(j3.2006) decimal floats

[Bill Long]

Jim Xia wrote:
>
> 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.

Probably not ironic at all.  The rest of us were just going to return -5 
for selected_real_kind(radix=10, ...) in the front end and be done with it.

>
> 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.

But consider your example of x+y.  Suppose kind=3 is 32-bit DFP and 
kind=4 is 32-bit binary floating point, and the declarations

real(3) :: x
real(4) :: y

Then one could always write expressions like

real(x,4) + y
x + real(y,3)

one of which would mean exactly the same thing as

x+y

I really don't see the advantage of making the user supply all the 
real(xxxx) decoration.  This would seem quite inconsistent with the 
normal Fortran conventions and unexpected by users.

Don't misinterpret this example as enthusiasm for supporting decimal 
floats.  Any implementation that actually has to implement a new real 
kind (any kind) faces an enormous task of writing new versions for all 
the intrinsics that take real arguments.  For intrinsics like 
dot_product, multiple new versions. Ugh.

Cheers,
Bill





>
> 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-- 
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