[SciPy-dev] the scipy mission, include finite element solver
Robert Kern
robert.kern@gmail....
Wed Apr 8 18:04:52 CDT 2009
On Wed, Apr 8, 2009 at 17:43, Ondrej Certik <ondrej@certik.cz> wrote:
> On Mon, Apr 6, 2009 at 2:23 AM, Prabhu Ramachandran
> <prabhu@aero.iitb.ac.in> wrote:
>> A scikit would be good as would a separate family of tools under the
>> scipy umbrella. It would be great to have a scipy-pde package but what
>> does this have to do with scipy itself? Do we have a larger
>
> So what exactly is "scipy itself"?
People usually mean the scipy Python package when they use this term.
> I thought it could be all numerical
> things, that are in matlab.
>
> They have it as a toolbox:
>
> http://www.mathworks.com/products/pde/
>
> so I guess scipy should be like a bare matlab and all toolboxes should
> go to scikits?
Not necessarily *bare* Matlab, but that's roughly my take. Personally,
I don't feel a need to put everything numerical possible into scipy
itself. That way lies madness, IMO. A single Python package just isn't
the right technology to contain that much code.
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?".
>> 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".
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the Scipy-dev
mailing list