[SciPy-user] question about ODE output and time steps

[Rob Clewley]

> 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.

That makes sense. That's one of the things I'd like feedback on. For
instance, I imagine that a class that defines a numeric interval
(PyDSTool's Interval class) in a mathematically meaningful way has
universal appeal. I'm not talking about interval arithmetic here --
more in terms of defining tolerances/bounds on a variable, and with
containment tests implemented using __in__, appropriate end-point
behavior in the presence of rounding errors, support for semi- or
bi-infinite intervals, etc.

Also, a Pointset encapsulates arrays with named rows, an optional
dedicated independent variable (for intrinsically 'parameterized'
pointsets) and provides a friendlier face on large datasets for which
keeping track of which index corresponds to which variable's data
becomes a pain in the behind. Would/does anyone use these classes
outside of PyDSTool?

> 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.

I'm hoping that it would be acceptable to keep odeint etc. more or
less as they are rather than have them recoded to utilize Pointsets,
Trajectories, etc. in their output, unless someone volunteers to
re-wrap the existing fortran integrator codes! That's a job I will
probably never find time for.

> 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.

This sounds very appealing to me, and would make me feel more
comfortable about imposing new classes on SciPy. Others who are
interested in PDEs or in symbolic dynamics might like to have their
own sub-modules of a "dynamic" module. It might encourage some
convergence in broadly useful classes for supporting interpolated
curves & surfaces from discrete data sets. I currently only have a
linearly interpolated curve class ("Trajectory") which does not easily
generalize.

I would be willing to get involved in setting up a "dynamic" module.

> > 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.

Although that's not what I meant, that might also be helpful. Erik
Sherwood might want to get back to you about that once we've explored
how we should better approach it. I was meaning basic issues such as
whether our class API and initializations are sufficiently robust and
pythonic, in the eyes of more professional/experienced pythoneers. For
instance, take the Pointset class: does the API need cleaning up? Is
its slicing behavior reasonable? Is it unacceptable to coerce all
incoming float arrays to float64!? (I think I know the answer to the
last question, but I'm not planning to fix that soon :)

> 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.

I have no idea whether the way that we build C functions on the fly
from user specifications can fit into the weave framework (I've never
used weave), but I'll spend some time later to think about it. Perhaps
others can already answer that question for me...

-Rob