Transition to ScipyLinearOperator

[SebastianSemper]

As it seems SciPy offers a huge amount of algorithms that only make use of forward and backward multiplications. With our easy translation from a fastmat Matrix object to a SciPy LinearOperator object, we can access this plethora of algorithms.

https://docs.scipy.org/doc/scipy/reference/sparse.linalg.html

I think we should get rid of all algorithms in fastmat that have a duplicate in SciPy, since these are are exposed to way more testing and also we have less duplication in the Python ecosystem.

The question now is, whether we should keep properties, like largestSV or largestEV, and fill them by calling the appropriate SciPy operations, thus introducing some kind of convenience in using these SciPy routines, or do we leave the user out in the wild and manage all of this stuff on his own?

In the first case, we would have to rewrite some of the routines and also expose some more flexibility, since SciPy for instance allows to calculate several singular and eigen values at once. But, we could also add a lot more, like the calculation of the k principal eigen vectors or singular vectors.

In the latter case we make fastmat itself a littler lighter and we shift the focus back to our original goal in providing fast linear transforms. But we would also loose the possibility to provide cloded form solutions to singular values and eigenvalues for example in the case of Fourier matrices or Circulant ones.

Thoughts?

[ChristophWWagner]

did you mean 'cloathed form solutions'? :3

[ChristophWWagner]

Aside the pun I think we should keep every property that assists an existing algorithm for so long as it referenced from within fastmat. If we get rid of largestEV / largestSV usage within fastmat itself I totally agree to let more proficient packages do the job based on our main grounds -- efficient matrix abstraction.

[SebastianSemper]

Done in #43 and #60 . closing.