On 25.11.2020 11:14, Kyotaro Horiguchi wrote:
At Wed, 25 Nov 2020 11:39:39 +0900 (JST), Kyotaro Horiguchi
<horikyota....@gmail.com> wrote in
So that line of thought prompts me to tread *very* carefully when
trying to dodge NaN results. We need to be certain that we
introduce only logically-defensible special cases. Something like
float8_coef_mul() seems much more likely to lead us into errors
than away from them.
Agreed on that point. I'm going to rewirte the patch in that
direction.
Removed the function float8_coef_mul().
I noticed that the check you proposed to add to line_closept_point
doesn't work for the following case:
select line('{1,-1,0}') <-> point(1e300, 'Infinity');
Ax + By + C = 1 * 1e300 + -1 * Inf + 0 = -Inf is not NaN so we go on
the following steps.
derive the perpendicular line: => line(-1, -1, Inf}
derive the cross point : => point(Inf, Inf)
calculate the distance : => NaN (which should be Infinity)
So I left the check whether distance is NaN in this version. In the previous
version the check is done before directly calculating the distance, but since
we already have the result of Ax+Bx+C so I decided not to use point_dt() in this
version.
Although I wrote that it should be wrong that applying FPzero() to
coefficients, there are some places already doing that so I followed
those predecessors.
Reverted the change of pg_hypot().
While checking the regression results, I noticed that the follwoing
calculation, which seems wrong.
select line('{3,NaN,5}') = line('{3,NaN,5}');
?column?
----------
t
But after looking point_eq(), I decided to let the behavior alone
since I'm not sure the reason for the behavior of the functions. At
least the comment for point_eq() says that is the delibarate
behvior. box_same, poly_same base on the point_eq_point so they behave
the same way.
By the way, '=' doesn't compare the shape but compares the area.
However, what is the area of a line? That should be always 0 even if
we considered it. And it is also strange that we don't have
corresponding comparison ('<' and so) operators. It seems to me as if
a mistake of '~='. If it is correct, I should revert the change of
line_eq() along with fixing operator assignment.
regards.
Status update for a commitfest entry.
The commitfest is closed now and this entry is "Waiting on author".
As far as I see, part of the fixes is already committed. Is there
anything left to work on or this patch needs review/ ready for committer
now?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
