On Mon, Jul 20, 2015 at 6:21 PM, Mathew <[email protected]> wrote: > I'm not clear on the following element in Julia FAQ: > http://julia.readthedocs.org/en/latest/manual/faq/#how-do-abstract-or-ambiguous-fields-in-types-interact-with-the-compiler > > In a nutshell, the FAQ defines two types: > > >> type MyStillAmbiguousType >> a::FloatingPoint >> end >> t = MyStillAmbiguousType(3.2) >> >> type MyType{T<:FloatingPoint} >> a::T >> end >> m = MyType(3.2) >> >> The fact that the type of m.a is known from m‘s type—coupled with the >> fact that its type cannot change mid-function—allows the compiler to >> generate highly-optimized code for objects like m but not for objects >> like t. > > I don't really understand this passage (I don't know anything about > compilers to begin with!) > > - If the acceleration comes from the fact the type is known before the > function is runned, can't the compiler create itself functions with all > fields of the type as argument, rather than the type as an argument, ie > transforming > > f(t::MyStillAMbiguousType) > > into > > f(t::MyStillAMbiguousType) = f(fa::FloatingPoint = t.a) > > More bluntly, another solution would be something like > > function f(t::MyStillAmbiguousType) > if typeof(f.a) == Float64 > f1(t) > elseif typeof(f.a) == Float32 > f2(t) > end > end >
This is good point though. Ref https://github.com/JuliaLang/julia/issues/10805 > > - If the acceleration comes from the fact that "its type cannot change > mid-function", why don't we replace every arguments of a function by an type > that encloses its fields, to declare that the type won't change in the body > of the function. For instance, instead of `f(x::Float64)`, define > > type EnclosedFloat > x::Float64 > end > f(x::EnclosedFloat) > > >
