Hello, At Wed, 31 Jan 2018 17:33:42 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20180131.173342.26333067.horiguchi.kyot...@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