Tomas Vondra <tomas.von...@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