Re: [PATCH] Improve geometric types

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