(j3.2006) decimal floats

[Robert Corbett]

Jim Xia wrote:
> 
> Well, it seems that I'm the only one has concerns with the decimal real 
> feature.

No.  I expressed concerns about it to Sun's representative to the
committee months ago.

> This may seem ironic given the fact that IBM has the only 
> hardware support on DFP, well ..., unless you look harder at the issues.

That tends to be so.  A working implementation is likely to turn
up problems that no amount of design and planning would reveal.

> For one, the binary representation for decimal floating point is quite 
> different from that for binary float in that it has four parts instead 
> of 3 segments in binary case.  Also not all valid binary combinations 
> are used in DFP.  This leaves a noted asymmetrical range of values for 
> DFP.  I'm not certain these properties can be correctly represented by 
> our (I mean FORTRAN's) numeric model.  I'll leave that question to the 
> mathematicians to figure out since I'm not an expert on it.
> 
> Even if it is correctly covered by FORTRAN numeric model for real, then 
> there are issues in mixing binary real and decimal real in operations. 
>  Fortran's rules are clear in that the conversions are always towards 
> the higher precision.  So conversion between binary and decimal is 
> required in an operation.  This is a very, I mean very, expensive 
> operation (may take up to 2000 cycles!).  Unless a programmer is so 
> certain that she demands the mixing of binary with decimal, we'd better 
> not to allow it at all.  And in fact the C standard does not allow 
> operations, like x + y, between binary and decimal.  It seems Fortran 
> committee is far too liberal in allowing this to happen.  Another issue 
> with conversion between binary and decimal is loss of precision. 
>  Fortran's rule on insisting greater precision is to aid preservation 
> for precision, as I believe.  This is not so for conversions between 
> binary and decimal -- many decimal floats can not be precisely 
> represented by binary, and vice versa.
> 
> So if we have to keep the decimal float as a part of F2008, then our 
> best choice is to ban the mixing between binary and decimal.  I'm 
> considering submitting a proposal for the next J3/WG5 meeting just for 
> that.

I agree that implicit conversions should be banned.  There should be
functions for explicit conversions.  I suspect that most people do not
understand how expensive radix conversions are, especially for large
exponents.

Some people on the committee think arithmetic should be done in the
format used to represent values in memory.  That could create problems
for programs that use IEEE 754r's storage format such as binary16 and
decimal32.

Bob Corbett