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]
