Обсуждение: Incompatible trig error handling

Поиск
Список
Период
Сортировка

Incompatible trig error handling

От
John Gorman
Дата:
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
Вложения

Re: Incompatible trig error handling

От
Tom Lane
Дата:
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



Re: Incompatible trig error handling

От
Noah Misch
Дата:
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.