Hello. Le lun. 1 juil. 2019 à 20:23, Heinrich Bohne <[email protected]> a écrit : > > > Is there a case where *not* knowing whether the fraction is reduced or > > not is detrimental? > > Hm, maybe you're right and specifying this (as well as where the sign is > stored) in the public API is not that important, as long as the > combination of returned numerator and denominator is valid. The only > benefit would have been that the user would have the certainty that the > returned values are already reduced to lowest terms, so that, in case > this matters to the user, they don't need to reduce the values > themselves. But whether this would outweigh the reduced flexibility of > the API is something that probably cannot be answered without the > ability to predict the future. > > However, what *is* crucial is specifying these things in the > documentation of the private fields that hold the numerator and > denominator, because a lot of the class' implementation relies on this.
Sure. The code doc should indicate all current assumptions. By not leaking them into the public API, we keep the flexibility until usage requires to go one way or another. > In fact, I noticed that BigFraction.hashCode() was broken before the > resolution of NUMBERS-119 and NUMBERS-125, because, while > BigFraction.equals(Object) reduced the numerators and denominators > before comparing them, hashCode() didn't. > > Specifying the reduction to lowest terms of the fields numerator and > denominator is even more important in Fraction than in BigFraction, > because the magnitude of the values stored in these fields has an impact > on whether arithmetic operations overflow or don't. Agreed, but it's not clear to me that it must be part of the public API. Gilles > > On 7/1/19 7:03 PM, Gilles Sadowski wrote: > > Hello. > > > > Le lun. 1 juil. 2019 à 12:35, Heinrich Bohne <[email protected]> a > > écrit : > >>> Couldn't it entail a loss of opportunity to allow "non-reduced" fractions > >>> for efficiency reason? > >> Yes, it would, but I can't envision a scenario where this would be > >> detrimental. Of course, I may be missing something. > > Is there a case where *not* knowing whether the fraction is reduced or > > not is detrimental? > > > >>> But I don't follow; if it's an implementation detail, it should not appear > >>> anywhere in the doc, and users should not rely on it. > >> What I meant is that it would be an implementation detail how the > >> numerator and denominator are stored. What the methods getNumerator() > >> and getDenominator() return should, of course, be specified > >> appropriately (for example, something like "returns the numerator of > >> this fraction's representation in lowest terms"). > >> > >> It just occurred to me that the question of where something should be > >> documented can also be applied to the sign being held by the numerator > >> rather than the denominator in case of negative fractions (which, if I'm > >> not mistaken, is currently only specified in > >> Fraction.getReducedFraction(int, int), a method that is targeted for > >> deletion in https://issues.apache.org/jira/browse/NUMBERS-125 ). > > Good catch. > > It's a similar issue: Is knowing where the sign is stored useful to users or > > can it be considered an implementation detail (leaving more freedom to > > change it)? > > Wouldn't a method "isNegative()" be a better alternative? > > > > Regards, > > Gilles > > > > > >> > >> On 7/1/19 9:32 AM, Gilles Sadowski wrote: > >>> Hi. > >>> > >>> Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne <[email protected]> a > >>> écrit : > >>>> I've recently been wondering about the following: > >>>> > >>>> With the resolution of NUMBERS-119 > >>>> (https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in > >>>> Fraction and BigFraction reduce the created fraction to lowest terms (in > >>>> the constructor Fraction(double, double, int, int), this is not obvious, > >>>> but because the convergents of a simple continued fraction are > >>>> automatically reduced to lowest terms when calculated with the recursive > >>>> formula used in the constructor, the fraction returned thereof is also > >>>> reduced to lowest terms). > >>>> > >>>> This rises the following question: Would it not be better if this > >>>> reduction to lowest terms were made part of the contract of the two > >>>> fields storing the numerator and denominator (i.e. included in their > >>>> documentation), and, as a consequence, of the corresponding public > >>>> accessor methods? > >>> Couldn't it entail a loss of opportunity to allow "non-reduced" fractions > >>> for efficiency reason? > >>> > >>>> Then the fact that the fraction is reduced to lowest > >>>> terms when created from a constructor or a public factory method would > >>>> become an implementation detail irrelevant to the caller of the > >>>> method/constructor, which could also prevent confusion, seeing as the > >>>> numerator-denominator factory methods are the only ones that explicitly > >>>> state that the fraction is reduced to lowest terms, even though this is > >>>> true for all other factory methods as well. > >>> The doc should be fixed. > >>> But I don't follow; if it's an implementation detail, it should not appear > >>> anywhere in the doc, and users should not rely on it. > >>> > >>> Regards, > >>> Gilles > >>> > >>>> Also, fractions returned from arithmetic operations are thereby also > >>>> implicitly specified as being reduced to lowest terms, rendering > >>>> mentions of this fact in these methods' documentation obsolete. > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
