Rob Clewley wrote:
> Hi,
>> I don't foresee having time to add (probably only some of) PyDSTool to
> SciPy or unless someone would graciously give me a hand. Part of that
> would involve some very specific feedback on the basic classes we've
> implemented and an evaluation of whether they are suitable for general
> usage: in particular, our Interval, Pointset, Variable, and Trajectory
> classes.
> To bring on board PyDSTool's ODE solvers in their current
> form is also to commit to the use of these basic classes, as there's
> not a trivial way to factor out the solvers without losing some of the
> fancy functionality (e.g., having autonomous external inputs to a RHS
> interpolated from arrays). In my biased opinion, I think that these
> basic classes could add value to SciPy in general, but I'm not going
> to push it until I get a sense of sufficient support from you guys.
>
Most of the main contributors to SciPy have been cautious
object-oriented people. We've got only a few limited classes but there
is no central objection to adding classes other than my experience is
that it is very hard to get classes that are really central enough to be
useful in more than one domain.
But, that doesn't preclude us from providing package-specific classes
(which we've already done). So, if adding these classes makes it easier
/ faster to solve dynamical systems, then I don't think there is going
to be any real resistance to putting them in the ODE tool chain.
In fact, there has been lots of discussion suggesting pulling out ODE's
from their current home in the integrate package (where they only
loosely fit) and making say a "dynamic" module that houses several
solution approaches to ordinary differential equations: from simple
wrappers around ODEPACK to full-featured class-based approaches like
PyDSTool provides.
> Some technically-minded folks might want to help me improve our
>> implementations too.
>I could help with implementations in terms of Python-compiled language
wrappings if that's what you mean.
> Also, the lsodar routine already wrapped nicely in SloppyCell could
> much more easily be incorporated into SciPy with minimal baggage
> included.
>It sounds like this is something that we should do already. There are
several low-level routines with compiled code already available in the
SciPy compiled code without a Python wrapper. I'd like to fix this. I
welcome anyone who wants to do more fancy things on top. If you want or
need SVN access to SciPy to contribute the work just ask. Usually, the
changes take place in the sandbox, but we need to move lots of things
over from the sandbox.
I'm planning some major work on SciPy this summer (as soon as I get this
Python buffer interface thing done for Python 3.0)
> Anyway, we haven't yet got around our ugly method for generating
> C-based right-hand-sides in a platform-independent way, which is to
> (mis-)use distutils! We hope to use auto-generated makefiles instead,
> and we have some chance of coding that up over the summer. I would
> think that would be a deal-breaker for having our integrators in
> SciPy, no?
>There is general interest in adapting weave so that pieces of it which
would be helpful for this kind of work are easier to access.
> In the meantime, I would encourage anyone who writes for SciPy, has
> played with PyDSTool, and is curious about incorporating our solvers
> into SciPy, to please continue this discussion with a critical
> evaluation of our base classes (recent improvements are in our SVN
> repository). You can read more about their design and implementation
> at our wiki.
>
Thanks for continuing the discussion.
-Travis