Btw, I didn't just ignore this – I'm ruminating on it :-)
On Sat, Mar 1, 2014 at 6:37 PM, John Myles White
<johnmyleswh...@gmail.com>wrote:
> 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 <ste...@karpinski.org> 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 <ste...@karpinski.org>wrote:
>
>> On Fri, Feb 28, 2014 at 8:49 AM, andrew cooke <and...@acooke.org> 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.
>>
>
>
>
