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

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

Heinrich Bohne created NUMBERS-129:
--------------------------------------

             Summary: 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


[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)