From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart) |
Cc: | jwieck(at)debis(dot)com, maillist(at)candle(dot)pha(dot)pa(dot)us, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] NAN code |
Date: | 1999-01-04 18:49:32 |
Message-ID: | m0zxF4G-000EBQC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Clark Evans | 1999-01-05 00:58:45 | XML/SGML |
Previous Message | Thomas G. Lockhart | 1999-01-04 18:17:50 | Re: [HACKERS] NAN code |