Petr,
You should be able to do something like the following:
function foo(n::Integer)
if iseven(n)
return 1.0
else
return 1
end
end
function bar1()
x = foo(1)
return x
end
function bar2()
x = foo(1)::Int
return x
end
julia> code_typed(bar1, ())
1-element Array{Any,1}:
:($(Expr(:lambda, Any[],
Any[Any[:x],Any[Any[:x,Union(Float64,Int64),18]],Any[]], :(begin # none, line
2:
x = foo(1)::Union(Float64,Int64) # line 3:
return x::Union(Float64,Int64)
end::Union(Float64,Int64)))))
julia> code_typed(bar2, ())
1-element Array{Any,1}:
:($(Expr(:lambda, Any[], Any[Any[:x],Any[Any[:x,Int64,18]],Any[]], :(begin #
none, line 2:
x = (top(typeassert))(foo(1)::Union(Float64,Int64),Int)::Int64 # line 3:
return x::Int64
end::Int64))))
In the output of code_typed, note how the strategically placed type declaration
at the point at which a type-unstable function is called resolves the type
inference problem completely when you move downstream from the point of
ambiguity.
-- John
On Dec 12, 2014, at 12:20 AM, Petr Krysl <krysl.p...@gmail.com> wrote:
> John,
>
> I hear you. I agree with you that type instability is not very helpful,
> and indicates problems with program design.
> However, I believe that provided the program cannot resolve the types
> properly (as it couldn't in the original design of my program, because I
> haven't provided declarations of variables where they were getting used,
> only in their data structure types that the compiler apparently couldn't
> see), the optimization for loop performance cannot be successful. It
> certainly wasn't successful in this case.
>
> How would you solve the problem with storing a function and at the same
> time allowing the compiler to deduce what values it returns? In my case I
> store a function that always returns a floating-point array. However, it
> may return a constant value supplied as input to the constructor, or it may
> return the value provided by another function (that the user of the type
> supplied).
>
> So, the type of the return value is stable, but I haven't found a way of
> informing the compiler that it is so.
>
> Petr
>
>
>
>
> On Thursday, December 11, 2014 8:20:20 PM UTC-8, John Myles White wrote:
> > The moral of this story is: If you can't or won't declare every single
> > variable, don't do loops. They are likely to be a losing proposition.
>
> I don't think this lesson will serve most people well. It doesn't reflect my
> experiences using Julia at all.
>
> My experience is that code that requires variable type declarations usually
> suffers from a deeper problem that the variable declarations suppress without
> solving: either (a) there's some insoluble source of ambiguity in the program
> (as occurs when calling a function that's passed around as a value and
> therefore not amenable to static analysis) or (b) there's some subtle source
> of type instability, as happens sometimes when mixing integers and floating
> point numbers.
>
> -- John
>
