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

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

Hi,

> Nevertheless we should consider to implement some dynamical system classes.
> Maybe no basic one, as now, but some useful
> wrappers for building dynamical systems of dynamical systems, as I
> implemented it in my class (I don't know if you had a close look on it).
> I find this very useful and use it a lot. I mean something like this:
>
>   coupled_chain< hopf_oscillator , complex_coupling<1,2> >
> ginzburg_landau( 1000 );
>   sparse_network< roessler >   net( 123 );
>               coupled_grid< lotka_volterra >   rauber_beute_gebiet( 100,100
> );
>
> Something like this should exist in parallel to the steppers in order to
> provide more reusable code.

I think this is generally a good idea and it indeed seems usefull to provide 
such dynamical system classes within the library. However, one has to make 
sure that the corresponding state representations are properly working 
together with the steppers, as they basically expect plain 1D sequences of 
doubles/complex and won't work with chains of 2 or higher dimensional 
objects. Maybe this can be overcome, though.
Anyways, if it is possible to implement something like "chain of dynamical 
system" that works with the stepper I agree that this would be a usefull 
thing.

Regards, Mario

>
> tschüssikovsky,
> André
>
>
> -------- 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
>
> ---------------------------------------------------------------------------
>--- 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