(j3.2006) decimal floats

[Jim Xia]

Well, it seems that I'm the only one has concerns with the decimal real 
feature.  This may seem ironic given the fact that IBM has the only 
hardware support on DFP, well ..., unless you look harder at the issues.

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.

Any thoughts are welcome.

Cheers,

Jim Xia

XL Fortran Compiler Testing
IBM Toronto Lab at 8200 Warden Ave.
Phone (905) 413-3444  Tie-line 313-3444
D2/NAH/8200 /MKM

j3-bounces at j3-fortran.org wrote on 01/10/2008 11:49:57 AM:

> Jim Xia wrote:
> >
> > > And the vendors are still complaining that there's too much to do.
> >
> > Yes, there's too much to do already.  Breaking the 
> > backward-compatibility is always a bad thing to vendors, not to 
> > mention the proposed change brings no new functionality to these two 
> > intrinsics.  Use KIND argument in cmplx to solve Van's problem.  I'll 
> > be happy to remove the radix feature in selected_real_kind, which is 
> > really not done right :-)
> >
> 
> I used to be in favor of removing this as well.  Malcolm's arguments 
> convinced me that having two competing formats does not affect whether 
> selected_real_kind with radix= is useful.  We have had similar 
> environments in the past (non-ieee formats such as legacy Cray, DEC, 
> etc.)  and selected_real_kind worked just fine.  It has been recently 
> pointed out to me that the latest AMD ABI requires  support for  decimal 

> floating point (Intel format, I assume).  I sense that this is coming 
> whether we want it or not,  and the Fortran 2008 standard is the place 
> to add the support.  If we wait until the next revision, we'll be quite 
> a bit behind the curve.  Even though the proprietary hardware targeted 
> by our compiler does not support decimal floats, I've none the less put 
> in a request to the compiler writers to reserve two KIND values for use 
> in the future  (3 for 32-bit decimal floats, and 6 for 64-bit.)
> 
> If you are convinced the current spec is not done right, I'd refer to 
> fix it, rather than deleting the feature.
> 
> Cheers,
> Bill
> 
> 
> 
> -- 
> Bill Long                                   longb at cray.com
> Fortran Technical Support    &              voice: 651-605-9024
> Bioinformatics Software Development         fax:   651-605-9142
> Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080111/b7290e91/attachment.html