Incompatible trig error handling
Two of the trigonometry functions have differing error condition behavior
between Linux and OSX. The Linux behavior follows the standard set by the
other trig functions.
On Linux:
SELECT asin(2);
ERROR: input is out of range
SELECT acos(2);
ERROR: input is out of range
On OSX:
SELECT asin(2);
asin
------
NaN
(1 row)
SELECT asin(2);
asin
------
NaN
(1 row)
The attached patch brings OSX into line with the expected behaviour and the
additional regression tests verify this.
Is this worth fixing and if so what is the next step?
Best, John
Attachments:
trig-v1.patchapplication/octet-stream; name=trig-v1.patchDownload+25-2
John Gorman <johngorman2@gmail.com> writes:
Two of the trigonometry functions have differing error condition behavior
between Linux and OSX. The Linux behavior follows the standard set by the
other trig functions.
We have never considered it part of Postgres' charter to try to hide
platform-specific variations in floating-point behavior. If we did,
we'd spend all our time doing that rather than more productive stuff.
In particular, it appears to me that both of these behaviors are allowed
per the POSIX standard, which makes it very questionable why we should
insist that one is correct and the other is not.
In addition, the proposed patch turns *all* cases that return NaN into
errors, which is wrong at least for the case where the input is NaN.
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
On Wed, Apr 29, 2015 at 05:11:48PM -0700, Tom Lane wrote:
John Gorman <johngorman2@gmail.com> writes:
Two of the trigonometry functions have differing error condition behavior
between Linux and OSX. The Linux behavior follows the standard set by the
other trig functions.We have never considered it part of Postgres' charter to try to hide
platform-specific variations in floating-point behavior. If we did,
we'd spend all our time doing that rather than more productive stuff.In particular, it appears to me that both of these behaviors are allowed
per the POSIX standard, which makes it very questionable why we should
insist that one is correct and the other is not.In addition, the proposed patch turns *all* cases that return NaN into
errors, which is wrong at least for the case where the input is NaN.
OS X is a MATH_ERREXCEPT, !MATH_ERRNO platform. PostgreSQL wrongly assumes
that all platforms are MATH_ERRNO platforms. The correct fix is to use
fetestexcept() on !MATH_ERRNO platforms.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers