[SciPy-Dev] Consensus on the future of integrate.ode

Benny Malengier benny.malengier@gmail....
Thu Sep 5 04:10:26 CDT 2013


I commented my ideas in the pull request here:
https://github.com/scipy/scipy/issues/2818#issuecomment-23646270


Main point: I think ode class should be redone to drop all the vode
specific stuff and keep to the minimum, using like matlab set_options for
all the rest, and then current odeint implemented as a simple wrapper
around ode.

Benny
2013/9/5 Juan Luis Cano <juanlu001@gmail.com>

> On 09/04/2013 06:14 PM, boyfarrell@gmail.com wrote:
> > Dear list,
> >
> > I think it would be interesting to start a discussion regarding the
> direction of integrate.ode. Reading the list, there seems to be many people
> interested seeing improvements. Is there a roadmap for development? If not
> can we come to a consensus about how best to contribute to this part of
> scipy? I think it is fair to say that other projects have overtaken scipy
> in terms integrating new solvers and general development in this area.
> Which is a shame.
> >
> > Personally, speaking as a user, I would like to see the use of more
> modern solvers. For example the code could be updated to use CVODE. This
> has many improvements/fixes over the Fortran VODE solver that is currently
> used. This would be a nice place to start, clearly that is still a
> nontrivial task.
> >
> > Also, is there a way that developers could be encourage to contribute
> additional solvers? For example by making an elegant low level API that
> makes this easier. Moreover, say that in order for a developer to connect a
> new solver to scipy all that had to be done was implement a particular,
> well defined, interface for their wrapper. Once implemented the new solver
> could be called with the exciting integrate.ode interface. Has anybody got
> experience is such design? Surely something like this has been attempted?
> The GNU Scientific Library interface springs to mind as a good example,
> http://www.gnu.org/software/gsl/manual/html_node/Ordinary-Differential-Equations.html
> >
> > Finally, I have read some discussion here regarding changing the API and
> or unifying the odeint and ode. I don't want to get too distracted with
> this as my main point is outlined above. Personally the current API doesn't
> bother me too much, I find both easy to use. But if this is being
> considered for an update I think the crucial thing is to have the interface
> have no reliance on any particular solver. Abstraction is key.
> >
> > Happy to know your thoughts and if we can make a push together for some
> improvements in this area then all the better.
>
> Regarding the last part, I created a PR last week with some changes to
> the odeint function, but I didn't aim to unify odeint and ode or do a
> big rework of the API. I introduced a couple of convenience changes:
> odeint objetive function has different signature than ode (one is (y, t)
> and the other is (t, y)) and some minor (but backwards incompatible)
> changes, done to solve some annoying issues that odeint has had. The
> thing is that even this little changes require a proper deprecation
> cycle to not break everyone's code too soon, so this major uplifting in
> ode/odeint must be taken very carefully.
>
> The good thing about odeint is that it's a simple function to
> GetThingsDone™ when you just want to quickly integrate some equation.
> You just need a lambda, an initial condition and a vector of time
> values. Having to configure a solver with its options is not very
> straightforward, specially for interactive work, as Gaël Varoquaux had
> already described in a previous discussion some years ago:
>
> http://osdir.com/ml/python-scientific-devel/2009-02/msg00042.html
>
> (this is true for everything else IMHO, also for building splines and
> stuff like that).
>
> Perhaps the most important thing is that someone with interest in this
> patiently iterates with this idea, searches consensus in the mailing
> list, write a proposal somewhere if needed, thinks about the proper
> deprecation process with the maintainers, writes the code and, well,
> takes responsibility of this until the very end. I guess it can take
> some months.
>
> Juan Luis Cano
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20130905/847aff31/attachment.html 


More information about the SciPy-Dev mailing list