Julia: rename eigs and svds?

[JeffBezanson]

I've never really liked these names --- why does adding an s mean to use an iterative method? Maybe we could call them Iterative.eig or eigit or eig_iterative?

[fredrikekre]

Perhaps just not export them from IterativeEigensolvers?

[StefanKarpinski]

A more generic way of controlling the algorithm by which eigenvalues are computed would be nice.

[Jutho]

I am working on a Krylov package that defines eigsolve and linsolve for solving eigenvalue problems and linear problems respectively, with the algorithm specified by dedicated Algorithm subtypes. The reason for not using eigs and IterativeSolvers is that

1. I don't like ARPACK, it fails often, and IterativeSolvers doesn't have restarted Lanczos and Arnoldi methods for eigenvalue problems yet

2. I want to use arbitrary functions as linear operators without wrapping them in LinearMaps (even though that is my own package)

3. I want to use arbitrary objects that behave as vectors (i.e. support scale! and axpy! and a few other methods).

I hope to make something public when julia 0.7 comes out (new iteration protocol and other changes)

[JeffBezanson]

Ok, can/should we copy your API for passing an algorithm to eig[solve]? Then IterativeEigensolvers could export algorithm types (including e.g. ARPACK if you really want to request that), and just extend eig and svd to accept those.

[Jutho]

You certainly can; I am certainly not going to say you should.

Maybe it's even confusing. linsolve is matlab's name for dense solvers of linear problems (i.e. lapack); I forgot what the exact difference was with mldivide, i.e. A\b, is, since I haven't used Matlab much the last few years.

But I just liked it as a name, and also found eigsolve to sound better as eigs (where I also don't know what the s is for). You might indeed just overload eig with an extra algorithm argument, but I don't think there is a spelled out name (ldiv?) for \ if you want to make the analogy to linear solvers? And typing \(A,b,algorithm) is a bit weird. Furthermore, it might be good to keep the distinction between the dense algorithms and the iterative ones; they typically have different interface.

As a side note, isn't it strange that eigs, i.e. ARPACK, is a Standard Library functionality and equally well established iterative solvers for linear problems are not? I guess the plan is that IterativeSolvers become part of the standard library one day?

[JeffBezanson]

I think it would be great to move IterativeEigensolvers and its ARPACK dependency out of stdlib into its own separate package.

[ViralBShah]

Yes. I think the cleanest thing to do that gives us the most flexibility is to move IterativeEigenSolvers and ARPACK into its own separate package.

[ViralBShah]

The current proposal is to rename them tsvd and teig for truncated, and also move these capabilities out of stdlib into packages.

[fredrikekre]

The current proposal is to rename them tsvd and teig for truncated

How are these better names than eigs and svds (which even have precedent)? I would be much more satisfied with (unexported) Arpack.eig and Argpack.svd.

[ViralBShah]

That would work too. IterativeEigenSolvers.eig is a mouthful, but Arpack.eig is probably ok.

[andreasnoack]

Now tracked in https://github.com/JuliaLinearAlgebra/Arpack.jl/issues/14