It would really be helpful it the conversion rules, especially the ones that might effect performance, were stated more clearly. Alternatively, a debug-mode for the runtime or a separate ahead-of-time tool could be useful.
Given that Julia is a bit of a moving target, I'm sometimes not clear about which behaviors are a consequence of the language design and which are simply occur because a certain optimization has not been created. On Sun, Jan 19, 2014 at 10:58 AM, Job van der Zwan <[email protected] > wrote: > I must say, I'm really surprised that adding two Int32 variables results > in an Int64 - I naively assumed Julia to work like this: > > a::T > b::T > (a+b)::T > > If people explicitly type a variable as an 32 bit integer, I think it's > safe to assume they want to keep it that way unless there is no other > option - like some kind of "principle of least promotion/conversion." > > On Thursday, 16 January 2014 14:41:32 UTC+1, Stefan Karpinski wrote: >> >> On Thu, Jan 16, 2014 at 1:39 AM, Tobias Knopp >> <[email protected]>wrote: >> >>> But why isn't float32 promoting to float64 on basic arithmetics then? >>> >> >> Well, it used to. But there were enough people who really wanted to use >> Float32 arithmetic, so we changed it. The squeaky wheel gets oiled. >> >> As Markus pointed out, when we get SIMD support (in the form of the @simd >>> macro or by autovectorization of llvm) there can be a factor of two between >>> both integer computations. >>> >> >> This is a very legitimate concern, and we may have to revisit this >> decision. >> >
