Re: Line intersection point is wrong
От | Tom Lane |
---|---|
Тема | Re: Line intersection point is wrong |
Дата | |
Msg-id | 14750.1466353137@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Line intersection point is wrong (Emre Hasegeli <emre@hasegeli.com>) |
Ответы |
Re: Line intersection point is wrong
|
Список | pgsql-bugs |
Emre Hasegeli <emre@hasegeli.com> writes: > While working on removing FP macros of the geometric type operators, > I noticed that line intersection is giving wrong results: 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. regression=# select '((1,0),(1,1))'::line; line ---------- {-1,0,1} (1 row) regression=# select '{-1,0,1}'::line # '((0,2),(2,2))'::line; ?column? ---------- (1,2) -- this answer is correct (1 row) regression=# select '{-2,0,2}'::line # '((0,2),(2,2))'::line; ?column? ---------- (2,2) (1 row) If I haven't lost it completely, {-1,0,1} and {-2,0,2} are equivalent line values. line_eq certainly thinks so. 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. regards, tom lane
В списке pgsql-bugs по дате отправления: