Re: Discussion of why java.lang.Number does not implement Comparable
Sideswipe wrote:
I have a follow-up to my own question: Perhaps what is in order is to
have an intermediary class like: "public class RealNumber extends
Number implements Comparable" -- and in the event where the are non-
definable comparisons, throw an exception. Then, you can have
Imaginary Numbers and allow the rest of us to work with numbers as we
naturally understand them.
I think we have hashed over the general RealNumber case quite
thoroughly. I would like to raise a different possibility which I think
captures the spirit of that idea while dodging the problems we have been
discussing.
Suppose there were an ExtendedBigDecimal with the following properties:
1. Its value set is the union of BigDecimal and the Double infinities
and NaNs.
2. It is Comparable<ExtendedBigDecimal>, with natural order for number
to number comparisons, and the Double.compareTo rules for infinities and
NaNs.
Then I think every value in the java.lang and java.math concrete Number
subclasses is exactly convertible to ExtendedBigDecimal, with the
ExtendedBigDecimal compareTo consistent with the Number class' compareTo.
Suppose also there were an interface, EBDNumber, that has a single
abstract method:
ExtendedBigDecimal convertToEBD();
and EBDNumber also extended Comparable<EBDNumber>
The comparison would be implemented by the Number subclass compareTo
methods not giving up after finding the other object is of a different
class. First it would check for it also implementing EBDNumber, and if
so convert both numbers to ExtendedBigDecimal and use its compareTo.
Two questions:
1. Does this make any sense?
2. Would the mixed type comparisons it would support be sufficiently
useful to justify the cost.
Note that it would not help with e.g. general rational number
arithmetic. 1/3, in a rational number package, would not be exactly
convertible to ExtendedBigDecimal.
Patricia