[
https://issues.apache.org/jira/browse/NUMBERS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184189#comment-17184189
]
Alex Herbert commented on NUMBERS-149:
--------------------------------------
Adding the cache increase the memory footprint. I think this is a negative for
the primary use case of performing computations.
Note that hashCode is currently a branchless computation so a cache may not be
as performant as you expect. It is certainly an implementation detail. The
cache is implemented not using best practice anyway. The member variable should
be copied locally and this checked, computed if necessary and returned. This
avoids duplicate access to memory:
{code:java}
int value = this.value;
if (value == 0) {
value = this.value = computeValue();
}
return value;
{code}
Note: String is a special case where the hashCode computation can be expensive
if the string is long. String can also be interned and so common strings refer
to the same object and the cache is of more value.
The factory constructor using the whole and parts is currently served using:
{code:java}
int whole;
int numerator;
int denominator;
Fraction sum = Fraction.of(whole).add(Fraction.of(numerator, denominator));
{code}
Adding the method is not essential.
Porting the other methods marked as deprecated makes no sense. Anyone switching
APIs will be able to handle method name changes in 5 minutes.
The fix to Fraction.pow to handle MIN_VALUE should be in a separate ticket and
PR.
> port functions / tests in commons-lang for Fraction.
> ----------------------------------------------------
>
> Key: NUMBERS-149
> URL: https://issues.apache.org/jira/browse/NUMBERS-149
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
> Reporter: Jin Xu
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://github.com/apache/commons-numbers/pull/82
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
