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
-
Improve test coverage of geometric types
- a3d2844852dc 12.0 landed
-
Fix problems in handling the line data type
- 2e2a392de391 12.0 landed
-
Use the built-in float datatypes to implement geometric types
- c4c340088546 12.0 landed
-
Remove remaining GEODEBUG references from geo_ops.c
- a082aed0723c 12.0 landed
-
Provide separate header file for built-in float types
- 6bf0bc842bd7 12.0 landed
-
Refactor geometric functions and operators
- a7dc63d904a6 12.0 landed
-
Fix crash in close_ps() for NaN input coordinates.
- 278148907a97 9.6.0 cited
-
Fix GiST index build for NaN values in geometric types.
- 1acf75725545 9.6.0 cited
-
Enable building with Visual Studion 2013.
- cec8394b5ccd 9.4.0 cited
-
Suppress -0 in the C field of lines computed by line_construct_pts().
- 43fe90f66a0b 9.4.0 cited