Re: [boost] library proposal: odeint
Hi, solving ODEs is pretty standard, but it is also a starting point for elaborate numerical analysis and tools, especially if you solve large systems with conserved quantities. Nevertheless, I think some simple ODE solvers would fit into Boost, libs for numerical root finding and optimization are also part of it, at least experimentally. Many libraries for solving ODEs exist in the C/C++ world, but many of them lack the use of the standard interfaces and containers. This is really a drawback to languages like Fortran or Python and odeint is one attempt for easy to use and container-independent ode solver. Best regards, Karsten
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.
libs for numerical root finding and optimization are also part of it, at least experimentally.
Can you be more concrete? Which libraries are you talking about here?
Many libraries for solving ODEs exist in the C/C++ world, but many of them lack the use of the standard interfaces and containers. This is really a drawback to languages like Fortran or Python and odeint is one attempt for easy to use and container-independent ode solver.
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? 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. Regards, Thomas
Hi, 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 applied.
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.
Regards, Thomas
Regards, Mario
Thomas Klimpel wrote:
Can you be more concrete? Which libraries are you talking about here?
Look here: http://www.boost.org/doc/libs/1_41_0/libs/math/doc/sf_and_dist/html/math_too... http://www.boost.org/doc/libs/1_41_0/libs/math/doc/sf_and_dist/html/math_too...
participants (3)
-
Karsten Ahnert -
Mario Mulansky -
Thomas Klimpel