Re: Line intersection point is wrong

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.

In response to

Responses

Browse pgsql-bugs by date

  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