[SciPy-dev] the scipy mission, include finite element solver
Prabhu Ramachandran
prabhu@aero.iitb.ac...
Thu Apr 9 06:18:04 CDT 2009
On 04/09/09 04:34, Robert Kern wrote:
> I see scipy as primarily providing the fundamentals. In addition, it
> also serves as a home for numerical code that would otherwise have no
> home. I see no benefit in pulling in existing projects that are
> thriving on their own. As for PDEs, specifically, I think the domain
> is rich enough that it can usefully live in its own package better
> than being put into scipy. While there may be some fundamentals that
> you can pull out that might make sense to live in scipy (some simple
> good-enough mesh generation as you suggest), you will inevitably need
> more options, more sophisticated mesh generation, more dependencies,
> etc., that fits the development life cycle of a PDE-dedicated package
> more than scipy.
>
> In other words, the important question isn't, "Can scipy do this?" but
> rather, "Can Python do this?".
Thanks Robert for expressing this so nicely!
>>> super-package that hopes to provide different bundles, kind of like sage
>>> but more targeted to numerical computing?
>> What do you mean by "we have a larger superpackage"? Are you asking if
>> we want to have such a package, or if we want scipy to become such a
>> package?
>
> I don't think he's talking about a Python package, but rather a
> project that bundles Python packages together, like the SAGE
> distribution (which is much more than the sage Python package),
> Python(X,Y) and EPD. scipy is a Python package and can't really morph
> into a superpackage. It simply belongs to a different category of
> things. In fact, I suggest not using the term "superpackage" but
> "distribution".
Indeed, that is precisely what I meant --- a distribution tailored for
PDEs would be nice. If we had a fool proof distribution generation
system that works on all platforms this would be trivial but easier said
than done.
cheers,
prabhu
More information about the Scipy-dev
mailing list