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
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index 4e927d8..afcfa8c 100644
--- a/src/backend/utils/adt/float.c
+++ b/src/backend/utils/adt/float.c
@@ -1530,7 +1530,7 @@ dacos(PG_FUNCTION_ARGS)
*/
errno = 0;
result = acos(arg1);
- if (errno != 0)
+ if (errno != 0 || isnan(result))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
@@ -1551,7 +1551,7 @@ dasin(PG_FUNCTION_ARGS)
errno = 0;
result = asin(arg1);
- if (errno != 0)
+ if (errno != 0 || isnan(result))
ereport(ERROR,
(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
errmsg("input is out of range")));
diff --git a/src/test/regress/expected/float8.out b/src/test/regress/expected/float8.out
index 6221538..49687fc 100644
--- a/src/test/regress/expected/float8.out
+++ b/src/test/regress/expected/float8.out
@@ -351,6 +351,23 @@ SELECT '' AS three, f.f1, exp(ln(f.f1)) AS exp_ln_f1
| 1.2345678901234e-200 | 1.23456789012339e-200
(3 rows)
+-- trigonometry
+SELECT asin(0);
+ asin
+------
+ 0
+(1 row)
+
+SELECT asin(2);
+ERROR: input is out of range
+SELECT acos(0);
+ acos
+-----------------
+ 1.5707963267949
+(1 row)
+
+SELECT acos(2);
+ERROR: input is out of range
-- cube root
SELECT ||/ float8 '27' AS three;
three
diff --git a/src/test/regress/sql/float8.sql b/src/test/regress/sql/float8.sql
index 92a574a..fd1e43f 100644
--- a/src/test/regress/sql/float8.sql
+++ b/src/test/regress/sql/float8.sql
@@ -114,6 +114,12 @@ SELECT '' AS three, f.f1, exp(ln(f.f1)) AS exp_ln_f1
FROM FLOAT8_TBL f
WHERE f.f1 > '0.0';
+-- trigonometry
+SELECT asin(0);
+SELECT asin(2);
+SELECT acos(0);
+SELECT acos(2);
+
-- cube root
SELECT ||/ float8 '27' AS three;
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