You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2019/07/05 22:26:00 UTC
[jira] [Commented] (NUMBERS-129) Waste of functionality in
Fraction.addSub(Fraction, boolean)
[ https://issues.apache.org/jira/browse/NUMBERS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16879545#comment-16879545 ]
Gilles commented on NUMBERS-129:
--------------------------------
Merged into "master" with slight changes. Please check.
> 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: 0.5h
> 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)