I saw the posting regarding the NaN issue and I 
thought you might be interested in the following:

Sun Microsystem's Numerical Computation Guide
which covers the IEEE 754 standard, states:

"NaN's are often represented as floating-point numbers
with the exponent e max + 1 and non-zero significands."

and

SoftFloat, a free software implementation of the
standard,
http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/softfloat.html,
defines the following:

default 32-bit NaN: 0xFFC00000
default 64-bit NaN: 0xFFF8000000000000

Assigning these values to int32_t and int64_t, and then
memcpying them to a float and a double representation
yeilded a TRUE result when testing with isnan().
If they are NaN under Linux/Intel implementation 
(2.0.36) using gcc 2.7.2.3 and math library 2.0.7 
of the IEEE 754 standard, is it not fair to say it 
would be true for all implementations?

For what its worth...

Marcus Mascari (mascarim@yahoo.com)








_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


Tue, 5 Jan 1999 00:56:56 -0800 (PST)
Marcus Mascari <mascarim@yahoo.com>
NaN format
Marcus Mascari wrote:

> Sun Microsystem's Numerical Computation Guide
> which covers the IEEE 754 standard, states:
>
> "NaN's are often represented as floating-point numbers
> with the exponent e max + 1 and non-zero significands."
>
> and
>
> SoftFloat, a free software implementation of the
> standard,
> http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/softfloat.html,
> defines the following:
>
> default 32-bit NaN: 0xFFC00000
> default 64-bit NaN: 0xFFF8000000000000

    My i386 Linux's nan.h defines them as

        Signal double NaN    0x7FF00000000F0000
        Quiet double NaN     0x7FF8000000000000
        Signal float NaN     0x7F800F00
        Quiet float NaN      0x7FC00000

>
> Assigning these values to int32_t and int64_t, and then
> memcpying them to a float and a double representation
> yeilded a TRUE result when testing with isnan().
> If they are NaN under Linux/Intel implementation
> (2.0.36) using gcc 2.7.2.3 and math library 2.0.7
> of the IEEE 754 standard, is it not fair to say it
> would be true for all implementations?

    Even  if  your ones work with Linux too, I expect problems on
    other implementations or at least on different hardware.

    If we add a little check to the regression, I  think  we  can
    figure  out most of the platform specific definitions for NaN
    until v6.5 and put them into .../include/port/*.h with having
    a  fallback to a function that elog()'s why this test failed.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Tue, 5 Jan 1999 11:17:39 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: NaN format