simpleqt opened a new pull request, #225:
URL: https://github.com/apache/commons-numbers/pull/225

   `DD.longValue()` documents a truncating cast towards zero (`(long) -2.75 => 
-2`), and the existing tests check it against `bigDecimalValue().longValue()`. 
A double-double whose high part is a whole number is converted by truncating 
both parts towards zero and summing them, but the sum is accepted only if it 
keeps the sign of the high part.
   
   For a value in the interval `(-1, 0)`, i.e. a high part of -1 with a 
positive low part, the truncation correctly produces `0`, which is then 
discarded as if it were an overflow:
   
   ```
   DD.ofSum(-1.0, 1e-20).longValue()  // -1  (expected 0)
   DD.ofSum(-1.0, 1e-20).intValue()   // -1  (expected 0)
   DD.ofSum(-1.0, 1e-20).doubleValue()      // -1.0
   DD.ofSum(-1.0, 1e-20).bigDecimalValue()  // -0.99999999999999999999...
   ```
   
   The mirror value `DD.ofSum(1.0, -1e-20)` already returns 0, as does any 
value away from zero, e.g. `DD.ofSum(-3.0, 1e-20)` returning -2.
   
   Root cause: `DD.java:756-762` (upstream `master`) summed the parts with `a1 
+ b + a2` and kept the result only when `(sum ^ a) >= 0`, a sign-change check 
that cannot distinguish the legitimate zero result of a value in `(-1, 0)` from 
an overflow. The check was introduced for the case where the high part is 2^63 
and the low part adds magnitude, i.e. a value outside the range of a `long`.
   
   Fix: sum with `Math.addExact`, which detects exactly when the value is 
outside the `long` range, and accept a zero sum. The existing behaviour for all 
other inputs, including the 2^63 cases covered by `DDTest#testLongValue` and 
the sums of longs in `DDTest#testLongSum`, is unchanged.
   
   The same defect is reachable through `intValue()`, for example 
`DD.ofSum(Integer.MIN_VALUE, 1e-7).longValue()`, where the truncation reaches 
one above the minimum int.
   
   Validation:
   - New regression test 
`DDTest#testLongValueTruncatesTowardsZeroWhenTheLowPartReversesTheSign` fails 
on the pre-fix base (1 of 1 tests, `longValue ==> expected: <0> but was: <-1>`) 
and passes with the fix.
   - `mvn -B -ntp verify` passes on the whole reactor, including checkstyle, 
RAT, SpotBugs and the 17935 `DDTest` cases.
   
   No `src/changes/changes.xml` entry is included: the entry format requires a 
JIRA issue key and I do not have a JIRA account. Happy to add one if you create 
or point me at a suitable NUMBERS ticket.
   
   AI assistance used to diagnose and fix this defect; the analysis and the 
change have been reviewed and verified as described above.
   


-- 
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]

Reply via email to