[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Payload length and interpretation in IEEE Std 754-2008



On Apr 29, 2011, at 10:01 AM, Charles Stevens wrote:

And it does concern me that the set of values permitted for a payload in, 
say, a Binary128 is MUCH larger than the set of values permitted in a 
Binary32, when it appears that the implementor would be dealing with the same 
set of conditions -- and thus the same set of payload values -- in both 
cases.  Why?  Eight-million-plus possibilities ought to be enough for ANY 
implementor!  

That's not obvious at all.  One can imagine a system where, when some form of 
debugging is enabled, a NaN payload contains an index into a table containing 
information about exactly where and how the NaN was raised, or a timestamp that 
can be correlated with program execution, or any number of other informative 
fields that could easily exceed 8 million possibilities.

I confess that I don't see what the merit of restricting all implementations to 
the low (or high) 23 bits of the payload would be; a language or implementation 
is free to make such a restriction, but it is not forced on an implementation 
that might like to do something useful with the additional bits.  Encoding 
space is a terrible thing to waste =)

- Steve


754 | revision | FAQ | references | list archive