[jira] [Resolved] (NUMBERS-129) Waste of functionality in Fraction.addSub(Fraction, boolean)

["Heinrich Bohne (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NUMBERS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heinrich Bohne resolved NUMBERS-129.
------------------------------------
       Resolution: Fixed
    Fix Version/s: 1.0

> 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
>             Fix For: 1.0
>
>          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)