RFC: Move iterative eigensolvers to the stdlib

[ararslan]

This PR moves eigs and svds into an Arnoldi package in the stdlib. This was very self-contained and was a pretty easy move. Julia's binary dependency on ARPACK is now only for this package, which can eventually be moved out entirely. thereby eliminating a GPL-licensed binary dependency. (Just kidding, ARPACK is 3-clause BSD.)

There might be a couple of uses of eigs that I missed, hence WIP. Done.

[ararslan]

This is confusing to me. ARPACK is not GPL-licensed, so why did we only test the Arnoldi stuff if we were using GPL libraries?

[StefanKarpinski]

Guessing: maybe because it depends on SuiteSparse which is partly GPL?

[ararslan]

That would make sense. I guess I should modify the stdlib tests then to only run Arnoldi when we're okay with using GPL libraries? (i.e. when Base.USE_GPL_LIBS is true)

[StefanKarpinski]

@ViralBShah ^

[andreasnoack]

So ARPACK as such doesn't depend on anything in SuiteSparse but the wrappers use factorizations and when the input is sparse, which is the case in some of the tests, then the wrappers use sparse factorizations from SuiteSparse.

[ViralBShah]

Yes, the shift and invert solvers need SuiteSparse.

[andreasnoack]

So the way to think of arpack.jl and arnoldi.jl is that arpack.jl is like blas.jl and lapack.jl, i.e. fairly low-level wrappers of Fortran subroutines while arnoldi.jl is like cholesky.jl, qr.jl, and lu.jl, i.e. higher level functionality that utilizes the wrappers in arpack.jl.

We should consider a more recognizable name than Arnoldi for the module because many of the users of eigs will have no idea what Arnoldi is. Although these methods are (almost) agnostic to the storage format, it might be an idea to call it SparseEigen or something like that because they are most often used with sparse matrices. Any thoughts @Sacha0 and @fredrikekre?

[fredrikekre]

We should consider a more recognizable name than Arnoldi

Yes, I also think that Arnoldi is a bad name. I suggested simply ARPACK in slack/linalg, but as @ararslan pointed out we are not wrapping all of ARPACK (but perhaps that will change in the future, and then ARPACK would be an appropriate name). Brainstorming some other names: EigenIterations, IterativeEigen, IterativeEigenSolvers. I kind of like EigenIterations.

[stevengj]

We should also avoid a name that sounds like it is about iterators. Maybe EigSubspace?

[Sacha0]

A better name than Arnoldi would be great. @fredrikekre's IterativeEigenSolvers strikes me as the most descriptive and accurate from those above. Best!

[ararslan]

IterativeEigenSolvers seems fine, though it's quite similar to JuliaMath/IterativeSolvers (not sure whether that's good or bad). According to Andreas, we do wrap most of ARPACK, but I suppose I would expect a package with a name like ARPACK to be a lower level wrapper over the library rather than providing higher level APIs as we do in this package.

I'm pretty indifferent toward what this is called, so once a consensus is reached I'll just move forward with the agreed upon name.

[Sacha0]

I would expect a package with a name like ARPACK to be a lower level wrapper over the library rather than providing higher level APIs as we do in this package.

Likewise, i.e. I would expect the package IterativeEigenSolvers to potentially implement some subset of its operations via calls to the package ARPACK. Best

[ViralBShah]

I thought that eventually, the ARPACK wrappers would move to ARPACK.jl, and the rest of the higher level functionality would move to IterativeSolvers.jl.

[ararslan]

That also seems like a good option.

[ViralBShah]

Let's go ahead with IterativeEigenSolvers for now, and get this done.

[ararslan]

Sounds great. Thanks all for the feedback.

[ararslan]

CI failures are unrelated (32-bit Windows couldn't connect, macOS couldn't load OpenBLAS). Unless there are any further comments, I plan to merge this soon.

[Sacha0]

Looks great! Thanks @ararslan! :)