Horton

Re: power() function in Windows: "value out of range: underflow"

David Rowley <david.rowley@2ndquadrant.com>

View thread View on postgr.es
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Huong Dangminh <huo-dangminh@ys.jp.nec.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Akio Iwaasa <aki-iwaasa@vt.jp.nec.com>
Date: 2018-04-29T22:10:34Z
Lists: pgsql-bugs, pgsql-hackers 
On 30 April 2018 at 09:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> http://netbsd.gw.com/cgi-bin/man-cgi?pow+3+NetBSD-5.2.3
>
> which goes to great lengths to justify NaN^0 = 1 while saying nothing
> to suggest that 1^NaN might not yield NaN.
>
> I'm not sure if we should add more special-case code for that, or just
> remove that test case again.  Historically we've not really felt that it
> was our job to mask oddities of the platform's math library, so the fact
> that power() is worrying about this seems like unjustified scope creep.
> On the other hand, we do have a bunch of special cases there already,
> so refusing to handle older BSD would be a tad inconsistent.

(Sorry missed your reply before I sent my last one)

Wouldn't this machine have returned 1 before this patch though? Surely
changing this behaviour this plaetform in favour of fixing on another
is worse than doing nothing. If that's the case, I think the only
option is to add a special case or revert this and document that the
behaviour may vary depending on the platform's implementation of
pow(). I think the special case is worth it, since there's already
some for the error cases.


-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

  1. Revert back-branch changes in power()'s behavior for NaN inputs.

  2. Avoid wrong results for power() with NaN input on more platforms.

  3. Avoid wrong results for power() with NaN input on some platforms.