[
https://issues.apache.org/jira/browse/NUMBERS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved NUMBERS-205.
----------------------------------
Fix Version/s: 1.2
Resolution: Implemented
Added in commit:
a514149aadea1542c9c00004a0367f8ee2247c95
> Add isZero() to interface Addition and isOne() to Multiplications
> -----------------------------------------------------------------
>
> Key: NUMBERS-205
> URL: https://issues.apache.org/jira/browse/NUMBERS-205
> Project: Commons Numbers
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.1
> Reporter: Harald Kirsch
> Priority: Major
> Fix For: 1.2
>
>
> h2. Rationale
> While coding polynomial computations over differing fields with commons math3
> where the field is a generic parameter in the implementation of monomials and
> polynomials, I coded the comparison with {{zero}} and {{one}} as
> {{coefficient.getField().getZero().equals(coefficient)}}.
> With commons-numbers this gets slightly less cumbersome as
> {{coefficient.zero().equals(coefficient)}}, but cumbersome and somewhat weird
> looking it is still.
> But the look of it is not the only problem: employing async-profiler I saw
> that the {{equals()}} required a non-negligible amount of CPU power, in
> particular for the BigFraction field, which in some cases near-duplicates the
> value to be compared due to calls to negate().
> h2. Requirement
> * Add a method {{isZero()}} to interface Addition which returns true iff the
> object is semantically equivalent to the object returned by {{zero()}}.
> * Add a method {{isOne()}} to interface Multiplication which returns true
> iff the object is semantically equivalent to the value returned by {{one()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
