Re: 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) #