Comments on David Hough's proposed ballot submissions -- comparisons

[Michel Hack <hack@xxxxxxxxxxxxxx>]

Earlier I wrote:

| In that case there is never a need to exceed the highest operand precision
| by much (by at most 20 bits, I think, if the widest supported formats are
| binary128 and decimal128; I would have to check my Continued-Fraction
| analysis records).  (To be honest, the same reasoning can be used to show
| that a common format of 43 decimal digits should be sufficient, but I'd
| have to think about this a bit more to be 100% sure.  In any case, ALWAYS
| converting to 43 decimal digits would indeed be extravagant.)

That's NOT ENOUGH -- the required precision may be as high as the
SUM of the two input precisions, plus the CF-derived extra of twenty
bits.  This would be 250 bits, or 76 digits (not 43), when comparing
binary128 and decimal28.

It is conceivable that shortcuts can be taken (in the worst case --
it is clear that shortcuts can and would be taken in the common case)
for comparisons relative to actual correctly-rounding conversions, e.g.
by converting in both directions at the same time until a difference
can be confirmed, but I stopped studying this in detail after we decided
to drop mixed-radix comparisons and started actively to discourage them.
They are illegal in the DFP-revised C99 proposal, for example.

It gets even worse when arithmetic is being considered, e.g. subtraction
of two nearly-identical different-radix values, because of catastrophic
cancellation.   This looks like an interesting exercise, but I think
that at least 365 bits (if not 500) might be required here.  In other
words, there is ample justification for the prohibition of mixed-radix
arithmetic expressions.

Michel.
Sent: 2008-01-30 17:07:50 UTC