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