Well, I supposed you could implement that method via a hack, something up like...

p = precision (say, 0.2)
t = attempted time for scheduling
i = -1
t1 = 0  // this will be the answer

do 
	i++
	t1 = (t + (p * i)) % p
while (t1 < t)

schedule at t1

This is a real hack though, a way around the fact that Java has no built-in version of Knuth's "floored division".  It's certainly not how I'd do scheduling though.  What you're describing here is really scheduling agents by integer values, only scaled down by 1/5 or 1/10.  Why not just use integer values directly, which is consistent and less likely to cause bugs?  As in:

        schedule.scheduleRepeating( 0, 0 , new Agent(), 1 );
        schedule.scheduleRepeating( 0, -1, new Observer(), 2 );

Sean

On Sep 21, 2012, at 7:32 AM, Richard O. Legendi wrote:

> Hi Sean,
> 
> Yes, it is floating poing arithmetic, but I think it's a relevant issue here (Chris also mentioned he had a problem with it).
> 
> Let's say a user schedules an agent for every 0.1th time step and another agent that has to do something in each 0.2th time step after all the other agents stepped.
> 
> So something like this:
> 
>         schedule.scheduleRepeating( 0, 0 , new Agent(), 0.1 );
>         schedule.scheduleRepeating( 0, -1, new Observer(), 0.2 );
>         
> The user expects that Agent steps in 0.1, 0.2, 0.3, 0.4 and Observer steps in 0.2, 0.4, etc. (after Agent activated). The issue is that sometimes the accumulated error results in 0.199999... or 0.6000001... which completely breaks this.
> 
> Having a method like schedule.setScheduleDoublePrecision( delta ) would solve this issue. The user might now how fine resolution would he need so he could easily set it accordingly. (I've attached a simple examle.)
> 
> Best,
> Richard
> Richard O. Legendi
> Software developer
> Intelligent Applications and Web Services
> AITIA International, Inc. 
> 
> http://people.inf.elte.hu/legendi/
> 
> 
> 
> On 2012.09.20. 20:30, Sean Luke wrote:
>> I'm not sure I understand the issue.  Key.compare() is correct, and in fact Double.compare() is definitely numerically wrong, and has been criticized as such.  This is because Double.compare has to be consistent with Double.equals(), which wasn't meant for numerical comparison but (in this case) for bit comparison.
>> 
>> But at any rate, in the range that matters to us, [0.0, Inf), the two methods produce identical results.
>> 
>> So the complaint here is, I guess, that 0.1 + 0.2 != 0.3.  But I don't think this is a Schedule issue.  It's not even a Java issue.  This is a basic feature of floating-point arithmetic.  You cannot represent 0.1 exactly in floating-point: it's impossible.  If this an issue for you, the solution would be, I suppose, to only submit things at integer values.  
>> 
>> Sean
>> 
>> On Sep 20, 2012, at 8:54 AM, Chris Hollander wrote:
>> 
>> 
>>> I've had crazy issues due to the imprecision of doubles too, even when using integer times such as CURRENT_STEP + 1.0.
>>> 
>>> If doubles are being compaerd with == instead of Double.compare() or x.compareTo() that sounds like an oversight/bug, and may explain some things.
>>> 
>>> 
>>> On Thursday, September 20, 2012, Richard O. Legendi wrote:
>>> Hi All,
>>> 
>>> Here's a small issue: when someone schedules something for the time 0.3 and for the time 0.1 + 0.2, they mean different numbers for sure, so scheduled for different times. This way the ordering parameter of the schedule method is irrelevant.
>>> 
>>> Is there a facility to define a delta within which two doubles/floats are considered equal in the scheduler?
>>> 
>>> I took a short look on the Schedule implementation and saw that it stores the time definitions within a Key object, but it comapres doubles simply by the == operator.
>>> 
>>> Thanks for any assistance.
>>> 
>>> Best,
>>> Richard
>>> 
>>> -- 
>>> Richard O. Legendi
>>> Software developer
>>> Intelligent Applications and Web Services
>>> AITIA International, Inc.
>>> 
>>> http://people.inf.elte.hu/legendi/



>