> On 9 Apr 2020, at 21:36, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le jeu. 9 avr. 2020 à 22:20, Alex Herbert <alex.d.herb...@gmail.com> a écrit : >> >> >> >>> On 9 Apr 2020, at 16:32, Gilles Sadowski <gillese...@gmail.com> wrote: >>> >>> >>> >>>> Given this I am thinking that using ZERO when possible is a better >>>> option and avoid 0 / -1. >>> >>> Hmm, then I'm both +0 and -0 (which is the same, right?) >>> on this issue. ;-) >> >> Ironically the conversion to a double is a minor bug: >> >> Fraction.of(0, 1).doubleValue() == 0.0 >> Fraction.of(0, -01).doubleValue() == -0.0 >> >> IEEE754 arithmetic for 0.0 / -1.0 creates a -0.0. >> >> Do we want to support -0.0? > > Why prevent it since it looks expected from the above call?
Well, in the against argument -0.0 is an artefact of the IEEE floating point format. It is not a real number. If we allow 0 / -1 as a fraction to mean something then we should really support it fully which means carrying the sign of the denominator through arithmetic as would be done for -0.0 (from the top of my head): -0.0 + -0.0 = -0.0 -0.0 + 0.0 = 0.0 0.0 - -0.0 = 0.0 0.0 - 0.0 = 0.0 0.0 * 42 = 0.0 -0.0 * 42 = -0.0 And so on... It is easier to exclude this representation from ever existing by changing the factory constructor to not allow it. Note that Fraction.of(-0.0) creates 0 / 1. So the support for 0 / 1 is inconsistent with conversion to and from double: Fraction.of(-0.0).doubleValue() == 0.0 Fraction.of(0, -1).doubleValue() == -0.0 I have checked and Fraction.of(0, 1).compareTo(Fraction.of(0, -1)) is 0. They evaluate to equal and have the same hash code. So this behaviour is different from Double.compareTo, Double.equals and Double.hashCode which distinguishes the two values. If fraction represented a signed number using the signed numerator and an unsigned denominator, reduced to smallest form, then the representation of zero is fixed. It would be 0 / 1 as you cannot have -0 as an integer. This issue has been created by the support for the sign in either part so that Integer.MIN_VALUE can be used as a denominator. This is a nice change to allow support for fractions up to 2^-31. But creates this signed zero issue. It leads me to think we should have a canonical representation of zero as 0 / 1 and prevent creation of 0 / -1 by careful management of class creation. > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
