RE: mixed decimal floating and binary floating arithmetic

["Steven Hobbs" <Steven.Hobbs@xxxxxxxxxxxxxxxx>]

Malcolm Cohen says:

> Steven Hobbs wrote:
> > The statement that Fortran always has allowed mixed mode is not true.
> >   
> Yes it is - it has always allowed mixing all kinds of floating-point
(at 
> least in the standard).  You are right that mixing integer and real in

> an expression "only" goes back 31 years (in the standard).  Of course 
> prior to Fortran 90 the standard only supported two kinds of  
> floating-point (single and double precision) though compiler support
for 
> more kinds than that was not that uncommon.

I take it that American National Standard X3.9-1966 USA Standard FORTRAN
(and ANS X3.10-1966 USA Standard Basic FORTRAN) were not Fortran
standards.  The FORTRAN-66 standard outlawed mixed integer and
floating-point except for certain exponentiations.  The standard also
outlawed mixed double-precision and complex because neither was a subset
of the other.  (See the last paragraph of section 6.1 of ANS X3.9-1966)

Although I think the result type of decimal64+binary64 should probably
be decimal64 because decimal64 has a greater range and the precisions
are almost equal, "decimal precision" must be carefully defined to
whether decimal64 or binary64 has the greater the precision.

Consider the decade of values between 1E15 and 9.99...E15.  For values
between 1E15 and 1.125E15, nextUp(bin) will take 8 increments for each
single increment of nextUp(dec), for binary64 bin and for decimal64 dec;
for values between 1.126E15 and 2.251E15, nextUp(bin) will take 4
increments for each single increment of nextUp(dec); for values between
2.252E15 and 4.503E15, nextUp(bin) will take 2 increments for each
single increment of nextUp(dec); for values between 4.504E15 and
9.007E15, both nextUp(bin) and nextUp(dec) will increment in lock-stop
through the integer values in this range; and for values between
9.008E15 and 9.999E15 nextUp(dec) will take two increment for each
single increment of nextUp(bin).  Since there are more binary64 values
represented in this decade then, with some definition of decimal
precision, it could be argued that binary64 has more precision than
decimal64.  People who remember slide rules will also know that
precision between 1 and 4 is much more important than precision between
9 and 10.

However, IEEE-754 recommends that languages implement extended and
extendable precisions.  What is the correct answer for an intermediate
type when the largest binary-extended has very much more precision but
also very much less range than the largest decimal-extended.  Should
IEEE-754 have outlawed such implementation choices for extended
precision?  Should language standards outlaw such implementation choices
for extended precision?  In this case should languages require the
source code to include explicit conversions while allowing implicit
conversions the interchange formats?

I do not think the answers to these questions are easy.

--Steven Hobbs