Re: [boost] [odeint] Iterator semantics

Subject: Re: [boost] [odeint] Iterator semantics
From: Karsten Ahnert (karsten.ahnert_at_[hidden])
Date: 2012-07-30 04:37:35

On 07/29/2012 04:31 AM, 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:
>>>> 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:
>>>>>>
>>>>
>>>> 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
>>
>> 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.

Ahh, I did not thought about transitivity. You are right, checking for
overlap destroys transitivity. Nevertheless, I came to point that
checking for the relation (iter1.time < iter2.time) in combination with
a flagging which iterator is the first is sufficient.