Re: NaN/Inf fix for ECPG

From: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
To: Rémi Zara <remi_zara(at)mac(dot)com>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: NaN/Inf fix for ECPG
Date: 2010-02-25 10:26:12
Message-ID: 4B865044.5070105@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rémi Zara írta:
> Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit :
>
>> Here's the attached test code. Compile it with
>>
>> gcc -Wall -o nantest nantest.c -lm
>>
>> and run it. It tests NAN anf INFINITY values with isinf() and isnan().
>> The expected output is:
>>
>> ==================
>> $ ./nantest
>> computed NAN
>> 1 0
>> computed INFINITY
>> 0 1
>> ==================
>>
>> Instead of "computed", NetBSD/x86-64 prints "defined"
>> but the test results are the same as under Linux/x86-64.
>>
>>
>
> Here it is :
>

First, thanks for running it.

> -bash-4.1$ gcc -Wall -o nantest nantest.c -lm
> -bash-4.1$ ./nantest
> defined NAN
> 0 1
>

So: isnan((double)NAN) == false, isinf((double)NAN) == true?
No wonder this causes a little problem.

> defined INFINITY
> 0 1
>
> Ok. So, on NetBSD/mips (#ifdef __NetBSD__ && __mips__), isnan(NAN) is true, isnan((double)NAN) is false, and isnan((double)(0.0 / 0.0)) is true.
>
> Regards,
> Rémi Zara
>

NAN on NetBSD/x86-64 is defined as:

extern const union __float_u __nanf;
#define NAN __nanf.__val

I would guess that it's similar on mips. Is is possible that
NetBSD/mips has a conversion bug?

What I don't get is that the code I used in ECPG and in this
test code is the same as in src/backend/utils/adt/float.c. E.g.:
float8in sees "NaN" -> value will be (double)NAN
float8out sees isnan(value) -> outputs "NaN" string

Can someone shed some light on why the backend
doesn't get the problem as above? :-(

As Rémi says, isnan((double)(0.0 / 0.0)) == true for him.
Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division
produces NaN. How about doing it explicitely in ECPG?

Rémi: please, run this code to confirm the above?

Best regards,
Zoltán Böszörményi

--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics

----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/

Attachment Content-Type Size
nantest1.c text/x-csrc 531 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rémi Zara 2010-02-25 10:38:24 Re: NaN/Inf fix for ECPG
Previous Message Heikki Linnakangas 2010-02-25 10:22:24 Re: testing cvs HEAD - HS/SR - xlog timeline 0 pg_xlogfile_name_offset