On 09/04/2020 12:04, Alex Herbert wrote:
So if we are to support 0/-1 then I will add this to the standard test
cases to make sure it is correctly implemented.
So I did this. No major functionality failures.
However there is a discrepancy between multiply and other functions.
Multiply will return the form 0 / 1 for zero when either argument is zero.
Divide will return the current instance if the instance is zero.
Add/subtract will return the current instance if the instance to add is
zero.
Pow will return the current instance if the instance is zero.
So you get this:
0 / -1 multiply 1 / 3 == 0 / 1
0 / -1 divide 1 / 3 == 0 / -1
0 / -1 add 0 / 1 == 0 / -1
0 / -1 pow 1 == 0 / -1
0 / -1 pow 2 == 0 / -1
In the later case you may actually expect pow(0 / -1, 2) to return 0 /
1. The result would require a change of sign on the denominator when the
power is even.
So do we:
1. return the canonical form 0 / 1 when the result is zero?
2. return the appropriate instance that is zero when the result is zero?
3. maintain the sign as if implemented using the arithmetic on the
denominator?
I do not see a situation where preserving the signedness of the zero
denominator is important. This rules out 3.
It makes it cleaner in the code to always return Fraction.ZERO when
operations result in zero. This has memory advantage by allowing the
garbage collection of fractions that are zero when they go out of scope
following computations. This is a weak argument as it is unlikely to
save much memory in common usage. It is also possible to create zeros in
computation and we do not want to go the route of switching new 0/1
instances to ZERO.
The easiest change is to just update multiply to return the appropriate
zero instance and not use Fraction.ZERO. The classes then are consistent
across the methods. Return the appropriate fraction instance if it
matches the result, otherwise compute the result.
The ZERO constant then is reduced to a convenience as for the ONE constant.
So my vote is option 2 for code consistency.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
