commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [numbers] Fraction() and Knuth 4.5.1 -- overflow, BigInteger, long, and rounding
Date Mon, 03 Dec 2018 23:33:25 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message