• Bob W (34/34) Apr 04 2005 Just read the new P754 draft. Although I cannot imagine
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (14/20) Apr 04 2005 The current D "real" format is *not* Extended Double !
• Bob W (18/34) Apr 04 2005 Just joking. Whatever format provided it is not less

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

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


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

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


 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"


--anders

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




 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"


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