aherbert commented on code in PR #138:
URL: https://github.com/apache/commons-numbers/pull/138#discussion_r1343813273
##########
commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Multiplication.java:
##########
@@ -44,4 +44,12 @@ public interface Multiplication<T> {
* @return <code>this<sup>-1</sup></code>.
*/
T reciprocal();
+
+ /**
+ * Is this the neutral element of multiplication? Implementations may want
to
+ * employ more efficient means than calling equals on the one element.
+ *
+ * @return {@code true} if {@code this} equals the result of {@link #one}.
Review Comment:
BigDecimal.equals and Double.equals have chosen binary equality. A
workaround for BigDecimal is to use compare.
We are of course free to do as we wish. I think the current documented
behaviour of numerical equality is acceptable. The change I made to DD was to
support this definition. So for now all 4 DD representations of zero are equal.
All 2 representations of one are equal. The other classes used by Field also
satisfy numerical equality. The FP64 has been changed so the two
representations of zero are equal and all representations of NaN are equal.
Regarding the neutral element of multiplication, in some cases (e.g. DD) a
multiplication by 1 may change the representation of the element if it contains
signed zeros. But the magnitude will be unchanged. The output value will be
equal to the input value when using the equals method.
If you wish to update the javadoc to reflect this behaviour then please do.
E.g. state that this method returns true if multiplication by this element will
not change the magnitude or signum of the multiplicand.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
