On 09/27/2018 07:05 PM, Tom Lane wrote:
> 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 ...
>
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