commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <>
Subject Re: [numbers-fraction] Double approximation constructor/factory method overhaul
Date Wed, 17 Jul 2019 00:29:53 GMT
On Tue, Jul 16, 2019 at 2:41 PM Heinrich Bohne <>

> > Do you think we really even need a BigFraction class at all in the
> context
> > of these upgrades? Or should one of the Fraction factory methods just
> take
> > BigInteger argumentsm and all fractions use the lazy dynamic method of
> > calculation you are proposing?
> I don't quite understand what you mean by this. The BigInteger class
> provides flexibility and the ability to store and operate on
> (practically) unlimited values, which Fraction does not have. The
> Fraction class, on the other hand, is faster and more memory efficient,
> due to its use of primitive values, which is an advantage over
> BigFraction.

That's fine.

> I am even more confused by your suggestion seeing as it was
> you who banned BigInteger from Fraction.addSub(Fraction, boolean) in
> , which, even though
> you were not aware of it at that time, did not limit the method's
> functionality in any way whatsoever (the use of int rather than long
> did, however, but this is now fixed).

I don't know what you mean by "functionality" but constructing a BigInteger
for every fraction multiplication uses up more memory and operations than
necessary and scales poorly. BigIntegers are not fast.

However, I understand why the previous coders incorporated a BigInteger and
I'm not sure that you do. The reason it was done was because Knuth proved
(as in mathematical proof) that a long is insufficient for certain fraction
multiplications where both numerator and denominator are large ints; 65
rather than 64 bits are necessary and a long will not suffice. For me,
these cases are so extreme and likely so rare that we might as well let
them fail, report to the user that these cases need to be handled with
BigFraction and leave it there. It could easily be handled in a try catch
block and such a block would be high performance.

That was the judgment I made and it is open to interpretation, provided
such interpretation agrees with Knuth's proof. We are entitled to our own
opinions but not our own facts.

Anyway I think your approximation schemes sound good and implement them
however you see fit.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message