Re: [Yanl-develop] my thoughts about current development state

[<mar...@gm...>]

Hi,

I wanted quickly to add that we came to the conclusion to drop the class structure of the implementation and remain with generic template code only. That means we don't have dynamical_system and ode_step_base anymore. Former abstract interfaces will be realized with concepts.

Mario

-------- Original-Nachricht --------
> Datum: Fri, 16 Oct 2009 14:53:30 +0200
> Von: Karsten Ahnert <kar...@gm...>
> An: yan...@li...
> Betreff: Re: [Yanl-develop] my thoughts about current development state

> Hello everybody,
> 
> First of all, it is nice that we started a very constructive discussion.
> In my eyes it goes in the right direction.
> 
> I would suggest that we write and discuss here some minimal code which
> is then implemented. I would also suggest that we use the euler steper
> as the basis for discussion, because its the most simple one and we drop
> any discussion about names, const, ... to a later point, until main
> points have been clarified.
> 
> My suggestion for a minimal stepper design is the following (avoiding
> any discussion about autonomous and non-autonomous systems)
> 
> template<class ContainerType>
> class ode_step_euler
> {
> 
>      ContainerType dxdt;
> 
> 
>  public:
> 
>      template<class CallMethod, class Iterator>
>      void do_step(
> 	CallMethod derivative ,
> 	double dt ,
> 	Iterator start ,
> 	Iterater end )
>      {
>          ContainerType::iterator dxdtiter = dxdt.begin();
>          derivative( start , dxdtiter );
>          while( start != end )
>              *start++ += dt * (*dxdtiter++);
>      }
> 
>     template< class CallMethod , class StateContainer >
>     void do_step(
>         CallMethod derivative ,
> 	double dt ,
> 	StateContainer state )
>     {
>         do_step( derivative , dt , state.begin() , state.end() );
>     }
> };
> 
> I think this design has all we need and is very flexible:
> * no virtual functions are used anymode
> * One can use the iterator and the container version
> * CallMethod can be a function or a class, whatever one likes.
> 
> 
> What we have to do now is, define how dxdt is created, which is indeed
> not trivial.
> 
> > Concerning the current discussion:
> > If the standard C-like usage (via functions) is not supported, as
> > currently discussed and which is also my position, I would recommend to
> > put the
> > system's state definition (the ContainerType) into the dynamical_system
> > class (or some derivation of it) as I did it in my
> > lib. This is less error prone, since the user must not care about what
> > kind of variable (s)he has to create for storing the state.
> > In Mario's example with the harmonic oscillator the user has to provide
> > the state-container-type twice, once to the stepper and to the system.
> > The latter seems to be kind of redundant and should be part of the
> > system and not the user's choice.
> 
> You are right, with the above approach this is possible but not
> necessary...
> 
> > In stepper:
> > The current time point  't'  should, if needed (as for non-autonomous
> > systems), be part of the system's state and being integrated by the
> > system using dt.
> 
> This is not possible, the time has to be a parameter. It will not work
> in RK4 or others for the intermediate points.
> 
> Bye, Karsten
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Yanl-develop mailing list
> Yan...@li...
> https://lists.sourceforge.net/lists/listinfo/yanl-develop

-- 
Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben!
http://portal.gmx.net/de/go/dsl02