Hi Eric.
On Mon, 3 Dec 2018 10:01:39 -0800, Eric Barnhill wrote:
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.
Maybe I misunderstood, but I thought that only intermediate results
would require "BigInteger"; if the result needs to be converted to
"BigFraction", than I'd favour raising an exception (with the advice
which you mention).
If later on someone comes up with a use-case for the alternate
solution,
we can revisit.
Regards,
Gilles
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
