Re: [boost] [odeint] Iterator semantics

Subject: Re: [boost] [odeint] Iterator semantics
From: Mario Mulansky (mario.mulansky_at_[hidden])
Date: 2012-07-31 09:07:14

On Tuesday, July 31, 2012 11:47:55 am Sergey Mitsyn wrote:
> On 29.07.2012 6:31, Dave Abrahams wrote:
> > on Thu Jul 12 2012, Karsten Ahnert <karsten.ahnert-AT-ambrosys.de> wrote:
> >> On 07/12/2012 09:52 AM, Mario Mulansky wrote:
> >>> On Wed, 2012-07-11 at 23:50 -0700, Jeffrey Lee Hellrung, Jr. wrote:
> >>> 
> >>> I agree that it1 != it2 should be implemented in the sense of
> >>> t1+-dt/2 != t2+-dt/2
> >> 
> >> So you are checking for overlap. This looks good and I think it should
> >> work.
> > 
> > If I'm understanding correctly what you're saying, making two iterators
> > equal if their underlying time ranges overlap would be "evil."  Your
> > equality operator would not be transitive, and thus not an equivalence
> > relation, and therefore you would not have implemented a conforming
> > iterator, and you'd have no right to expect an algorithm that works on
> > iterators to work on yours.
> 
> IMHO the values of the iterator's underlying time variable would belong
> to "almost" discrete {t0 + n*dt +/- epsilon}, n from Z, where epsilon
> comes from floating point errors and is small. Thus, the distance
> between neighboring values should be no less than (dt-2*epsilon).> 
> I would say a test 'distance(t1,t2) < dt/2' would be transitive if
> epsilon is less than dt/4
> 
> That's of course true while t0 and dt is the same for all iterators
> passed to an algorithm.

dt even changes while iterating when methods with step-size control are used. 
This case is really ugly and I'm not sure if it's possible to implement a 
fully compatible iterator there. Maybe one should restrict to fixed-step-size 
methods where the overlap checking works?