Thread overview | |||||
---|---|---|---|---|---|
|
April 04, 2005 IEEE 754r Forthcoming Floating Point Formats | ||||
---|---|---|---|---|
| ||||
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). |
April 04, 2005 Re: IEEE 754r Forthcoming Floating Point Formats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bob W | 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 |
April 04, 2005 Re: IEEE 754r Forthcoming Floating Point Formats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | "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.) |
Copyright © 1999-2021 by the D Language Foundation