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.

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.

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. :P

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

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.

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?