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@ambrosys.de
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@ambrosys.de>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.