> 
> On the matter of writing a Comparator<Number>, the basic problem is
> the Number interface is not strong enough to allow you to write such
> functionality.
> 
> First, the Number type basically only means "convertible to a
> primitive." There are no strict requirements on consistency between
> the different conversion methods and there is not even a requirement
> that calling the same Number method on the same object returns the
> same value (since Numbers are not required to be immutable).
> 
> Even just writing a semantically correct Comparator<Number> for
> Number subclasses in the JDK is nontrivial. Multiple Number
> subclasses (BigInteger and BigDecimal) have values outside of the
> set of values that can be represented with a primitive type.
> 
> So a general Comparator<Number> is not really well-defined.

Right. This is something I discovered in the process. (Feel free to look at how 
for I got [1].)

Although I was the one who brought it up, I think the whole Comparator<Number> 
discussion is slightly off topic. I still think that explicitly mentioning 
rounding and truncation is a bit confusing, as even the JDK implementations 
resort to other methods.

[1] http://stackoverflow.com/a/4192900/276052

Reply via email to