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]
