[SciPy-User] isn't it a bug in scipy.sparse? + some questions

[Nathan Bell]

2009/11/8 Dmitrey <tmp50 at ukr.net>:
>
> Questions:
> 1) Seems like a[some_ind,:]=something works very, very slow for lil. I have
> implemented a workaround, but can I use a[some_ind,:] for another format
> than lil? (seems like all other ones doesn't support it).

Please file a bug report if you haven't done so already.  It's
possible that this issue is already fixed [1] or will be fixed in 0.8.

[1] http://projects.scipy.org/scipy/ticket/917

> 2) What is current situation with matmat and matvec functions? They say
> "deprecated" but no alternative is mentioned.

Those are implemented with A*x now (just like a dense matrix).  Sorry
for the confusion, the deprecation warning should be more explicit.
Feel free to file a bug report :)

> 3) What is current situation with scipy.sparse.linalg.spsolve? It says
> /usr/lib/python2.6/dist-packages/scipy/sparse/linalg/dsolve/linsolve.py:78:
> DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be removed,
> install scikits.umfpack instead
>   ' install scikits.umfpack instead', DeprecationWarning )
> But I don't want my code to be dependent on a scikits module. Are there
> another default/autoselect solver for sparse SLEs?
> If no, which one would you recommend me to use as default for sparse SLEs -
> bicg, gmres, something else?

Currently, if you have UMFPACK installed when SciPy is compiled (often
this happens automatically) then it will be the default handler for
spsolve().  Since UMFPACK is a GPL code a decision was made to move
the wrappers an optional package (scikits.umfpack).  Eventually, these
wrappers will be removed from SciPy and the default will revert to
SuperLU, which is BSD licensed sparse factorization method that ships
with SciPy.

-- 
Nathan Bell wnbell at gmail.com
http://www.wnbell.com/