Re: mixed decimal floating and binary floating arithmetic

[Michel Hack <hack@xxxxxxxxxxxxxx>]

There are good reasons for not supporting automatic mixed-radix
type coercions.  The latter works well only for strict supersets,
which would imply an unreasonably large type (e.g. Decimal2688,
if Binary64 needs to be accomodated).  In practice one might use
the widest supported DFP format, e.g. Decimal128, but it is usually
application-dependent which common format is the appropriate one to
use -- and hence the desire for explicit casts.

The one operation that *could* have been supported is comparisons,
because mixed-radix comparisons *can* be exact if implemented as
primitives (i.e. NOT by converting to a common practical format).
That's because any implied conversion needs to be carried out only
far enough to resolve the ordering -- frequently not far at all.
I was even prepared to design a machine instruction for doing this,
as a variant of the one I implemented for FP radix conversions.

I had proposed a motion to this effect, and it was in fact accepted,
(June 2006) but two months later another motion was passed that moved
it to "purple text" (P754 WG draft lingo) -- and in the end (don't
remember when) all purple text was dropped from the standard.

My motion did not require mixed-radix comparisons, but stated that
if they were provided they had to be correct.

The saving grace is that the prohibition of mixed-radix operations,
when extended to comparisons, avoids implictly-incorrect comparisons.
The programmer is forced to use a cast, and hence to assume full
responsibility for the effects thereof.

Michel.
---Sent: 2009-04-15 20:55:42 UTC