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.
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 ).
On 7/1/19 9:32 AM, Gilles Sadowski wrote:
Hi.
Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne <heinrich.bo...@gmx.at> 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
