Le jeu. 9 avr. 2020 à 14:09, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > > 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.
But didn't you imply above that 0 / -1 pow 2 should return 0 / 1 ? > 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. +1 > 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. Why not? > 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. I don't follow: How do you match before computing? > > 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
