Mixed-radix comparisons (was: ...level 2 datums)
Dan Zuras gave an excellent description of the issues involved.
The large number of bits cited by Dan was however for the exact
integer representation of the comparison (basically, it comes
from the number of decimal digits needed to express any BFP
value exactly (that value being Nmin-Dmin for the BFP format).
This is however overkill for comparison, where the precision
needed to discriminate between any two values, one BFP and the
other DFP, is the sum of the precisions (expressed in bits) plus
a value derived from Continued Fraction theory, based on the
exponent range of the formats involved. This is about 24 bits
for the 754-2008 basic formats (where binary128 vs decimal128
is the worst case), so we need about 250 bits in the worst case.
Of course, the vast majority of comparisons are trivial, so an
implementation would dispatch those cases quickly. For the rest,
there are several possibilities: use density considerations to
decide which operand to convert to the other's format, or convert
both to a common format a*2**b*10**d with increasing resolution
until a difference becomes clear.
It is this technical complexity that led me to propose the motion
that if mixed-radix comparisons are allowed, they should be
available as correct primitives. (One tricky issue is that
comparisons are not allowed to overflow or underflow, which is
why they are not equivalent to checking the sign of a difference.)
Michel.
---Sent: 2010-10-06 14:48:33 UTC