Boost logo

Boost :

Subject: Re: [boost] library proposal : odeint
From: Mario Mulansky (mario.mulansky_at_[hidden])
Date: 2010-07-11 05:41:00

On Sunday 11 July 2010 06:26:22 Matthias Troyer wrote:
> On 9 Jul 2010, at 15:46, Karsten Ahnert wrote:
> >> I have one question - have you considered if your library will 'play
> >> nicely' with the Boost.Units library? If it will, the units error
> >> detection and convenience of output with units, would seem to make it
> >> much more attractive.
> >
> > At the moment it is not possible to use Boost.Units. We are redesigning
> > the library and it might be possible to enable Boost.Units at some
> > point. But I suspect, that Boost.Units will not work in general with
> > odeint. I can go in details if you like.
> I would be very interested in why it would not work with Boost.Units since
> I might be interested in using such a library with my own datatypes
> instead of double or std::complex<double>

Using your own integral types, e.g. vector< my_double >, should be possible,
as long as standard operators ( + , * , += , *= ... ) are defined for
my_double. For steppers with error control, also max, abs and pow functions
are required for your data type. If you encounter a problem please let us

For using Boost.Units, the types for state vector and derivative vector are
different, as Karsten also pointed out. This is not supported currently, but
might be possible. Things get more complicated when one thinks about using
different units for different entries of the state vector - as Karsten said.

My very personal opinion is that the effort to support Boost.Units exceeds the
outcome. Before addressing an ODE numerically, one should always transform to
dimensionless equations anyways so I see only little benefits from Boost.Units

However, using own data types is exactly what this library is designed for so
we appreciate any feedback on this.

Best regards,


> Matthias
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at