Re: Line intersection point is wrong
От | Emre Hasegeli |
---|---|
Тема | Re: Line intersection point is wrong |
Дата | |
Msg-id | CAE2gYzyi_XkC4YdBj3E+a+7xYfOg0AR=sZsSCEWuYNFVmp+fCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Line intersection point is wrong (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Line intersection point is wrong
|
Список | 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.
В списке pgsql-bugs по дате отправления: