Clever. Thanks!
Petr
On Thursday, December 11, 2014 9:26:34 PM UTC-8, John Myles White wrote:
>
> 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 <[email protected] <javascript:>>
> 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
> >
>
>
