Re: [HACKERS] NAN code
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] NAN code |
Дата | |
Msg-id | m0zxF4G-000EBQC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] NAN code ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | 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 по дате отправления: