insaf021 opened a new pull request, #342:
URL: https://github.com/apache/commons-math/pull/342
Dfp(DfpField, String) copies at most getRadixDigits() * 4 + 1 significant
digits into its scratch buffer and stops reading the input once that buffer is
full. If no decimal point has been seen by then, the decimal position is taken
from the number of digits stored rather than the number of integer digits in
the string, so every digit past the precision is lost from the exponent as well
as the mantissa. With the default 20-digit field,
newDfp("123456789012345678901234567890") returns 1.2345678901234568e20 instead
of roughly 1.23e29, and "1234567890123456789012345678.5" gives the same e20
value because its decimal point sits past the cut-off and is never reached. The
result is a finite, plausible-looking number that is off by a factor of ten per
excess digit, with nothing beyond FLAG_INEXACT to signal it. It shows up when
comparing toDouble() of long decimal strings against Double.parseDouble: the
two agree up to 21 digits and then diverge sharply. When the buffer fills
before a dec
imal point, the constructor now counts the remaining integer digits up to the
point and uses that as the decimal position, so the value is still rounded at
the precision limit but keeps its exponent; this is separate from the exponent
handling changed in #341. The new test in DfpTest fails on master with `x =
1.2345678901234568e20` and passes with the patch, and `mvn verify` on
commons-math-core, commons-math-legacy-exception and commons-math-legacy-core
is clean, as are the Dfp-using tests in commons-math-legacy.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
