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}).
>>>>>
>>>>
>>>>
>>
