Re: Strange behavior with polygon and NaN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Strange behavior with polygon and NaN
Date
Msg-id 289049.1605284781@sss.pgh.pa.us
Whole thread Raw
In response to Re: Strange behavior with polygon and NaN  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Strange behavior with polygon and NaN
List pgsql-hackers
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Tue, 10 Nov 2020 14:30:08 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
>> For instance, {1,-1,0} is the line "x = y".  We could argue about
>> whether it'd be sensible to return zero for the distance between that
>> and the point (inf,inf), but surely any point with one inf and one
>> finite coordinate must be an infinite distance away from that line.
>> There's nothing ill-defined about that situation.

> Mmm... (swinging my arms to mimic lines..)
> dist(x = y, (1e300, Inf)) looks indeterminant to me..

Well, what you're showing is that we get an internal overflow,
essentially, on the way to calculating the result.  Which is true,
so it's sort of accidental that we got a sensible result before.
Nonetheless, we *did* get a sensible result, so producing NaN
instead seems like a regression.

We might need to introduce special-case handling to protect the
low-level calculations from ever seeing NaN or Inf in their inputs.
Getting the right answer to "just fall out" of those calculations
might be an unreasonable hope.

For example, for a line with positive slope (A and B of opposite
signs), I think that the right answer for points (Inf,Inf) and
(-Inf,-Inf) should be NaN, on much the same grounds that Inf
minus Inf is NaN not zero.  But all other points involving any Inf
coordinates are clearly an infinite distance away from that line.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alexey Bashtanov
Date:
Subject: don't allocate HashAgg hash tables when running explain only
Next
From: Alvaro Herrera
Date:
Subject: Re: error_severity of brin work item