Le jeu. 9 avr. 2020 à 23:20, Alex Herbert <alex.d.herb...@gmail.com> a écrit : > > > > > 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 seems to be the winning argument to transform all zero to canonical form. > 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. +1 Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
