dot(a,b) fails for Array{Any}

[nicwib]

The function dot(a,b) fails for inputs of type Array{Any} even if the element types are, e.g., Float64. The reason seems to be that dot uses zero(type) which produces an error for the Any type.

Array{Any} can occur unexpectedly, since array comprehensions sometimes produce Array{Any} where one might expect a more narrow type such as Array{Float64}. The included code below shows exactly that situation.

The problem was encountered with 0.3.0-prerelease+2494. The problem did not occur on 0.3.0-prerelease+1713 and not on 0.2.0.

Here is a command sequence illustrating the problem:

Here is the code:
$ cat mycode.jl
a = [1.2, 3.4]
b = [a[i]+1 for i=1:length(a)]
c = dot(a,b)
@show a b c
@show typeof(a) typeof(b) typeof(c)

Trying with a recent 0.3.0 release:
$ julia --version
julia version 0.3.0-prerelease+2494
$ julia mycode.jl
ERROR: no method zero(Type{Any})
in dot at linalg/matmul.jl:47
in include_from_node1 at loading.jl:128
while loading /Users/epknwib/Documents/Julia/mycode.jl, in expression starting on line 3

Trying with 0.2.0:
$ /Applications/JuliaStudio.app/julia/bin/julia --version
julia version 0.2.0
$ /Applications/JuliaStudio.app/julia/bin/julia mycode.jl
a => [1.2,3.4]
b => {2.2,4.4}
c => 17.6
typeof(a) => Array{Float64,1}
typeof(b) => Array{Any,1}
typeof(c) => Float64

Trying with an older 0.3.0 prerelease:
$ /Applications/Julia-0.3.0-prerelease-0f55c2fae5.app/Contents/Resources/julia/bin/julia --version
julia version 0.3.0-prerelease+1713
$ /Applications/Julia-0.3.0-prerelease-0f55c2fae5.app/Contents/Resources/julia/bin/julia mycode.jl
a => [1.2,3.4]
b => {2.2,4.4}
c => 17.6
typeof(a) => Array{Float64,1}
typeof(b) => Array{Any,1}
typeof(c) => Float64

Niclas

[ivarne]

This is probably a consequence of #6183.

Maybe we should define zero(), one() and so on, using the promotion system, instead of just using the type for the container?

see definition for zero(::AbstractArray{T,N}) in: https://github.com/JuliaLang/julia/blob/master/base/abstractarray.jl#L241

[andreasnoack]

The old behaviour worked when the elements were integers (because it used to be that one(Any)=1), but for an Any array there is no reason to believe that the elements are integers. The old behaviour could also hide type inference problem and to some extend it can therefore be helpful to get the error. Right now, I think the best solution is to define the vectors with a concrete type if possible and if not, then with e.g. Real.

@ivarne Can you elaborate on what you mean by "...using the promotion system..."? I am not sure what you suggest.

[ivarne]

I was thinking about something like an efficient version of

zero{T}(x::AbstractArray{T}) = fill!(similar(x), zero(promote(x...)[1]))

Not sure if it is a good idea.

[JeffBezanson]

A good solution is to call zero only if the container is empty. Then you get an error for dot({},{}).

[nicwib]

@JeffBezanson Wouldn't it be better to define the dot product of two zero-length vectors as zero? At least that would be straightforward for arrays with known numeric types.

[JeffBezanson]

Yes, that approach will work for arrays with known numeric types. You could return zero for an Any array too, but you have to pick a type of zero arbitrarily.