Re: [HACKERS] [PATCH] Improve geometric types

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>

From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: emre@hasegeli.com
Cc: tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, robertmhaas@gmail.com, a.alekseev@postgrespro.ru, pgsql-hackers@postgresql.org
Date: 2018-02-01T11:52:10Z
Lists: pgsql-hackers
Hello,

At Wed, 31 Jan 2018 17:33:42 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20180131.173342.26333067.horiguchi.kyotaro@lab.ntt.co.jp>
> 0003: This patch replaces "double" with float and bare arithmetic
>     and comparisons on double to special functions accompanied
>     with checking against abnormal values.
> 
>  - Almost all of them are eliminated with a few safe exceptions.
> 
>     - circle_recv(), circle_distance(), dist_pc(), dist_cpoint()
>       are using "< 0.0" comparison but it looks fine.
> 
>     - pg_hypot is right to use bare arithmetics.
> 
>     ! circle_contain_pt() does the following comparison and it
>       seems to be out of our current policy.
> 
>       point_dt(center, point) <= radius
> 
>       I suppose this should use FPle.
> 
>       FPle(point_dt(center, point), radius)
> 
>       The same is true of circle_contain_pt(), pt_contained_circle .

 - line_eq looks too complex in the normal (not containing NANs)
   cases.  We should avoid such complexity if possible.

   One problem here is that comparison conceals NANness of
   operands. Conversely arithmetics propagate it. We can converge
   NANness into a number. The attached line_eq() doesn that. This
   doesn't have almost no additional complexity when NAN is
   involved. I believe it qbehaves in the same way
   and shares a doubious behavior like this.

   =# select '{nan, 1, nan}'::line = '{nan, 2, nan}'::line;
    ?column? 
   ----------
    t

   But probably no point in fixing(?) it.

   The attached file contains line_eq, point_eq_point and
   circle_same. I expect that line_eq is fast but other two are
   doubious.

0004:

 - line_perp

   We can detect perpendicularity without division.

   The normal vecotor of Ax + Bx + C = 0 is (A, B). If two lines
   are perpendicular, the inner product of the normal vectors of
   v1 and v2 is 0. No point in dividing.

   l1->A * l2->A + l1->B * l2->B == 0

   . . . Mmm.. The function seems broken. I posted the fix for
   the existing version is posted, and line_perp() in the attched
   file will work fine.


regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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().