Re: [boost] [odeint] GSoC Summary and Feedback request

Subject: Re: [boost] [odeint] GSoC Summary and Feedback request
From: Mario Mulansky (mario.mulansky_at_[hidden])
Date: 2011-08-23 05:08:36

On Mon, 22 Aug 2011 22:05:13 +0200, Larry Evans  
<cppljevans_at_[hidden]> wrote:

> On 08/22/11 13:01, Mario Mulansky wrote:
> [snip]
>> Please visit the docs to find out more about the features and abilities
>> of odeint:
>> http://headmyshoulder.github.com/odeint-v2/doc/index.html
> [snip]
> Here:
>
>
> http://headmyshoulder.github.com/odeint-v2/doc/boost_sandbox_numeric_odeint/concepts/state_algebra_operations.html
>
> the number 14 appears with no  explanation of why 14 was chosen instead
> of say 20 or 50.   Instead of 14, it would be better if there were some
> macro, like mpl's BOOST_MPL_LIMIT_VECTOR_SIZE:

First, the description of the algebra/operations is very brief, lots of  
details are still missing there.
The number 14 is induced by the maximum number of stages used in a stepper  
(here in the runge_kutta78 stepper). Also, I up to now never encountered  
an algorithm which requires more stages so I currently don't see a reason  
to increase the number.
However, I generally agree that it might be better to implement the  
operations by using Macros. But opposing to the  
BOOST_MPL_LIMIT_VECTOR_SIZE there is absolutely no point in giving the  
user the possibility to change the, say, ODEINT_OPERATIONS_COUNT as it is  
strictly defined by the implemented algorithms. For this reason switching  
to a macro-ized version does not have priority for us at the moment as we  
currently don't see any benefit, except elegance maybe.

>
>
> http://www.boost.org/doc/libs/1_47_0/libs/mpl/doc/refmanual/limit-vector-size.html
>
> There's also a typo on state_algebra_operations.html:
>
>   Constrcuts a Scale  object

Will be corrected, thanks.

>
> Also, couldn't:
>
>   algebra.for_eachN( y, x1, x2, ... xN-1)
>
> be replaced by generating overloaded algebra.for_each's?  Similarly,
> couldn't Operations::scale_sumN< Value1, Value2, ..., ValueN>
> done like the way fusion::vector is done?  This might make it easier,
> in the future, to convert to variadic templates.  OTOH, why not try
> variadic templates now?

Switching to an overloaded for_each would be no problem at all. But I do  
actually like the for_eachN version because the compiler tells you if you  
accidentally forget an argument. A bug rather difficult to identify if  
just another overload kicks in.
As said before, revisiting the Operations is something I want to look into  
at some point, but for now I don't think it's worth the effort.
As Karsten said, odeint-v2 is and will stay C++03, we have an c++11  
version in mind where operations and algebra will surely look more  
sophisticated.

Thanks for your comments!

Best,
Mario

>
> -regards,
> Larry