Re: [boost] [odeint] Iterator semantics

Subject: Re: [boost] [odeint] Iterator semantics
From: Karsten Ahnert (karsten.ahnert_at_[hidden])
Date: 2012-07-12 04:19:10

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:
>>>>
>>>>> 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

So you are checking for overlap. This looks good and I think it should work.

> 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.

Maybe this is not so problematic. The iterators can be different from
the integrate routines.

> Nevertheless I think this is still better than flagging iterators.