www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - IEEE 754r Forthcoming Floating Point Formats

reply "Bob W" <nospam aol.com> writes:
Just read the new P754 draft. Although I cannot imagine
that they'll present us a new standard anytime soon,
but from what I have seen they might bless us with
the following formats:

Binary 16 (new, probably a tribute to gamers ?)
Binary 32 (single precison, just another name)
Binary 64  (the good old double gets renamed too)
Binary 128 (new, but ... see below ##)
Decimal 32 (new, for people and computers with 10 fingers)
Decimal 64 (will beat double (Binary64) for certain apps)
Decimal 128 (For bill's bank account, never rounds down)

To be abolished:
Extended single (have you ever known anyone using this?)
Extended double (the current D real format, heeeelp !!!)

##: Exceptions to the rules are likely as usual. There
might be optional formats. Maybe the 80 bit format
can be officially squeezed in the new Binary128.

Now we have the reason why Intel was shocking Walter
by telling him that FPU support for 80bits will fade.

The 754r and 854 will merge into the new 754
standard. When? God knows. They have started
Around 2000/2001 and they seem to be in the
middle of it. We'll see ...


P.S.: Another format was discussed but aparently has
not made it: 192bits. You can represent the atoms in
the universe with a double (sorry Binary64), because
there are only 1e80 of them, give or take a few. If you
don't believe me - count them yourself!. Use this 192bit
monster to count them more exactly than I could do
with a double. Your printout needs to be formatted to
about 40+ digits per number including exponent.
Still not enough for an accurate atom count I'm afraid.

But it would be fun to see a 192 bit emulation in D racing
against Javascript (suggest high precision transcend's).
Apr 04 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bob W wrote:

 To be abolished:
 Extended single (have you ever known anyone using this?)
 Extended double (the current D real format, heeeelp !!!)

The current D "real" format is *not* Extended Double ! It could be, but it could also be Double. Or Quadruple. It's "largest hardware implemented floating point size", meaning it's CPU/FPU dependant. Therefore, it varies... And Yet Again: this would be self-evident, if real was an alias instead ?
 ##: Exceptions to the rules are likely as usual. There
 might be optional formats. Maybe the 80 bit format
 can be officially squeezed in the new Binary128.

If there were hardware 128-bits, I don't think anyone would need to mess around with 80-bits or 96-bits... ? But those aren't really here yet, so we make due with what we have ? Or compromise and get 64-bit everywhere... "One Size Fits All" (the approach that Java, C# and Windows seems to take) --anders
Apr 04 2005
parent "Bob W" <nospam aol.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d2rkds$285k$2 digitaldaemon.com...
 Bob W wrote:

 To be abolished:
 Extended single (have you ever known anyone using this?)
 Extended double (the current D real format, heeeelp !!!)

The current D "real" format is *not* Extended Double ! It could be, but it could also be Double. Or Quadruple.

Just joking. Whatever format provided it is not less than double is fine with me for most of my apps.
 ##: Exceptions to the rules are likely as usual. There
 might be optional formats. Maybe the 80 bit format
 can be officially squeezed in the new Binary128.

If there were hardware 128-bits, I don't think anyone would need to mess around with 80-bits or 96-bits... ?

The problem is 128bits cost silicon and/or performance and are mostly unneeded. If double covers 99% of our needs, 80 or 96 bits will do 99.9% so padding could be a solution (IEEE 854 should come up with something before they merge with the new 754 revision). If I remember correctly during the endless story of the P754 revision attempts, someone was suggesting that precision should forcibly be reduced from the 128bits so that performace can be guaranteed to be at least 50% of the double's. But that could be already off the table.
 But those aren't really here yet, so we make due with
 what we have ? Or compromise and get 64-bit everywhere...

 "One Size Fits All"
 (the approach that Java, C# and Windows seems to take)

 --anders

As mentioned before that would be fine with me. But if not, the compiler/parser needs to ensure that it evaluates every fractional literal correctly not only those suffixed. (Now I start repeating myself.)
Apr 04 2005