From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: tgl@sss.pgh.pa.us
Cc: gkokolatos@pm.me
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Strange behavior with polygon and NaN
Date: Tue, 1 Dec 2020 17:06:44 +0300
Message-ID: <8d811be6-aebf-7276-0ec2-048ab58607ab@postgrespro.ru> (raw)
In-Reply-To: <20201125.171406.1000330279258818376.horikyota.ntt@gmail.com>
References: <20201124.135544.121959508317571971.horikyota.ntt@gmail.com>
<290594.1606238981@sss.pgh.pa.us>
<20201125.113939.692283304590689816.horikyota.ntt@gmail.com>
<20201125.171406.1000330279258818376.horikyota.ntt@gmail.com>
On 25.11.2020 11:14, Kyotaro Horiguchi wrote:
> At Wed, 25 Nov 2020 11:39:39 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: a.lubennikova@postgrespro.ru, horikyota.ntt@gmail.com, tgl@sss.pgh.pa.us, gkokolatos@pm.me, pgsql-hackers@lists.postgresql.org
Subject: Re: Strange behavior with polygon and NaN
In-Reply-To: <8d811be6-aebf-7276-0ec2-048ab58607ab@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox