Hmmm....

	I like the idea of an implementation able to represent
more numbers exactly.  An "Nth Power of M" exact representation,
where N and M are allowed to be any integer, would add much of
that subset of the number line resulting from ordinary computation
to the numbers exactly representable.  I think that is an
unequivocally good thing.

	The implementor of such an implementation would need to
take great care when writing procedures to perform comparisons
among exact numbers, but the problem is not insoluble.

	At the moment, though, we're discussing inexact numbers
in IEEE-ish mantissa-exponent style notation, but of differing
lengths.  And my personal take on that is, rather than treat
each number as a "neighborhood" I'd prefer to treat it as a
"point" on the number line.  This allows a very specific kind
of inconsistency, but that inconsistency happens for good and
comprehensible reasons, and "hiding" it may sometimes hide
important information.

Example of inconsistency:  Consider two computations, A and B,
that yield results a and b such that a > b, but by a very small
amount.  If a is stored in a short, forcing a round down, and b
is stored in a short, forcing a round down (but not as much),
then (= a b) ==> #t, even though the computations A and B return
different values.

If a is stored in a short, forcing a round down, and B is stored
in a long, forcing a (*MUCH* smaller) round up or down, then
(> b a) ==> #t, even though B gives a value strictly less than A
when carried out to the same precision.

But I think this kind of "inconsistency" is both reasonable and
expected by anyone who would have a reason to specify that the
results should be given in a specific floating-point format, and
efforts to "avoid" it can only result in inconsistencies of a
less understood or less expected kind, possibly reducing the
utility of extended float formats by crippling comparisons
against them.

				Bear