Re: [PATCH] Improve geometric types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: emre(at)hasegeli(dot)com, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Improve geometric types
Date: 2018-09-27 17:05:26
Message-ID: 23662.1538067926@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-09-27 17:21:30 Re: [PATCH] Improve geometric types
Previous Message Apoorv Jain 2018-09-27 16:36:10 Application for Google Code-in 2018 mentor