Horton

Re: [PATCH] Improve geometric types

Tomas Vondra <tomas.vondra@2ndquadrant.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Emre Hasegeli <emre@hasegeli.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-07-29T12:03:22Z
Lists: pgsql-hackers 

On 07/29/2018 01:28 PM, Thomas Munro wrote:
> On Sun, Jul 29, 2018 at 10:57 PM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> On Sun, Jul 29, 2018 at 10:35 PM, Tomas Vondra
>> <tomas.vondra@2ndquadrant.com> wrote:
>>> It's always 0/-0 difference, and it's limited to power machines. I'll
>>> try to get access to such system and see what's wrong.
>>
>> This is suspicious:
>>
>>         /* on some platforms, the preceding expression tends to produce -0 */
>>         if (line->C == 0.0)
>>             line->C = 0.0;
> 
> I mean, it's suspiciously absent from the new line_construct()
> function.  It was introduced here:
> 
> commit 43fe90f66a0b200f6c32507428349afb45f661ca
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Date:   Fri Oct 25 15:55:15 2013 -0400
> 
>     Suppress -0 in the C field of lines computed by line_construct_pts().
> 
>     It's not entirely clear why some PPC machines are generating -0 here, since
>     the underlying computation should be exactly 0 - 0.  Perhaps there's some
>     wider-than-nominal-precision calculations happening?  Anyway, the best way
>     to avoid platform-dependent results seems to be to explicitly reset -0 to
>     regular zero.
> 

Hmm, I see. I think adding it to the else branch should do the trick,
then, I guess. But I'd be much happier if I could test it somewhere
before the commit.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Improve test coverage of geometric types

  2. Fix problems in handling the line data type

  3. Use the built-in float datatypes to implement geometric types

  4. Remove remaining GEODEBUG references from geo_ops.c

  5. Provide separate header file for built-in float types

  6. Refactor geometric functions and operators

  7. Fix crash in close_ps() for NaN input coordinates.

  8. Fix GiST index build for NaN values in geometric types.

  9. Enable building with Visual Studion 2013.

  10. Suppress -0 in the C field of lines computed by line_construct_pts().