Horton

Re: [PATCH] Improve geometric types

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, emre@hasegeli.com, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-09-27T17:21:30Z
Lists: pgsql-hackers 
If you look at the differing results carefully, there's this one:

*** 3249,3255 ****
!  [(0,0),(3,0),(4,5),(1,6)] | (-5,-12)          | [(0,-0),(-15,-36),(40,-73),(67,-42)]
--- 3249,3255 ----
!  [(0,0),(3,0),(4,5),(1,6)] | (-5,-12)          | [(0,0),(-15,-36),(40,-73),(67,-42)]

(Third column is first multiplied by second).

I wonder why the expected file has a -0 only in the second position and
not both first and second.  These are both positive zeroes being
multiplied by a negative number.  Why is 0 * -12 = -0  yet  0 * -5 = 0?
What is going on?  Is the sign suppressed for negative zeros only in the
first coordinate?  I suppose this is just a side effect of how
float8_mi, _pl, _mul work (in point_mul_point).

Anyway maybe your test case should use more of the float8 op
combinations in order to show the difference.

-- 
Álvaro Herrera                https://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().