NaN/Inf fix for ECPG
in [PgSql]
|
Prev: pgsql: Clean up package namespace use and use ofSafe in plperl.
Next: ToDo: plpgsql plugin for query and expression verification
From: =?iso-8859-1?Q?R=E9mi_Zara?= on 24 Feb 2010 14:45 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 : -bash-4.1$ gcc -Wall -o nantest nantest.c -lm -bash-4.1$ ./nantest defined NAN 0 1 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 25 Feb 2010 05:26 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/
From: =?iso-8859-1?Q?R=E9mi_Zara?= on 25 Feb 2010 05:38 Le 25 févr. 2010 à 11:26, Boszormenyi Zoltan a écrit : > > NAN on NetBSD/x86-64 is defined as: > > extern const union __float_u __nanf; > #define NAN __nanf.__val > Same here: math.h:extern const union __float_u __nanf; math.h:#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? > bash-4.1$ gcc -Wall -o nantest1 nantest1.c -lm bash-4.1$ ./nantest1 computed NAN 1 0 defined INFINITY 0 1 Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Boszormenyi Zoltan on 25 Feb 2010 07:26 I wrote: > 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? > I came up with three patches, they are attached. Can you try whether the first patch (missing float.h from data.c) solves the problem? And together with the 2nd one? In that patch I fixed the order of float.h and math.h in nan_test.pgc, which is the opposite of the order found in e.g. backend/utils/adt/float.c. The 3rd patch is explicit about NetBSD/mips but it doesn't feel right. They are working on Linux/x86-64 and NetBSD/x86-64. Can you try the combinations below on "pika" outside the buildfarm whether they still fail the ECPG make check? - patch 1 by itself (12a) - patch 1+2 (12a + 12-regr) - patch 3 with/without 1+2 Sorry to give you work, but we don't have a mips machine. Thanks in advance, 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/
From: =?iso-8859-1?Q?R=E9mi_Zara?= on 24 Feb 2010 12:05
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : > > > Is this buildfarm member for detecting bugs in the already > obsolete NetBSD 5.0 BETA, or what? The final 5.0 and > two bugfix releases are already out for a while. The owner > of that particular machine should upgrade. I upgraded pika to NetBSD 5.0.2, and the problem is still there. There are some tests (in "core") which tests for NaN and Infinity, which pass. So either those tests are insufficient, or the code does something different there. Anything you want me to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |