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