[
https://issues.apache.org/jira/browse/MATH-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-1223.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.6
Fixed in git repository, with commit e4b3ac8 in the master branch (4.X) and
with commit 9e1b0ac in the MATH_3_X branch.
> Wrong splitting of huge double numbers
> --------------------------------------
>
> Key: MATH-1223
> URL: https://issues.apache.org/jira/browse/MATH-1223
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Luc Maisonobe
> Priority: Minor
> Fix For: 4.0, 3.6
>
>
> In both MathArrays and FastMath, some computations on double are performed by
> firt splitting double numbers in two numbers with about 26 bits.
> This splitting fails when the numbers are huge, even if they are still
> representable and not infinite (the limit is about 1.0e300, eight orders of
> magnitude below infinity).
> This can be seen by computing for example
> {code}
> FastMath.pow(FastMath.scalb(1.0, 500), 4);
> {code}
> The result is NaN whereas it should be +infinity.
> or by modifying test MathArraysTest.testLinearCombination1 and scaling down
> first array elements by FastMath.scalb(a[i], -971) and scaling up the second
> array elements by FastMath.scalb(b[i], +971), which should not change the
> results. Here the result is a loss of precision because a safety check in
> MathArrays.linearCombination falls back to naive implementation if the high
> accuracy algorithm fails.
> The reason for the wrong splitting is an overflow when computing
> {code}
> final int splitFactor = 0x8000001;
> final double cd = splitFactor * d; // <--- overflow
> {code}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
