www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - FloatingPoint in D

reply BCS <ao pathlink.com> writes:
Can any D implementation be assumed to use IEEE-768? In other words: can 
I safely build floats and double from bits and expect it to work on an
arbitrary 
compiler including ones that don't exits yet?

I guess a corollary is, are there any platforms that D is likely to be used 
on that have a hardware FP system *other* than IEEE-768?
Mar 13 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
BCS wrote:
 Can any D implementation be assumed to use IEEE-768? In other words: can 
 I safely build floats and double from bits and expect it to work on an 
 arbitrary compiler including ones that don't exits yet?
 
 I guess a corollary is, are there any platforms that D is likely to be 
 used on that have a hardware FP system *other* than IEEE-768?

There is exactly one Google hit for '"ieee 768" floating point'[1], which to me indicates one of two possibilities: 1) It's a _really_ unpopular standard ;). 2) There is no such thing as IEEE-768 or it has nothing to with floating point, and either (a) there is approximately one other person who thinks, like you, there is or (b) approximately nobody else thinks so and your name is Steve Harris ;). (All of this, of course, assumes Google is correct in finding no more matches, which may or may not be true :P) The D spec page on floating point[2] specifies that all operations should comply with IEEE-754 rules (did you perhaps mean _that_ standard?), but AFAICT that page doesn't actually specify the format of values when stored in memory. So unless a specific storage format is required by IEEE-754, assuming any particular binary format may not be portable. (Note: I have no idea what IEEE-754 specifies, exactly) Also, there was also some mention a while back that GDC always defines 'real' as the local C 'long double' type, which in the case of the port for PPC turns out to be a weird format consisting of two doubles used to represent a single value. There was some discussion regarding what to do about this, but I can't offhand remember the outcome. IIRC it was in D.gnu, in the announcement thread for GDC 0.23. [1]: http://www.google.com/search?q=%22ieee+768%22+floating+point&btnG=Search&hl=en [2]: http://www.digitalmars.com/d/float.html
Mar 13 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Frits,

 BCS wrote:
 
 Can any D implementation be assumed to use IEEE-768? In other words:
 can I safely build floats and double from bits and expect it to work
 on an arbitrary compiler including ones that don't exits yet?
 
 I guess a corollary is, are there any platforms that D is likely to
 be used on that have a hardware FP system *other* than IEEE-768?
 


<Justified but un-needed bashing of my memory> <G>
 The D spec page on floating point[2] specifies that all operations
 should comply with IEEE-754 rules (did you perhaps mean _that_
 standard?), 

yes
 but AFAICT that page doesn't actually specify the format
 of values when stored in memory. So unless a specific storage format
 is required by IEEE-754, assuming any particular binary format may not
 be portable. (Note: I have no idea what IEEE-754 specifies, exactly)
 

IEEE-754 does spec the bit pattern for 32 & 64 bit FP values
 Also, there was also some mention a while back that GDC always defines
 'real' as the local C 'long double' type, which in the case of the
 port for PPC turns out to be a weird format consisting of two doubles
 used to represent a single value. There was some discussion regarding
 what to do about this, but I can't offhand remember the outcome. IIRC
 it was in D.gnu, in the announcement thread for GDC 0.23.
 
 [1]:
 http://www.google.com/search?q=%22ieee+768%22+floating+point&btnG=Sear
 ch&hl=en [2]: http://www.digitalmars.com/d/float.html
 

real will be a pain however it's cut because even in x86 where it is 80bit IEEE-754 doesn't define an exact bit pattern. So I'm thnking the result is: D floating point can be assumed to use IEEE-754.
Mar 13 2007
parent reply Don Clugston <dac nospam.com.au> writes:
BCS wrote:
 Can any D implementation be assumed to use IEEE-768? In other words:
 can I safely build floats and double from bits and expect it to work
 on an arbitrary compiler including ones that don't exits yet?

 I guess a corollary is, are there any platforms that D is likely to
 be used on that have a hardware FP system *other* than IEEE-768?



Not many non-IEEE 754 systems exist any more. The most notable exception is some Cray systems. (actually, AMD's 3DNow! also isn't IEEE 754 compliant.).
 real will be a pain however it's cut because even in x86 where it is 
 80bit IEEE-754 doesn't define an exact bit pattern.

