[
https://issues.apache.org/jira/browse/NUMBERS-129?focusedWorklogId=272639&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-272639
]
ASF GitHub Bot logged work on NUMBERS-129:
------------------------------------------
Author: ASF GitHub Bot
Created on: 05/Jul/19 15:15
Start Date: 05/Jul/19 15:15
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #64: NUMBERS-129: Use long
instead of int for intermediate results in Frac…
URL: https://github.com/apache/commons-numbers/pull/64#issuecomment-508790731
[](https://coveralls.io/builds/24393543)
Coverage decreased (-0.002%) to 94.25% when pulling
**510e23218f51e4391827b8121ba7c4c0cc9c52f9 on Schamschi:NUMBERS-129** into
**e44b91e461c730873c4e4e7c4e4c3dc84c73ec53 on apache:master**.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 272639)
Time Spent: 20m (was: 10m)
> Waste of functionality in Fraction.addSub(Fraction, boolean)
> ------------------------------------------------------------
>
> Key: NUMBERS-129
> URL: https://issues.apache.org/jira/browse/NUMBERS-129
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
> Affects Versions: 1.0
> Reporter: Heinrich Bohne
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [NUMBERS-79|https://issues.apache.org/jira/browse/NUMBERS-79], which has been
> marked as resolved by now, suggested to replace the usage of {{BigInteger}}
> in the method {{Fraction.addSub(Fraction, boolean)}} with primitive {{long}}
> values for the sake of performance. However, the ticket's
> "[resolution|https://github.com/apache/commons-numbers/commit/7c2486362b64201fd8dc19b2df12aefba2a4165a]";
> does not use {{long}}, but {{int}} variables (as I hinted at in a comment in
> the ticket about a month ago, when the code was still in the branch
> fraction-dev and not merged into master yet), although the method's
> documentation was changed to state that the method uses the {{long}} datatype.
> So for one thing, the method's documentation makes claims about the method's
> implementation that are simply not true, and for another, the usage of
> {{int}}s can cause the method to fail, while using {{long}}s would _always_
> produce the correct result because an overflow would never occur (which I
> also explained in the aforementioned comment in the ticket).
> As for performance: I doubt that three {{int}}\-to\-{{long}} conversions
> and subsequent multiplications and one {{Math.toIntExact(long)}} invocation
> are significantly less performant than three {{Math.multiplyExact(int, int)}}
> and one {{Math.addExact(int, int)}} invocation (if at all), so using
> {{int}}s rather than {{long}}s sacrifices functionality for practically
> nothing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
