[jira] [Resolved] (MATH-1248) BigFraction optimizations around object creation for ZERO values and reduce()

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

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

Gilles resolved MATH-1248.
--------------------------
    Resolution: Fixed

> BigFraction optimizations around object creation for ZERO values and reduce()
> -----------------------------------------------------------------------------
>
>                 Key: MATH-1248
>                 URL: https://issues.apache.org/jira/browse/MATH-1248
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.5
>            Reporter: Chris Popp
>            Priority: Minor
>             Fix For: 3.6
>
>         Attachments: MINIMIZEALLOCATION-MATH-1248.patch
>
>
> In many cases a BigFraction object may represent a fraction in its most reduced form.  Despite this, the reduce() method doesn't bother checking whether the BigFraction needs to be reduced before returning a new object.
> This is problematic because equals() calls reduce() on both operands.  This means that doing a simple comparison like BigFraction.ONE.equals(BigFraction.TWO) will result in two object allocations.
> Additionally, while there is a very minimal attempt at optimizing around operations that take in a parameter of BigFraction.ZERO, it is somewhat inconsistent and incomplete.  For example, BigFraction add(final BigFraction fraction) checks to see whether the incoming fraction is zero and if so, returns *this*.  Why doesn't it also check whether *this* is zero and return the incoming fraction if so, avoiding an allocation?  
> This is one example, but it exists in other locations where we not only end up with allocations but expensive arithmetic operations as well (multiplication or exponentiation).
> At minimum I think the reduce() method should just return *this* if gcd <= 1.
> I attached a patch with the change for reduce() and some ideas for avoiding object allocations, attempting to follow the patterns in BigInteger.  I verified all of the tests in the commons math pass after the changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)