commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <>
Subject Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding
Date Mon, 03 Dec 2018 18:01:39 GMT
> Does this mean that computations can "unpredictably" overflow
> (or throw an exception)?

The ArithmeticUtils() methods mulAndCheck and addAndCheck throw exceptions
if there is overflow during primitive operations. That is the "check" part
of the method name.

> Is it acceptable, or should we enclose the problematic code in
> a "try" block and redo the computation with "BigInteger" when
> necessary?
> What is the performance hit of using "BigFraction" rather than
> "Fraction"?

I once used BigDecimal for a project, it is great code but the performance
is nothing close to using primitives.

> Are there use-cases that would need the ultimate performance from
> "Fraction" while not worry about overflow?

You would need a greatest common factor between the two fractions that was
larger than 64 bits.

Again, BigFraction is there for anyone worried about such a case and there
is no significant performance hit to switching over to BigFraction compared
to a Fraction class that was using BigInteger under the hood. But I
suspect  there would be a substantial performance gain if longs were being
used under the hood for the Fraction class for the more common use case of
smaller fractions. If it would be best practice, a bit of microbenchmarking
could be done to check.

A FractionOverflowException could be specifically tailored to this use case
and the error message can suggest using BigFraction. Or as you suggest, the
catch block could silently or with warning return a BigFraction. If we have
class inheritance straight, and both Fraction and BigFraction have the
exact same interface, this could be an elegant solution.


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