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

[Michel Hack <hack@xxxxxxxxxxxxxx>]

The new purple prose is useful indeed, but we run into the objections of
IEEE editors...

>   This standard discourages implicit "widening" to narrower formats,
>   because of the propensity for programming error, and discourages
>   allowing mixed radices, because of the very high cost of widening
>   to a common type.  ]

That's precisely why I had proposed an explicit mention of mixed-radix
comparisons in June 2005 (it was accepted at the time, but removed later),
stressing that IF mixed-radix comparisons are supported (they were not
required), they have to be performed on the exact values, and NOT obtained
by converting one (or even both) to a common radix (unless that common
format was a true superset in both radices, which would have to be a very
wide decimal format, e.g. 11503-digit decimal if binary128 is supported).

In practice, mixed-radix comparison is performed by using partial radix
conversion sufficient to distinguish the values, with most cases being
decided very rapidly, and only nearly-identical values being troublesome.
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.)

Michel.

Sent: 2008-01-30 14:54:02 UTC