Emre Hasegeli <emre@hasegeli.com> writes:
>> Uh, I thought pg_hypot() was still needed on our oldest supported
>> platforms. Or is hypot() already supported there?
> What is our oldest supported platform?
Our normal reference for such questions is SUS v2 (POSIX 1997):
http://pubs.opengroup.org/onlinepubs/007908799/
I looked into that, and noted that it does specify hypot(), but
it has different rules for edge conditions:
If the result would cause overflow, HUGE_VAL is returned and errnomay be set to [ERANGE].
If x or y is NaN, NaN is returned. and errno may be set to [EDOM].
If the correct result would cause underflow, 0 is returned anderrno may be set to [ERANGE].
whereas POSIX 2008 saith:
If the correct value would cause overflow, a range error shalloccur and hypot(), hypotf(), and hypotl() shall return
thevalueof the macro HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively.
[MX] If x or y is ±Inf, +Inf shall be returned (even if one of xor y is NaN).
If x or y is NaN, and the other is not ±Inf, a NaN shall bereturned.
[MXX] If both arguments are subnormal and the correct result issubnormal, a range error may occur and the correct
resultshallbe returned.
In short, the reason that the existing comment makes a point of the
Inf-and-NaN behavior is that the standard changed somewhere along the
line. While I believe we could get away with assuming that hypot()
exists everywhere, it's much less clear that we could rely on the result
being Inf and not NaN in this case.
Now, it's also not clear that anything in PG really cares. But if we
do care, I think we should keep pg_hypot() ... and maybe clarify the
comment a bit more.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers