On 09/27/2018 07:05 PM, Tom Lane wrote: > 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 ... >
Heh. A debugger lying to you just a wee bit is fun ... > ... 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. > OK, makes sense. Thanks for the investigation! regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services