aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/float.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-06-14 11:00:07 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-06-14 11:00:07 -0400
commitdecbe2bfb1051c5ab6c382b19e1d909e34227a22 (patch)
tree87063608a54cf2feab46104b59436facda52d119 /src/backend/utils/adt/float.c
parent378badc8ebebc8fece7a18001f6b876cc00b12c0 (diff)
downloadpostgresql-decbe2bfb1051c5ab6c382b19e1d909e34227a22.tar.gz
postgresql-decbe2bfb1051c5ab6c382b19e1d909e34227a22.zip
Fix behavior of exp() and power() for infinity inputs.
Previously, these functions tended to throw underflow errors for negative-infinity exponents. The correct thing per POSIX is to return 0, so let's do that instead. (Note that the SQL standard is silent on such issues, as it lacks the concepts of either Inf or NaN; so our practice is to follow POSIX whenever a corresponding C-library function exists.) Also, add a bunch of test cases verifying that exp() and power() actually do follow POSIX for Inf and NaN inputs. While this patch should guarantee that exp() passes the tests, power() will not unless the platform's pow(3) is fully POSIX-compliant. I already know that gaur fails some of the tests, and I am suspicious that the Windows animals will too; the extent of compliance of other old platforms remains to be seen. We might choose to drop failing test cases, or to work harder at overriding pow(3) for these cases, but first let's see just how good or bad the situation is. Discussion: https://postgr.es/m/582552.1591917752@sss.pgh.pa.us
Diffstat (limited to 'src/backend/utils/adt/float.c')
-rw-r--r--src/backend/utils/adt/float.c43
1 files changed, 33 insertions, 10 deletions
diff --git a/src/backend/utils/adt/float.c b/src/backend/utils/adt/float.c
index 6a717f19bba..84d37de9304 100644
--- a/src/backend/utils/adt/float.c
+++ b/src/backend/utils/adt/float.c
@@ -1565,7 +1565,7 @@ dpow(PG_FUNCTION_ARGS)
if (unlikely(isinf(result)) && !isinf(arg1) && !isinf(arg2))
float_overflow_error();
- if (unlikely(result == 0.0) && arg1 != 0.0)
+ if (unlikely(result == 0.0) && arg1 != 0.0 && !isinf(arg1) && !isinf(arg2))
float_underflow_error();
PG_RETURN_FLOAT8(result);
@@ -1581,15 +1581,38 @@ dexp(PG_FUNCTION_ARGS)
float8 arg1 = PG_GETARG_FLOAT8(0);
float8 result;
- errno = 0;
- result = exp(arg1);
- if (errno == ERANGE && result != 0 && !isinf(result))
- result = get_float8_infinity();
-
- if (unlikely(isinf(result)) && !isinf(arg1))
- float_overflow_error();
- if (unlikely(result == 0.0))
- float_underflow_error();
+ /*
+ * Handle NaN and Inf cases explicitly. This avoids needing to assume
+ * that the platform's exp() conforms to POSIX for these cases, and it
+ * removes some edge cases for the overflow checks below.
+ */
+ if (isnan(arg1))
+ result = arg1;
+ else if (isinf(arg1))
+ {
+ /* Per POSIX, exp(-Inf) is 0 */
+ result = (arg1 > 0.0) ? arg1 : 0;
+ }
+ else
+ {
+ /*
+ * On some platforms, exp() will not set errno but just return Inf or
+ * zero to report overflow/underflow; therefore, test both cases.
+ */
+ errno = 0;
+ result = exp(arg1);
+ if (unlikely(errno == ERANGE))
+ {
+ if (result != 0.0)
+ float_overflow_error();
+ else
+ float_underflow_error();
+ }
+ else if (unlikely(isinf(result)))
+ float_overflow_error();
+ else if (unlikely(result == 0.0))
+ float_underflow_error();
+ }
PG_RETURN_FLOAT8(result);
}