Re: [boost] [odeint] Iterator semantics

Subject: Re: [boost] [odeint] Iterator semantics
From: Mario Mulansky (mario.mulansky_at_[hidden])
Date: 2012-07-12 03:52:49

On Wed, 2012-07-11 at 23:50 -0700, Jeffrey Lee Hellrung, Jr. wrote:
> On Wed, Jul 11, 2012 at 11:21 PM, Karsten Ahnert <karsten.ahnert_at_[hidden]
> > wrote:
> 
> > On 07/12/2012 12:39 AM, Jeffrey Lee Hellrung, Jr. wrote:
> > > On Wed, Jul 11, 2012 at 2:57 PM, Karsten Ahnert
> > > <karsten.ahnert_at_[hidden]>wrote:
> > >
> > >> On 07/11/2012 07:44 PM, Jeffrey Lee Hellrung, Jr. wrote:
> > >>> On Wed, Jul 11, 2012 at 9:04 AM, Karsten Ahnert
> > >>> <karsten.ahnert_at_[hidden]>wrote:
> >
> [...]
> 
> > >>> This is problematic since equality here means that the time
> > >>>> (t) of the begin iterator is smaller then the time of the end
> > iterator.
> > >>>>
> > >>>
> > >>> Can you elaborate? I don't understand why this is what equality means.
> > >>
> > >> One needs to implement the != operator (or equal if you use
> > >> Boost.Iterator). A naive implementation of operator!= (or the equal() if
> > >> you use boost.iterator) could check that the current time of the ODE is
> > >> smaller then the time of other iterator:
> > >>
> > >> bool equal( iterator other )
> > >> {
> > >>     return this->t < other->t;
> > >> }
> > >>
> > >
> > > :: confused :: I would think iterator1 op iterator2 is equivalent to
> > time1
> > > op time2.
> >
> > No, this is not the case iterator != iterator2 is equivalaent to time1 <
> > time2 . The first operation is commutative the second one not.
> >
> 
> Well, you can define operator== and operator!= however you want, and some
> definitions will make sense and some won't (e.g., non-/anti-symmetry).
> *All* I've been trying to do here is coax out of you *why* you're defining
> operator== and operator!= this way :)
> 
> (Especially, with my limited understanding of the application, when it
> seems time1 op time2 would do what you want, or perhaps a fuzzy version
> taking into account the time step.)

I agree that it1 != it2 should be implemented in the sense of 
t1+-dt/2 != t2+-dt/2
As far as I understand the timestep dt should be available at this
point.
Unfortunately, this behavior would be different from the current
integrate implementations that guarantee that the endpoint is reached
while in the above version we might stop in the interval t_end-dt/2.
Nevertheless I think this is still better than flagging iterators.

Best, Mario