[SciPy-dev] sparse matrix support status
Fernando.Perez at colorado.edu
Fri Oct 7 18:11:58 CDT 2005
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
>>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.
Well, as Travis just mentioned in another thread:
But, frankly, we can probably distribute an __init__ file with scipy
core that is generic enough to get all the packages installed, and not
distribute an __init__ file with scipy.
That way we achieve the modularity of scipy that is desired (and can
perhaps start to persuade people like pysparse to get their package in a
condition to work like scipy.sparse). And they can still keep their own
release (because scipy core will be the basic foundation).
And installing packages separately becomes no big deal at all.
scipy is moving towards making it as easy as possible for externally
maintained packages (possibly with their own release cycle) to integrate
cleanly into scipy. So hopefully there will be room for common work here...
More information about the Scipy-dev