(j3.2006) decimal floats
Fri Jan 11 16:52:28 EST 2008
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.
XL Fortran Compiler Testing
IBM Toronto Lab at 8200 Warden Ave.
Phone (905) 413-3444 Tie-line 313-3444
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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3