For me, what’s confusing about the up-promotion of arithmetic operations is
that you wind up with type-changes that you might not expect:
function foo()
a = 0x01
println(typeof(a))
b = 0x02
a = a + b
println(typeof(a))
end
foo()
I still find the change in type of a to be unexpected. Obviously I can resolve
this by doing things like,
function foo()
a = 0x01
println(typeof(a))
b = 0x02
a::Uint8 = a + b
println(typeof(a))
end
foo()
but that leaves me with another source of confusion: when should I be asserting
the type of a variable vs doing something like,
function foo()
a = 0x01
println(typeof(a))
b = 0x02
a = uint8(a + b)
println(typeof(a))
end
foo()
— John
On Mar 1, 2014, at 3:30 PM, Stefan Karpinski <[email protected]> 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.
>
