Subject: Re: Strange behavior with polygon and NaN
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, tgl@sss.pgh.pa.us
Cc: gkokolatos@pm.me, pgsql-hackers@lists.postgresql.org
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>
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Message-ID: <8d811be6-aebf-7276-0ec2-048ab58607ab@postgrespro.ru>
Date: Tue, 1 Dec 2020 17:06:44 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20201125.171406.1000330279258818376.horikyota.ntt@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

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