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