Re: [HACKERS] NAN code - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] NAN code
Date
Msg-id m0zxF4G-000EBQC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] NAN code  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
List pgsql-hackers
>
> >     While  searching for the NAN definition I've noticed too that
> >     our float4/float8 datatypes can  output  'NaN',  but  do  not
> >     parse  them back.
>
> Yeah, I just noticed that a few minutes ago too.
>
> I've got some patches which fix this, at least for machines with NaN
> support (and for HUGE_VAL/Infinity too). We'll need some more code to
> handle non-IEEE machines...

    The  final  might  be  that  for  machines/compilers with NaN
    support, NAN is

        #define NAN (0.0/0.0)

    or whatever is the correct thing for it (best choice is still
    the definition from a system header like nan.h if available),
    while for those who cannot support it it'll be

        #define NAN unsupported_nan_request()

        double unsupported_nan_request(void)
        {
            elog(ERROR, "unsupported request for NaN as floating point value");
            return 0.0;
        }


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

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] NAN code
Next
From: Clark Evans
Date:
Subject: XML/SGML