Difficulty of compareTo on floats/doubles

[Alex M]

Hi, this is my first time posting to any OpenJDK list, so if I'm doing
something inappropriately let me know. :)

I saw it being suggested that "any" could perhaps support .equals() and
.compareTo(). equals() seems to make sense -- using "==" would compare
identity on Objects and bits on primitives, while .equals() would become ==
for primitives and make the call on Objects. I'm not sure how plausibly the
compareTo() idea will happen (given that would not make sense on Objects
that don't implement Comparable, or on booleans), but one more potential
problem with it is that floats/doubles have an undefined return value when
comparing NaN's; they're neither less than, equal, not greater than any
others.

Unfortunately, or at least confusingly, the Float and Double classes offer
a compareTo method which defines an order on NaNs based on their int bits
(and which allows them to be equal to one another). This is also reflected
in their equals() methods, such that various comparisons end up different.


        Float h=Float.NaN;
        float i=Float.NaN;

        System.out.println(h==i);       //False
        System.out.println(h.equals(i));//True

        float inf=Float.POSITIVE_INFINITY;

        System.out.println(h<inf);           //False
        System.out.println(h.compareTo(inf));//1 ("greater")

These situations would need to be dealt with, even in the question of just
allowing equality comparison -- some situations, especially with an
implicit unboxing from a Float, will cause very strange problems.

~6 out of 5 statisticians say that the
number of statistics that either make
no sense or use ridiculous timescales
at all has dropped over 164% in the
last 5.62474396842 years.