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
