The key behavioral difference between these two is that with the
non-parametric union version you can change both the value and the type of
the field of a MyType object after construction, whereas in the parametric
version you can change the value of the field after an object has been
constructed,
On Wednesday, October 28, 2015 at 8:10:41 AM UTC-4, Stefan Karpinski wrote:
>
> The key behavioral difference between these two is that with the
> non-parametric union version you can change both the value and the type of
> the field of a MyType object after construction, whereas in the
Yeah, that's a good point. When you give the compiler the assurance that
"I'm not going to change the type of x here", you also loose the
possibility to do that :) Type instabilities are a major performance
bottleneck (one of the most common performance problems, actually...) but
in many
With a type declared like that, any access of the field x will be type
unstable, which means that Julia’s JIT compiler will emit much more
defensive, and thus slower, code.
The solution is to declare a *parametric* type:
type MyType{T<:Union{Int64, Float64}}
x::T
end
That way, MyType(3)
that makes sense. many thanks!
在 2015年10月28日星期三 UTC+8下午3:14:26，Tomas Lycken写道：
>
> With a type declared like that, any access of the field x will be type
> unstable, which means that Julia’s JIT compiler will emit much more
> defensive, and thus slower, code.
>
> The solution is to declare a
One reason would be to reduce pressure on the compiler: this will perform
badly in terms of memory usage and compilation time because a separate
version of "f" has to be compiled for every "T":
immutable X{T}
val::T
end
f(x) = println("got $(x.val)")
for i=1:10^5
f(X((zeros(i)...)))
end
