[
https://issues.apache.org/jira/browse/NUMBERS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aryan Ganjoo updated NUMBERS-218:
---------------------------------
Description:
ArithmeticUtils.pow(-2, 31) and ArithmeticUtils.pow(-2L, 63) throw
ArithmeticException even though their exact results are Integer.MIN_VALUE and
Long.MIN_VALUE. The API documents overflow only when the result cannot fit.
Expected: those two calls return the minimum values; neighbouring overflowing
powers, such as pow(2,31) and pow(-2,32), still throw. Actual: an early
exponent guard rejects both valid boundary cases.
A standalone regression harness failed on pristine master
9b629bdfd72fc8c499795e32bf12909bf34a1f18 and passed with a local two-line guard
correction. The new JUnit test and mvn -q -pl commons-numbers-core verify
passed locally; a BigInteger comparison over a broad base/exponent range also
found no mismatches after the correction. The fix is now submitted as
https://github.com/apache/commons-numbers/pull/223; full local mvn clean verify
passed, while hosted checks and maintainer review are pending. NUMBERS-151 is a
closed performance refinement concerning 0^0 and does not report this
minimum-value boundary.
was:
ArithmeticUtils.pow(-2, 31) and ArithmeticUtils.pow(-2L, 63) throw
ArithmeticException even though their exact results are Integer.MIN_VALUE and
Long.MIN_VALUE. The API documents overflow only when the result cannot fit.
Expected: those two calls return the minimum values; neighbouring overflowing
powers, such as pow(2,31) and pow(-2,32), still throw. Actual: an early
exponent guard rejects both valid boundary cases.
A standalone regression harness failed on pristine master
9b629bdfd72fc8c499795e32bf12909bf34a1f18 and passed with a local two-line guard
correction. The new JUnit test and mvn -q -pl commons-numbers-core verify
passed locally; a BigInteger comparison over a broad base/exponent range also
found no mismatches after the correction. The fix is local and has not yet been
submitted as a PR. NUMBERS-151 is a closed performance refinement concerning
0^0 and does not report this minimum-value boundary.
> ArithmeticUtils.pow rejects representable minimum-value powers
> --------------------------------------------------------------
>
> Key: NUMBERS-218
> URL: https://issues.apache.org/jira/browse/NUMBERS-218
> Project: Commons Numbers
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0
> Reporter: Aryan Ganjoo
> Priority: Major
>
> ArithmeticUtils.pow(-2, 31) and ArithmeticUtils.pow(-2L, 63) throw
> ArithmeticException even though their exact results are Integer.MIN_VALUE and
> Long.MIN_VALUE. The API documents overflow only when the result cannot fit.
> Expected: those two calls return the minimum values; neighbouring overflowing
> powers, such as pow(2,31) and pow(-2,32), still throw. Actual: an early
> exponent guard rejects both valid boundary cases.
> A standalone regression harness failed on pristine master
> 9b629bdfd72fc8c499795e32bf12909bf34a1f18 and passed with a local two-line
> guard correction. The new JUnit test and mvn -q -pl commons-numbers-core
> verify passed locally; a BigInteger comparison over a broad base/exponent
> range also found no mismatches after the correction. The fix is now submitted
> as https://github.com/apache/commons-numbers/pull/223; full local mvn clean
> verify passed, while hosted checks and maintainer review are pending.
> NUMBERS-151 is a closed performance refinement concerning 0^0 and does not
> report this minimum-value boundary.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
