Yes, that's what I meant. I just realized all you need to do % 2^32 or & 0xffffff whenever you add... disregard that lol
On Thursday, March 13, 2014 10:10:45 PM UTC-4, John Myles White wrote: > > By integer overflow, do you mean wrapping arithmetic like you’d get from > doing everything mod N for some integer N? > > — John > > On Mar 13, 2014, at 7:08 PM, Ben <[email protected] <javascript:>> wrote: > > Sorry if this is hijacking the thread, but I'm wondering is there a way to > force integer overflow? I think it would be useful for things like sliding > window protocols. > > Also, is there a way to release julia code that works on both 32 bit and > 64 bit machines? (it sounds like annotating types as 32-bit isn't enough) > > Great language by the way! > > On Saturday, March 1, 2014 6:30:00 PM UTC-5, Stefan Karpinski wrote: >> >> There's been many discussions of this before. The basic premise is >> simple: all integer arithmetic is done in your native word size. When you >> store that result somewhere, it is converted to the storage type. Since you >> can do most operations on Int64s and then convert to Int32 and get the >> exact same answer, this works out fine. I have yet to hear a really >> convincing argument for why we shouldn't just do everything in native int >> size. >> >> >> On Sat, Mar 1, 2014 at 6:26 PM, Stefan Karpinski <[email protected]>wrote: >> >>> On Fri, Feb 28, 2014 at 8:49 AM, andrew cooke <[email protected]> wrote: >>> >>>> defining >>>> Base.promote_rule(::Type{Int32}, ::Type{Int32}) = Int32 >>>> doesn't help either, and i'm not sure why. >>>> >>> >>> Promotion only applies when the types don't already have the same type. >>> When you write int32(1) + int32(2) you call this method: >>> https://github.com/JuliaLang/julia/blob/master/base/int.jl#L16, which >>> explicitly converts the values to your native Int type and then does the >>> work. >>> >> >> >
