Re: Strange behavior with polygon and NaN

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: gkokolatos(at)pm(dot)me, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Strange behavior with polygon and NaN
Date: 2020-11-25 08:14:06
Message-ID: 20201125.171406.1000330279258818376.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 25 Nov 2020 11:39:39 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v7-0001-fix-geometric-nan-handling.patch text/x-patch 72.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-11-25 08:29:55 Re: Prevent printing "next step instructions" in initdb and pg_upgrade
Previous Message Fujii Masao 2020-11-25 08:07:48 Re: [PATCH] Add features to pg_stat_statements