Julia has functions for checked integer arithmetic on the base integer 
types which raise an OverflowError().

   using Base.Checked # now these functions are available for use:
# checked_neg, checked_abs, checked_add, checked_sub, checked_mul # 
checked_div, checked_rem, checked_fld, checked_mod, checked_cld
As I recall,  the current try .. catch mechanism is not optimized for that 
sort of heavy use within conditional logic.
So the approach you suggest is reasonable to me.  Fredrik Johansson does 
something similar in the way his Arb software,
written in C, interacts internally with what would be Julia's BigFloat. 
 The package Nemo.jl gives access to some of Arb
and FLINT (Fast multiprecision integers) within Julia.

Arb doc <http://fredrikj.net/arb/>     Nemo doc 
<http://nemocas.org/nemo-0.4.pdf>   



On Friday, April 8, 2016 at 2:07:30 AM UTC-4, Laurent Bartholdi wrote:
>
> Dear all,
> How hard would it be to code arbitrary-precision integers in Julia with at 
> worst 2x performance loss over native Ints?
>
> This is what I have in mind: have a bitstype structure, say 64 bits, which 
> is either the address of a BigInt (if even), or an Int64 (if odd). Addition 
> would be something like:
>
> function +(a::FastInt,b::FastInt)
>     if a&b&1
>         (result,obit) = @llvm.sadd.with.overflow.i64(a,b&~1)
>         obit ? reinterpret(FastInt,BigInt(a>>1)+(b>>1)) : result
>     elseif a&1
>         reinterpret(FastInt,(a>>1) + reinterpret(BigInt,b))
>     elseif b&1
>         reinterpret(FastInt,reinterpret(BigInt,a) + b>>1)
>     else
>         reinterpret(FastInt,reinterpret(BigInt,a) + reinterpret(BigInt,b))
>     end
> end
>
> (code not meant to be run, just a skeleton)
>
> This would be very useful in the development of computer algebra systems, 
> in which BigInts are too slow and eat up too much memory, but one is ready 
> to pay a small price for guard against arithmetic overflows.
>
> If this is too complicated, then perhaps at least a type of integers that 
> would raise an error in case of over/underflows? Those could be caught in 
> throw/catch enclosures, so the user could restart the operation with 
> BigInts.
>
> TIA, Laurent
>

Reply via email to