Yes, but it specifies several aspects of it -- significand must be continuous, exponent must be continuous. There's not much room to move. (a) IEEE 754R specifies the storage of 128-bit reals, and they are identical to x86 80-bit reals, except that the significand has some trailing zeros. (x86 80-bit reals are a poor-man's quadruple). (b) AFAIK, the only systems with 80-bit reals are x86, Itanium, and 68K, and they are all identical. So in practice, it's a de-facto standard, and 754R will goes a long way towards standardising it. The only hardware implementations of 'real' are 64-bit double, 80-bit x86-compatible (with or without implicit bit), and 128-bit quadruple (which is binary defined on some Sparc systems, but not implemented on any hardware AFAIK). Itanium also has an 81-bit real, but it's only used by the OS to provide fast implementations of 80-bit hypot() and similar functions - I think it's technically not IEEE compliant. In practice, the situation is not nearly as bad as it appears.
 So I'm thnking the result is: D floating point can be assumed to use 
 IEEE-754.

Yes.
Mar 14 2007
parent BCS <ao pathlink.com> writes:
Reply to Don,

 BCS wrote:
 
 Can any D implementation be assumed to use IEEE-768? In other
 words: can I safely build floats and double from bits and expect it
 to work on an arbitrary compiler including ones that don't exits
 yet?
 
 I guess a corollary is, are there any platforms that D is likely to
 be used on that have a hardware FP system *other* than IEEE-768?
 



exception is some Cray systems. (actually, AMD's 3DNow! also isn't IEEE 754 compliant.).
 real will be a pain however it's cut because even in x86 where it is
 80bit IEEE-754 doesn't define an exact bit pattern.
 

continuous, exponent must be continuous. There's not much room to move. (a) IEEE 754R specifies the storage of 128-bit reals, and they are identical to x86 80-bit reals, except that the significand has some trailing zeros. (x86 80-bit reals are a poor-man's quadruple). (b) AFAIK, the only systems with 80-bit reals are x86, Itanium, and 68K, and they are all identical. So in practice, it's a de-facto standard, and 754R will goes a long way towards standardising it. The only hardware implementations of 'real' are 64-bit double, 80-bit x86-compatible (with or without implicit bit), and 128-bit quadruple (which is binary defined on some Sparc systems, but not implemented on any hardware AFAIK). Itanium also has an 81-bit real, but it's only used by the OS to provide fast implementations of 80-bit hypot() and similar functions - I think it's technically not IEEE compliant. In practice, the situation is not nearly as bad as it appears.
 So I'm thnking the result is: D floating point can be assumed to use
 IEEE-754.
 


Good. I guess as counter cases are found static asserts or ifs can be used.
Mar 14 2007
prev sibling next sibling parent reply Andreas Kochenburger <akk nospam.org> writes:
BCS wrote:
 Can any D implementation be assumed to use IEEE-768? In other words: can 
 I safely build floats and double from bits and expect it to work on an 
 arbitrary compiler including ones that don't exits yet?
 
 I guess a corollary is, are there any platforms that D is likely to be 
 used on that have a hardware FP system *other* than IEEE-768?
 
 

You're sure it ain't IEEE 754 ?? -- Andreas ------- MinForth: http://minforth.net.ms/
Mar 13 2007
parent BCS <ao pathlink.com> writes:
Reply to Andreas,

 BCS wrote:
 
 Can any D implementation be assumed to use IEEE-768? In other words:
 can I safely build floats and double from bits and expect it to work
 on an arbitrary compiler including ones that don't exits yet?
 
 I guess a corollary is, are there any platforms that D is likely to
 be used on that have a hardware FP system *other* than IEEE-768?
 


In fact I"m shure it /is/ IEEE 754, but enough about how bad my memory is <g>.
Mar 13 2007
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
BCS wrote:

 I guess a corollary is, are there any platforms that D is likely to be 
 used on that have a hardware FP system *other* than IEEE-768?

Currently GDC uses a non-IEEE type for "real" on non-X86 platforms, but it is being revised for GDC 0.24 ("real" will go back to double) Only applies to D "real" / C "long double", so float/double are fine. --anders
Mar 13 2007