Ah, ok, good. Just making sure. There are only a few folks who know those
internals well enough to speak directly to your question, but I can say
that this seems to be the consistent behavior for all anonymous functions.
You'll probably need to test for it and work around it, I'm afraid:
julia> f = (x) -> x
(anonymous function)
julia> f.code
AST(:($(Expr(:lambda, {:(x::Any)}, {{},{{:x,:Any,0}},{}}, :(begin # none,
line 1:
return x
end)))))
On Tuesday, April 14, 2015 at 4:43:43 PM UTC-4, Todd Anderson wrote:
>
> The problem is that we are doing complicated AST transformations and so we
> need to know what types to expect for each field of all the AST nodes and
> in this case for these :lambda AST nodes. Yes, the AST is not formally
> defined and can change at any moment but we are doing what we are doing and
> so far things have been reasonably consistent. I just haven't seen
> anything other than Array{Symbol,1} for the first :lambda argument.
>
> On Tuesday, April 14, 2015 at 11:54:55 AM UTC-7, Matt Bauman wrote:
>>
>> I think you're getting caught up on a red herring. Is your root problem
>> that the function isn't performing as well as you'd like? This is a well
>> known issue with anonymous functions. You'd be better off writing a for
>> loop to iterate over `j` yourself, or figuring out a way to make use of
>> Base's reduction functions.
>>
>> On Tuesday, April 14, 2015 at 2:25:17 PM UTC-4, Isaiah wrote:
>>>
>>> I've highlighted in red below the part of the lambda that is of :(::)
>>>> type.
>>>
>>>
>>>
>>> #s2 = cartesianarray(AST(:($(Expr(:lambda, {:(j::Any)},
>>>> {{},{{:j,Any,0}},{{:weights,Array{Float64,2},1}}}
>>>
>>>
>>>
>>> Sorry if I am being dense here, but:
>>>
>>> julia> typeof(:(j::Any))
>>>> Expr
>>>
>>>
>>> so, I still can't tell where you are seeing `:(::)` as a type. The code
>>> that you highlighted in red is just quoted. I'm guessing that what you are
>>> seeing is an artifact of the nested expression quoting (or quite possibly a
>>> bug in `show` for nested quote blocks).
>>>
>>> On Tue, Apr 14, 2015 at 11:36 AM, Todd Anderson <[email protected]>
>>> wrote:
>>>
>>>> I've highlighted in red below the part of the lambda that is of :(::)
>>>> type. When I first saw that, I assumed it was of SymbolNode type so I
>>>> added some code to handle that case but that code didn't execute. I then
>>>> inspected the type by hand and found it was of :(::) type. (It seems that
>>>> printing a SymbolNode won't print the type if the type is Any whereas
>>>> :(::)
>>>> always prints the type. Also, note that for non-Any types, the print
>>>> style
>>>> of SymbolNode and :(::) seem identical so you can't disambiguate them
>>>> easily through printing.)
>>>>
>>>> I can understand a difficulty in type inference for the array elements
>>>> that are being created. It seems like it should be an easier task though
>>>> to infer that at worst "j" is Unsigned.
>>>>
>>>> On Monday, April 13, 2015 at 7:19:22 PM UTC-7, Isaiah wrote:
>>>>>
>>>>> This shows the first lambda arg again as :(j::Any) of type :(::). In
>>>>>> my real code, it was at least figuring out in the second lambda arg to
>>>>>> type
>>>>>> "j" as {:j,Int64,0} but in this example it doesn't even figure out that
>>>>>> "j"
>>>>>> has to be of some Unsigned type and punts back to Any ({:j, Any, 0}).
>>>>>
>>>>>
>>>>> I'm not sure I follow -- I don't see any type annotation of `:(::)`.
>>>>> However, more generally, there are currently some (known) limitations of
>>>>> Julia's type inference for anonymous functions. A do-block creates an
>>>>> anonymous function, so I would guess that is the underlying issue with
>>>>> the
>>>>> inferred types here.
>>>>>
>>>>> (By the way, have you seen the Cartesian macros in base?
>>>>> http://julia.readthedocs.org/en/release-0.3/devdocs/cartesian/)
>>>>>
>>>>> On Mon, Apr 13, 2015 at 7:46 PM, Todd Anderson <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Here's a small example:
>>>>>>
>>>>>> function nef(weights, input_B)
>>>>>> delta_B = cartesianarray(Float64, (input_B),) do j
>>>>>> sum(weights[spikes_A, j])
>>>>>> end
>>>>>> end
>>>>>>
>>>>>> ct = code_typed(nef, (Array{Float64,2}, Int64))
>>>>>>
>>>>>> println(ct)
>>>>>>
>>>>>> Here's the output:
>>>>>>
>>>>>> {:($(Expr(:lambda, {:weights,:input_B}, {{:#s2,:delta_B},{{:weights,
>>>>>> Array{Float64,2},1},{:input_B,Int64,0},{:#s2,Any,18},{:delta_B,Any,18}},{}},
>>>>>>
>>>>>> :(begin
>>>>>> #s2 = cartesianarray(AST(:($(Expr(:lambda, {:(j::Any)},
>>>>>> {{},{{:j,Any,0}},{{:weights,Array{Float64,2},1}}}, :(begin #
>>>>>> /mnt/home/taanders/pse-hpc/benchmarks2/nengo/ex2.jl, line 3:
>>>>>> return sum(getindex(weights,spikes_A,j))
>>>>>> end))))),Float64,input_B::Int64)
>>>>>> delta_B = #s2
>>>>>> return #s2
>>>>>> end))))}
>>>>>>
>>>>>> This shows the first lambda arg again as :(j::Any) of type :(::). In
>>>>>> my real code, it was at least figuring out in the second lambda arg to
>>>>>> type
>>>>>> "j" as {:j,Int64,0} but in this example it doesn't even figure out that
>>>>>> "j"
>>>>>> has to be of some Unsigned type and punts back to Any ({:j, Any, 0}).
>>>>>>
>>>>>
>>>>>
>>>
