Subject: Re: [boost] library proposal: odeint
From: Mario Mulansky (mario.mulansky_at_[hidden])
Date: 2009-12-14 18:08:33
I'm working on odeint together with Karsten and, first of all, I want to thank
for the replies.
On Monday 14 December 2009 22:52:27 Thomas Klimpel wrote:
> Karsten Ahnert wrote:
> > Nevertheless, I think some simple ODE solvers would fit into Boost,
> Why do you think that some "simple" ODE solvers would fit into Boost, but
> more "complicated" real world ODE solvers would not? I always thought that
> Boost solves real world problems, and hence doesn't exclude "complicated"
> things in case they are really required.
I agree. odeint is meant to be used for "real world" problems. Actually, we do
already use it in our "every day" work. "simple" maybe was not phrased too
well. What Karsten meant is that we (currently) focus on solving general ode
systems, that means without considering conserved quantities, different
time-scales or other properties where more specialized routines should be
> I don't think that "container" is an appropriate abstraction in the domain
> of ode solvers. Don't you think that a vector space where you can do scalar
> multiplication and addition would be a more appropriate abstraction?
You are perfectly right. Our aim is to write a library that works with
stl::vector, tr1::array as well as ublas matrices, mtl matrices, blitz
matrices, maybe even graphs, as underlying state types. This was the reason
why we used an "iterator algebra" instead of a vector algebra in our
implementation. However, I totally see your point that this might not be the
right (in a mathematical sense) abstraction.
> Based on what I have seen from odeint, I would vote against inclusion into
> Boost. And I would probably also vote against inclusion into Boost of a
> fully polished simple ODE solvers library that provides just explicit RK
> solvers with adaptive stepsize control.
Ok. That's a clear answer to what we wanted to ask.
For us, solving odes appears very often in every day work and a well
maintained, easily applicable toolset shipped with the boost would make our
life much simpler. However, we are aware of the fact that such a library
might be too specific to actually become part of the boost.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk