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