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