Jonathan Guyer wrote:
>  On Oct 7, 2005, at 3:01 PM, Fernando Perez wrote:
>  
>  
> >it does seem that
> >pysparse offers extra capabilities beyond what scipy.sparse has, it 
> >would be
> >nice (I think) to fold that into the new shiny scipy.
>  
>  
>  True enough. Dan Wheeler and I would be willing to look into this. We 
>  presently use pysparse in FiPy because that's what we could figure out, 
>  particularly for iterative solvers, but it'd simplify our lives 
>  considerably if we could reduce our installation instructions to "Get 
>  SciPy. Get FiPy."
>  
>  Roman Geus has indicated to us that he's not interested in merging 
>  pysparse into a larger suite like SciPy; he prefers individually 
>  maintained small packages to large monolithic systems. He may have 
>  changed his mind about that, though, and regardless, pysparse is BSD 
>  licensed, so it's perfectly legal to use his code to improve 
>  scipy.sparse (assuming that rigorous benchmarking determines that there 
>  are, in fact, improvements to be made). We'll do some tests and, if a 
>  merge is warranted, we'll run it by Roman out of courtesy.

As Travis Oliphant wrote, I would like to help, too. So let me know if 
you have a need for another hands in (as almost anybody, I did write my 
own sparce matrix implementations in past). As a side-note, I would 
really appreciate to see umfpack bindinds in scipy (if the umfpack 
licence allows that, of course) - I have made some tests (admittedly a 
long time ago) showing that, at least for my class of problems umfpack 
performed much better than superlu via pysparse. (iterative solvers are 
out of question for me.)

cheers,
r.

_______________________________________________
Scipy-dev mailing list
Scipy-dev@[...].net
http://www.scipy.net/mailman/listinfo/scipy-dev