Thread: 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
Attachment
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
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.