From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Line intersection point is wrong |
Date: | 2016-06-19 18:02:34 |
Message-ID: | CAE2gYzyi_XkC4YdBj3E+a+7xYfOg0AR=sZsSCEWuYNFVmp+fCw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> Hm. I don't think I believe the vertical-line cases there either.
> They seem to be assuming A = -1 in a vertical line, which would be
> true if the line was computed by line_construct_pts, but otherwise
> not necessarily.
I think we can just remove those cases.
> Also: your formulation of the general case assumes that
> (l1->A * l2->B - l2->A * l1->B) is not zero, which I'm
> not entirely convinced of. In principle the line_parallel test
> would catch the case, but seeing that that is not exactly how
> line_parallel computes its result, roundoff error could bite us
> here. I wonder if line_interpt_internal should skip the
> line_parallel call and instead do its own tests for zero divide
> to detect parallel lines.
If it would do its own test, the result would be inconsistent with ?#
and ?||. It is not hard to get an overflow with the current logic
anyway:
hasegeli=# select '{1,1,-2}'::line # '{1,2,-3}'::line;
?column?
---------------------
(Infinity,Infinity)
(1 row)
Evidently nobody is using these operators. I am going to send a patch
reworking many of those to make them less vulnerable to roundoff
errors for the next release.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-19 18:17:31 | Re: Line intersection point is wrong |
Previous Message | Tom Lane | 2016-06-19 18:01:49 | Re: [HACKERS] Re: BUG #14199: The pg_ctl status check on server start is not compatible with the silent_mode=on |