Discussion of why java.lang.Number does not implement Comparable

[Sideswipe]

So, I have read the SDN entry of why Number does not implement
Comparable
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4414323

And while I agree with their thinking I disagree with their approach.

Not all Numbers are 'Comparable' such as NaN (which is one of their
motivational cases). However, when you look up the behavior of
compareTo() in Float -- no such special condition exists for the case
of NaN

While some numbers are not comparable, I argue that the numbers used
in Java (with the exception of NaN) are comparable. So, Double d =
10.12 and Integer x = 11 ARE comparable. X is clearly larger.

For me, it seems that a better approach would be to have Number
implement Comparable in the class signature but not actually DO the
implementation. That way, in the event of NaN and such, implementing
methods can simply throw exceptions (which seems far more appropriate
than what Float.compareTo(Float.NaN) produces now -- which is

int result = new Float(10).compareTo(Float.NaN);
System.out.println(result);

-1

Only special number cases are not comparable.

Thoughts, anyone? I fully realize I may bring out the worst in people
with this question

Christian Bongiorno
http://christian.bongiorno.org

 

[Sideswipe]

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.

 

[Owen Jacobson]

So, I have read the SDN entry of why Number does not implement
Comparablehttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4414323

And while I agree with their thinking I disagree with their approach.

Not all Numbers are 'Comparable' such as NaN (which is one of their
motivational cases). However, when you look up the behavior of
compareTo() in Float -- no such special condition exists for the case
of NaN

While some numbers are not comparable, I argue that the numbers used
in Java (with the exception of NaN) are comparable. So, Double d =
10.12 and Integer x = 11 ARE comparable. X is clearly larger.

How would you implement Number#compareTo(Number n) in such a way that
it imposes a total ordering on *all* objects that satisfy the Number
type, including user-supplied Number subclasses? There is nothing in
either the JLS or the JRE to prevent you from adding new Number
subclasses -- say you have your own arbitrary-precision decimal class
that's 4x as fast as Sun's for operations you care about[1] that also
extends Number?

Comparable's contract is only thoroughly satisfiable when the
implementation is closed to extension, either by being final or by
being pacakge-visible or less with known subclasses.

[1] Contrived, but valid, example

 

[Eric Sosman]

So, I have read the SDN entry of why Number does not implement
Comparable
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4414323

And while I agree with their thinking I disagree with their approach.

Not all Numbers are 'Comparable' such as NaN (which is one of their
motivational cases). However, when you look up the behavior of
compareTo() in Float -- no such special condition exists for the case
of NaN

What compare() implementation do you suggest for

public class Complex extends Number {
private final double real;
private final double imag;
...
}

.... or would you prefer to say that a complex number cannot
be a Number?

 

[Patricia Shanahan]

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'm not sure it is that easy even for RealNumber classes. Suppose two
classes X and Y each represent a subset of the real numbers. For
example, X represents unresolved surds based on rationals exactly, so
that 5+sqrt(2/3) would be a possible X value. Y represents some other
subset of the real numbers, such as the trig functions of integer
numbers of degrees, so that sine(30) is exactly representable as a Y.

There is a total order on (X union Y), because every element corresponds
to some real number, and the real numbers have a total order.

However, determining the order between an X and a Y may not be trivial.
If the X and Y have different values, calculating out the binary
expansion of each until there is a difference will determine their
order. However, that approach does not tell you how to detect exact
equality between an X and a Y.

Patricia

 

[Twisted]

However, determining the order between an X and a Y may not be trivial.
If the X and Y have different values, calculating out the binary
expansion of each until there is a difference will determine their
order. However, that approach does not tell you how to detect exact
equality between an X and a Y.

Seems you know a fair bit of higher maths from your recent posting
history here!

I'd suggest the following:

* First, sorting a NaN in some arbitrary but consistent way, e.g. NaN
< -inf < -10 < -1 < 0 < 1 < 10 < inf, allows well-defined behavior and
makes collections of floats that may include NaNs safe to put into
e.g. a TreeSet. So I'm not sure I disagree with Float's implementation
of this behavior.
* Second, Patricia's detecting-exact-equality issue with
representations of irrational numbers:

- You can usually determine algebraically whether they are equal or
not. For example nearly every sine is transcendental and the finite
set of algebraic sines is well-known. Also e^x is transcendental for
all rational x except 0, so far as I am aware, and ln x for rational
x != 1 (these mirror one another); log(a) b with rational a and b when
b is not a rational power of a (by definition!)...
- Nonetheless you may not always be able to, and even when you are
algebraically sure they're unequal it may be unobvious which is
smaller without computing a ridiculously long initially-identical
portion of their binary expansions. In these cases a consistent but
arbitrary ordering is better than none.
- Often you *will* be able to decide order algebraically, by taking an
inverse func of both sides of an appropriately-contrived inequality
with an undecided relational operator in the middle, whose correct
value is easily decided from the result of this and which is either
the same as or reversed from the correct inequality for the original
numbers. This works for any monotonic func (e.g. exp, ln, any log,
hyperbolic sine and inverse hyperbolic sine, square root and inverse
hyperbolic cosine (pick one branch)) and other funcs have a symmetry
that lets you convert to a smaller domain on which the funcs are
monotonic (almost every trig function, quadratics, hyperbolic cosine)

 

[Oliver Wong]

So, I have read the SDN entry of why Number does not implement
Comparable
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4414323

And while I agree with their thinking I disagree with their approach.

Not all Numbers are 'Comparable' such as NaN (which is one of their
motivational cases). However, when you look up the behavior of
compareTo() in Float -- no such special condition exists for the case
of NaN

While some numbers are not comparable, I argue that the numbers used
in Java (with the exception of NaN) are comparable. So, Double d =
10.12 and Integer x = 11 ARE comparable. X is clearly larger.

For me, it seems that a better approach would be to have Number
implement Comparable in the class signature but not actually DO the
implementation. That way, in the event of NaN and such, implementing
methods can simply throw exceptions (which seems far more appropriate
than what Float.compareTo(Float.NaN) produces now -- which is

int result = new Float(10).compareTo(Float.NaN);
System.out.println(result);

-1

Only special number cases are not comparable.

Thoughts, anyone? I fully realize I may bring out the worst in people
with this question

I'm siding with Sun on this one. I think since, Java 1.5, none of the
classes in the standard library simply implement Comparable. Instead, they
may implement Comparable<Integer>, or Comparable<Float>, etc. Typically,
for a given class Foo, if it implements Comparable, it does so in the form
of Comparable<Foo>.

So it follows that if Number were to implement Comparable, it would do
so in the form of Comparable<Number>. Which means that any instance of
Number must be comparable to any other instance of Number.

In particular, that means that there must exist code in the Integer
class to allow it to be comparable to Double, in addition to all the other
possible combinations. Since Number is not final, end-users can generate
their own subclass of Number, and know Integer would have to someone add
code so that it becomes comparable to those user defined classes.

Contrast that with the current situation, where Integer implements
Comparable<Integer>, and the Integer class itself is final. Now, the code
in Integer only needs to take care of comparing itself against other
Integers, and it doesn't have to worry about user-defined subclasses,
since Integer is final.

If ever you need to compare an Integer to a Double, it is usually
straightforward to convert the Integer into a Double, and then compare the
resulting Double against the original Double.

- Oliver

 

[Michael Jung]

* First, sorting a NaN in some arbitrary but consistent way, e.g. NaN
< -inf < -10 < -1 < 0 < 1 < 10 < inf, allows well-defined behavior and
makes collections of floats that may include NaNs safe to put into
e.g. a TreeSet. So I'm not sure I disagree with Float's implementation
of this behavior.

That wont really help, because you will lose certain features of
comparing. Throwing an Arithmetic exception is probably better. Working with
the two infinities in Java is already somewhat awkward.

* Second, Patricia's detecting-exact-equality issue with
representations of irrational numbers:

- You can usually determine algebraically whether they are equal or
not.

No. Depending on what you do, solutions to these problems are unknown. Suppose
I have numbers representing the first (smallest) real root of polynomials.,
i.e. N(a,b,c) represents the smallest real root of x^3 - ax^2 - bx - c. Now
tell me how N(.1,-.2,1) compares to N(.2,.3,-2)? (While this problem may be
solvable, you should get the picture.)

Michael

 

[Twisted]

That wont really help, because you will lose certain features of
comparing.

Explain please.

No.

Do not bluntly contradict me in a public forum.

Depending on what you do, solutions to these problems are unknown.

There's an equation that can in principle be solved to see if they are
equal. In practise it will be difficult with big enough (degree 5 or
more) polynomials and various transcendental functions. In many cases,
you know one is algebraic and the other transcendental and therefore
they must be unequal.

Those known to be unequal can be expanded in binary until you know
which is smaller, and you know it will take finite time.
Those known to be equal can be treated as such.
The remaining ones can be expanded in binary up to a point and in the
majority of cases you'll quickly find one is less than the other.
Only ones close enough together and difficult to tackle analytically
remain. The policy with them might be to give them an arbitrary but
deterministic ordering perhaps based on class and internal
representation, or hashCode, or something.

Even ones known to be equal that are not equals() should be treated in
that last way to fit the contract of Comparable...unless equals()
should work "properly" across all Number subclasses.

It is admittedly a complex issue. Perhaps leaving it up to those
mixing types to convert them manually and then compare them (e.g. an
Integer and a Double by converting the Integer to another Double
first) is best after all.

 

[Patricia Shanahan]

Explain please.


Do not bluntly contradict me in a public forum.

Shrug. Different people have different preferences, so it is hard for
writers to keep track. I'm here to learn, as well as to pass on any
relevant insights I have, so if someone disagrees with me I *want* them
to say so, simply and directly. I won't be offended as long as they
explain their reasoning, so that I can either be convinced and learn, or
be able to explain why I disagree with their reasoning.

There's an equation that can in principle be solved to see if they are
equal. In practise it will be difficult with big enough (degree 5 or
more) polynomials and various transcendental functions. In many cases,
you know one is algebraic and the other transcendental and therefore
they must be unequal.

I think you may be underestimating the difficulties of dealing with
general real numbers. In many cases we can calculate the value to any
required finite number of decimal, or binary, places. That is enough to
give the order for two unequal values, but not enough to ever be able to
declare equality.

Even if a class represents values of some transcendental function there
can be some points at which the function has an algebraic solution. For
example, consider the sines of angles that can be expressed as rational
numbers of degrees. sin(30), sin(45), and sin(60) are exact solutions to
quadratic equations.

One could write a comparator between sines and quadratic equation
solutions by special casing angles that are exact multiples of three
degrees, and then calculating the binary expansions of the other values
until there is a difference.

However, to make Number implement Comparable we would need a general
approach to comparing that does not depend on writing special code for
every pair of Number subclasses.

Here's a challenge for those who want to make Number implement
Comparable<Number>. Write the API documentation for the compareTo
method. Tell me what I have to do if I am writing a new Number subclass
in order to conform to the contract.

Patricia

 

[Twisted]

Even if a class represents values of some transcendental function there
can be some points at which the function has an algebraic solution. For
example, consider the sines of angles that can be expressed as rational
numbers of degrees. sin(30), sin(45), and sin(60) are exact solutions to
quadratic equations.

To clarify, when I said above that transcendental and algebraic were
unequal I meant individual numbers where one's known to be
transcendental and the other algebraic.

The trig values that are algebraic are well-characterized aren't they?
So knowing which are not transcendental is not impossible.

However, to make Number implement Comparable we would need a general
approach to comparing that does not depend on writing special code for
every pair of Number subclasses.

Here's a challenge for those who want to make Number implement
Comparable<Number>. Write the API documentation for the compareTo
method. Tell me what I have to do if I am writing a new Number subclass
in order to conform to the contract.

The simplest most general way is to convert to BigDecimal and punt to
BigDecimal.compareTo, with precision decided by something (perhaps
something new) in the way of a MathContext-like entity. It couldn't be
passed to the compareTo method obviously so it would have to be a
threadlocal or something (a singleton would cause problems if distinct
threads did simultaneous math and wanted distinct precisions).

Ones that don't compare equals() have to be treated as distinct, so
give a nonzero compareTo, and I think objects of different Number
direct-subclasses never compare equals(). If they all have sensible
implementations of hashCode() too, the thing to do would be:

In class Foo, see if the argument is also a Foo. If so, use a suitable
comparison within Foos. Otherwise, get BigDecimal versions at the
context-determined precision and compare those. If nonzero return the
result. If zero compare the hashCodes. If nonzero return the result.
If still zero ... should be damned rare, but I dunno what. Actually
forget hash codes; in the case the arguments are of different Number
direct-subclasses just use the lexical ordering of
a.getClass().toString() and b.getClass().toString(), which should be
different. Using a locale-independent collation!

But I think at this point the best thing is probably to leave things
as is, and users of mixed Number types can convert to a common type
manually to do comparisons. Implementing Number.compareTo(Number) in
general is only warranted if people are liable to be stuffing a
heterogeneous mix of Numbers into a TreeMap as keys or something. And
since they all implement hashCode sensibly, so far as I'm aware,
HashMap is probably the better choice for that anyway, leaving cases
where you want a collection (e.g. TreeSet) to iterate over a
heterogeneous mix in sorted order. For that a wrapper suffices:

public class NumberWrapper implements Comparable<NumberWrapper> {
private Number delegate;
private int bigDecimalDigitPrecision;
// obvious constructor and getNumber()
// obvious hashCode punts to delegate
// obvious equals returns false if arg not a NumberWrapper,
// then unwraps both and punts to delegates
public int compareTo (NumberWrapper nw) {
if (delegate.getClass().equals(nw.delegate.getClass())) {
// Insert suitably clever use of reflection to call
// delegate.compareTo(nw.delegate) with both cast to
// the appropriate subclass. Making the above if
// trigger if delegate classes differ but have
// common ancestor deeper than Number left as an
// exercise for the reader.
return ...
}
BigDecimal t1 = // May need reflection here too, or for
// Sun to put a bigDecimalValue(precision) in Number
BigDecimal t2 = // Ditto, with nw.delegate
int result = t1.compareTo(t2);
if (result != 0) return result;
return delegate.getClass().toString().compareTo(
nw.delegate.getClass().toString());
}
}

The major issues apparent are:
* The wrapper will heavily need reflection, somewhat less if Number
were changed non-drastically. Adding bigDecimalValue(precision)
to Number would go a long way. Adding a compare(Number) that may
throw if the class isn't the same would help enormously.
* The wrappers can hold the precision to use, but may act up if
ones with different precisions were mixed.
* OTOH not using the wrappers seems to require either hard-coding
the precision (evil!) or using a ThreadLocal (slow!)

Fortunately I think putting heterogeneous Numbers into a sorted
collection is really damn rare.

 

[Patricia Shanahan]

The simplest most general way is to convert to BigDecimal and punt to
BigDecimal.compareTo, with precision decided by something (perhaps
something new) in the way of a MathContext-like entity. It couldn't be
passed to the compareTo method obviously so it would have to be a
threadlocal or something (a singleton would cause problems if distinct
threads did simultaneous math and wanted distinct precisions).

This could lead to some very strange effects. You could have two
numbers, x and z, that are different according to the comparison rules
for their own class, but that match to the Number comparison precision.

x.compareTo(z) would be non-zero. However, there could be a third
Number, y, of a different Number subclass, such that y.compareTo(x) and
y.compareTo(z) are both zero.

Fortunately I think putting heterogeneous Numbers into a sorted
collection is really damn rare.

The killer argument for not having Number implement Comparable.

If a given Number subclass has a reasonable total order it can implement
its own intra-class comparison. For example, Double implements
Comparable<Double>, and BigDecimal implements Comparable<BigDecimal>.

If there is a need, and a good implementation, for a total order on a
collection containing a couple of different Number subclasses, one could
write a Comparator that handles that combination of classes, using
appropriate special rules.

I think this approach deals with all the real cases, without opening
up the general Number comparison can of worms.

Patricia

 

[Michael Jung]

Explain please.

Typically: if a>0 then 0<-a.

Do not bluntly contradict me in a public forum.

I gave an explanation. Otherwise Patricia gave an appropriate reply.

There's an equation that can in principle be solved to see if they are
equal. In practise it will be difficult with big enough (degree 5 or
more) polynomials and various transcendental functions. In many cases,
you know one is algebraic and the other transcendental and therefore
they must be unequal.

For one, we are ordering, not checking for equality alone. You might possibly
find an intricate way of comparing the smallest real roots of uneven
polynomials (arbitrary degree). Take results of other functions that are not
easily computed, but have interesting features to make them Numbers in a Java
sense. Transcendental and algebraicness doesn't have anything to do with it.

Those known to be unequal can be expanded in binary until you know
which is smaller, and you know it will take finite time.

This assumes that they can be computed in this way. You may also consider
extremely huge (factored) numbers, which in theory can be compared and
computing it is totally unfeasible.

Only ones close enough together and difficult to tackle analytically
remain. The policy with them might be to give them an arbitrary but
deterministic ordering perhaps based on class and internal
representation, or hashCode, or something.

As Patricia has pointed out this leads to counterintuitive results and
basically makes the whole comparing business obsolete.

Michael

 

[Twisted]

Typically: if a>0 then 0<-a.

I don't know where to begin in trying to figure out what kind of drugs
you either are taking but shouldn't or aren't taking but should
here.

I gave an explanation.

I said something and your response was a blunt "No", which is rude.

For one, we are ordering, not checking for equality alone.

You forgot that the main issue was in fact the "checking for equality"
part. Comparing binary expansions of known-unequal numbers eventually
and fairly trivially yields their order.

This assumes that they can be computed in this way. You may also consider
extremely huge (factored) numbers, which in theory can be compared and
computing it is totally unfeasible.

A number represented as a product of factors? Those are dead *easy*.
Even if you don't first multiply them to get a plain BigInteger or
whatever. You can estimate magnitude and know x < 10^y < this product
for instance in many cases. Comparing them to each other can start
with dropping common factors and comparing only what's left,
especially easy if your internal representation is the prime
factorization.

[snip remainder of attack]

This bickering is pointless. Have you nothing more constructive to do
than try to tear down other people here?

 

[Patricia Shanahan]

You forgot that the main issue was in fact the "checking for equality"
part. Comparing binary expansions of known-unequal numbers eventually
and fairly trivially yields their order.

Actually, there are two problems. I've been focusing on the sub-case in
which, for each operand, there is a feasible, efficient algorithm for
generating the next block of digits of the decimal expansion. Even in
that case, the problem of equality checking remains.

The other case is where is no efficient decimal expansion algorithm.
Either there is no algorithm at all, or it takes too much time and/or
space to run it. It think that is the case Michael Jung is pursuing.

A number represented as a product of factors? Those are dead *easy*.
Even if you don't first multiply them to get a plain BigInteger or
whatever. You can estimate magnitude and know x < 10^y < this product
for instance in many cases. Comparing them to each other can start
with dropping common factors and comparing only what's left,
especially easy if your internal representation is the prime
factorization.

The devil is in the word "huge". In this context I would treat it as
meaning "too big for brute force to be practical".

Patricia

 

[Michael Jung]

I don't know where to begin in trying to figure out what kind of drugs
you either are taking but shouldn't or aren't taking but should
here.

I assume you can correct the mistyping. The point remains valid.

You forgot that the main issue was in fact the "checking for equality"
part. Comparing binary expansions of known-unequal numbers eventually
and fairly trivially yields their order.

See below and Patricia's answer.

A number represented as a product of factors? Those are dead *easy*.
Even if you don't first multiply them to get a plain BigInteger or
whatever. You can estimate magnitude and know x < 10^y < this product
for instance in many cases. Comparing them to each other can start
with dropping common factors and comparing only what's left,
especially easy if your internal representation is the prime
factorization.

You have a good algorithm at hand that compares
(2^(2^n)-2^(2^m-1))(2^(2^n)+2^(2^m+1)) and 2^(2^(n+1))-2^(2^(m+1)-1)? Note
that this has two parameters only and IS easy. But if I know your algorithm,
I'll add some more in there to break it. (n,m > 10^6) I am not a number
cruncher, but be sure that there are non-trivial problems in that domain.

Three points against forcing comparability on numbers:

1. Checking for equality may be non-trivial, let alone ordering. Let alone
computational.

See above.

2. For some numbers comparability may be pointless.

The complex numbers have been mentioned, but there are numbers naturally
embedded into the reals, where you don't want that. Consider the numbers
{0,1,2} with typical addition/multiplication all done with the remainder
operation. This (e.g.) means -1 = 2. Ordering them is senseless.

3. Some comparability operations are counterintuitive, when embedded into the
standard ones.

Suppose you have the positive reals and compare them via integer part, i.e. "x
gt y <=> int(x) > int(y)". That still has nice properties, possibly
sufficient for your purposes, may be more easy to compute (see above), etc.
However several numbers are equal, which you wouldn't naturally consider so.
E.g. x eq y does not imply 2*x eq 2*y.

Some of these arguments side in with the argument that you need to be able to
supply comparability with arbitrary number implementations thereby getting
even more counterintuitive results, since basically you are restricted to the
interface methods of Number when comparing with other numbers.

Michael

 

[Patricia Shanahan]

Michael Jung wrote:
....

Some of these arguments side in with the argument that you need to be able to
supply comparability with arbitrary number implementations thereby getting
even more counterintuitive results, since basically you are restricted to the
interface methods of Number when comparing with other numbers.

....

This brings out one assumption I have been making silently, that one or
more abstract helper methods could be added to Number, requiring them to
be implemented in every concrete subclass of Number.

For example, if a solution were based on generating digits of the
decimal expansion:

public abstract Iterator<Byte> digitIterator();

where the digitIterator result supplies successive digits of the decimal
expansion.

The conclusion I have reached, based on the discussion, is that there is
no set of methods that could be implemented in all reasonable subclasses
of Number that would be sufficient to implement Comparable<Number> in a
meaningful, useful way.

Patricia

 

[Twisted]

The other case is where is no efficient decimal expansion algorithm.
Either there is no algorithm at all, or it takes too much time and/or
space to run it. It think that is the case Michael Jung is pursuing.

I considered that in another branch of this thread.

The devil is in the word "huge". In this context I would treat it as
meaning "too big for brute force to be practical".

That's why I suggested non-brute-force methods such as canceling
common factors.

 

[Twisted]

I assume you can correct the mistyping. The point remains valid.

There was a point? If NaNs are in your calculation it's already gone
haywire. At least it won't outright blow up if they get into a TreeSet
this way. If you want to throw on NaN you want to do so as soon as a
NaN is produced, and if not, you want NaN to have well-defined (if
perhaps strange) semantics.

You have a good algorithm at hand that compares
(2^(2^n)-2^(2^m-1))(2^(2^n)+2^(2^m+1)) and 2^(2^(n+1))-2^(2^(m+1)-1)?

Those aren't pure factorizations; they have additions and subtractions
in them. We were discussing numbers represented like 2^a3^b5^c...

Please don't try to change the playing field out from under the
players in the middle of the game; that's considered cheating.

2. For some numbers comparability may be pointless.

The complex numbers have been mentioned

Hence why quite early we'd all agreed that a RealNumber subclass would
be a better target for making comparable.

but there are numbers naturally
embedded into the reals, where you don't want that. Consider the numbers
{0,1,2} with typical addition/multiplication all done with the remainder
operation. This (e.g.) means -1 = 2. Ordering them is senseless.

And they are not, contrary to your claim, "naturally embedded into the
reals". If you think there's any kind of homomorphism from the reals
onto any finite field you need to get your head examined.

3. Some comparability operations are counterintuitive, when embedded into the
standard ones.

Suppose you have the positive reals and compare them via integer part, i.e. "x
gt y <=> int(x) > int(y)". That still has nice properties, possibly
sufficient for your purposes, may be more easy to compute (see above), etc.
However several numbers are equal, which you wouldn't naturally consider so.
E.g. x eq y does not imply 2*x eq 2*y.

That is the sort of comparison you perform explicitly on floor(x) or
round(x) or something, rather than make the natural compareTo() order
of a type. And so irrelevant here.

 

[Twisted]

The conclusion I have reached, based on the discussion, is that there is
no set of methods that could be implemented in all reasonable subclasses
of Number that would be sufficient to implement Comparable<Number> in a
meaningful, useful way.

I happen to think it is probably better to expect users of
heterogeneous Numbers to manage conversion for intercomparison
themselves. I'm not sure quite how I got stuck having to defend the
possibility of doing it directly with compareTo() in (Real)Number, and
I wouldn't mind not being hounded on the matter any further. It's
possible; it's probably not at all easy and would require lots of
special compare code in each subclass; it would likely be hackish and
kludgy in places; and it's better off avoided. 'Nuff said.