Re: [HACKERS] [PATCH] Improve geometric types

> I'm a bit confused how this patch has gone through several revisions > since, but has been marked as "ready for committer" since 2017-09-05. Am > I missing something? This is floating between commitfests for longer than a year. Aleksander Alekseev set it to "ready for committer", but Kyotaro

Re: [HACKERS] [PATCH] Improve geometric types

Hi, On 2018-02-07 16:46:38 +0100, Emre Hasegeli wrote: > I am incorporating the fix you have posted to the other thread to this patch. You've not posted a version fixing the issues in the surrounding thread, do I see that right? I'm a bit confused how this patch has gone through several

Re: [HACKERS] [PATCH] Improve geometric types

> - 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

Re: [HACKERS] [PATCH] Improve geometric types

Hello, At Wed, 31 Jan 2018 17:33:42 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI 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

Re: [HACKERS] [PATCH] Improve geometric types

> ! 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(),

Re: [HACKERS] [PATCH] Improve geometric types

> 1."COPT=-DGEODEBUG make" complains as follows. > > | geo_ops.c:2445:62: error: invalid type argument of unary ‘*’ (have > ‘float8 {aka double}’) > | printf("dist_ppoly_internal- segment 0/n distance is %f\n", *result); Fixing. > 2. line_construct_pm has been renamed to line_construct. I

Re: [HACKERS] [PATCH] Improve geometric types

At Wed, 31 Jan 2018 13:09:09 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180131.130909.210233873.horiguchi.kyot...@lab.ntt.co.jp> > At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote > in

Re: [HACKERS] [PATCH] Improve geometric types

At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote in > New versions are attached including all changes we discussed. Thanks for the new version. # there's many changes from the previous version..

Re: [HACKERS] [PATCH] Improve geometric types

> I'm fine with the current shape. Thanks. Maybe the same > discussion applies to polygons. (cf. poly_overlap) It indeed does. I am incorporating. > line_closept_point asserts line_interpt_line returns true but it > is hazardous. It is safer if line_closept_point returns NaN if >

Re: [HACKERS] [PATCH] Improve geometric types

Hello, At Thu, 18 Jan 2018 16:01:01 +0100, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

> 0001: > > - You removed the check of parallelity check of > line_interpt_line(old line_interpt_internal) but line_parallel > is not changed so the consistency between the two functions are > lost. It is better to be another patch file (maybe 0004?). I am making line_parallel() use

Re: [HACKERS] [PATCH] Improve geometric types

Hello, I played more around geometric types and recalled that geometric types don't have orderings. Also have corrected some other misunderstanding. Sorry for my confusion and I think I returned on the way. At Wed, 17 Jan 2018 18:59:30 +0100, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

> I'm not sure what you mean by the "basic comparison ops" but I'm > fine with the policy, handling each component values in the same > way with float. So point_eq_point() is right and other functions > should follow the same policy. I mean <, >, <= and >= by basic comparison operators.

Re: [HACKERS] [PATCH] Improve geometric types

Hello, I'm still wandering on the way and confused. Sorry for inconsistent comments in advanceX-( At Sun, 14 Jan 2018 13:20:57 +0100, Emre Hasegeli wrote in

Re: [HACKERS] [PATCH] Improve geometric types

> I found seemingly inconsistent handling of NaN. > > - Old box_same assumed NaN != NaN, but new assumes NaN == > NaN. I'm not sure how the difference is significant out of the > context of sorting, though... There is no box != box operator. If there was one, previous code would return false

Re: [HACKERS] [PATCH] Improve geometric types

Hello, sorry for the absense. (Sorry for the long but should be hard-to-read article..) At Thu, 4 Jan 2018 14:53:47 +0100, Emre Hasegeli wrote in > Rebased versions are attached. Thank you for the new

Re: [HACKERS] [PATCH] Improve geometric types

> Does this patch series fix bug #14971? No, it doesn't. I am trying to improve things without touching the EPSILON.

Re: [HACKERS] [PATCH] Improve geometric types

Does this patch series fix bug #14971? https://www.postgresql.org/message-id/20171213172806.20142.73...@wrigleys.postgresql.org Eric: see https://www.postgresql.org/message-id/CAE2gYzzvp=uvpw4fytoaevyk-wze4jw7u2s1glrok35mr1-...@mail.gmail.com for last version of patch. Motivation for patch is at

Re: [HACKERS] [PATCH] Improve geometric types

On Thu, Nov 30, 2017 at 3:28 AM, Emre Hasegeli wrote: > It would at least be dump-and-restore hazard if we don't let them in. > The new version allows NaNs. > >> This gives a wrong result for NaN-containing objects. > > I removed the NaN aware comparisons from FP macros, and

Re: [HACKERS] [PATCH] Improve geometric types

> dist_pl is changed to take the smaller distance of both ends of > the segment. It seems absorbing error, so it might be better > taking the mean of the two distances. If you have a firm reason > for the change, it is better to be written there, or it might be > better left alone. I am sorry for