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/