Agreed, but it's not clear to me that it must be part of the public API.
Yes, I admit that the public API doesn't really have anything to do with
this, I realize that now. If my last email suggested otherwise, this was
unintentional.
On 7/1/19 11:52 PM, Gilles Sadowski wrote:
Hello.
Le lun. 1 juil. 2019 à 20:23, Heinrich Bohne <heinrich.bo...@gmx.at> 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 <heinrich.bo...@gmx.at> 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 <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
---------------------------------------------------------------------
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
