Re: [PATCH] Improve geometric types
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: emre@hasegeli.com, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
Thomas Munro <thomas.munro@enterprisedb.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-09-27T17:05:26Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > On 09/27/2018 12:48 AM, Tom Lane wrote: >> Actually, it seems simpler than that: gaur produces plus zero already >> from the multiplication: >> regression=# select '-3'::float8 * '0'::float8; >> ?column? >> ---------- >> 0 >> (1 row) > Hmmm, interesting. But I still don't quite understand why the test > program still produced -0.000000 and not 0.000000. That seems like a > direct contradiction to what we see in regression tests, doesn't it? OK, so after poking at it for another hour and getting more and more confused, I realized that gdb was lying to me by printing genuine minus zero values as just "0". Throw out everything I thought I knew and start over ... ... and awhile later, this is the answer: on this machine, printf with "%f" will show the sign of minus zero. But printf with "%g" will not. Guess which format float8out uses. (I'll bet that gdb does too, so that its lie wasn't its fault.) AFAICT at the moment, gaur is doing the underlying IEEE float math the same as everybody else, which is not very surprising because HP bought into IEEE math pretty early. Hex-dumping shows conclusively that point_mul_point *does* emit (-0,0) in the case in question. But we've got a platform-specific issue with whether the minus zero gets printed as such. I wonder whether similar effects explain some of the other platform-specific oddities we've seen with minus zero. Anyway, at this point I'd say let's just leave gaur broken so far as the geometric tests are concerned, pending results from the concurrent thread about possibly rewriting snprintf.c's float handling to not depend on the platform's sprintf. If that doesn't happen, we can revisit some sort of narrower fix for this. The narrow fix ought to be in snprintf.c anyway, not anywhere near the geometric code. I notice BTW that it's sort of accidental that snprintf.c behaves properly for minus zero on most machines. The test "value < 0" isn't true, so it doesn't think there's a sign. When sprintf outputs a "-" anyway, that's effectively treated as a digit. We'd do the wrong thing with a format like "%+f", and maybe in other cases too. regards, tom lane
Commits
-
Improve test coverage of geometric types
- a3d2844852dc 12.0 landed
-
Fix problems in handling the line data type
- 2e2a392de391 12.0 landed
-
Use the built-in float datatypes to implement geometric types
- c4c340088546 12.0 landed
-
Remove remaining GEODEBUG references from geo_ops.c
- a082aed0723c 12.0 landed
-
Provide separate header file for built-in float types
- 6bf0bc842bd7 12.0 landed
-
Refactor geometric functions and operators
- a7dc63d904a6 12.0 landed
-
Fix crash in close_ps() for NaN input coordinates.
- 278148907a97 9.6.0 cited
-
Fix GiST index build for NaN values in geometric types.
- 1acf75725545 9.6.0 cited
-
Enable building with Visual Studion 2013.
- cec8394b5ccd 9.4.0 cited
-
Suppress -0 in the C field of lines computed by line_construct_pts().
- 43fe90f66a0b 9.4.0 cited