inconsistent zero-dimensional array operations

[abraunst]

Zero dimensional arrays get converted to scalar on some operations. Is this intended behavior? If yes, it seems undocumented* (and no so consistent IMHO)...

[*] I've found some discussion about zero-dim arrays in faq.md, but no reference to this.

julia> x=ones()
0-dimensional Array{Float64,0}:
1.0

julia> x .= 1
0-dimensional Array{Float64,0}:
1.0

julia> x .*= 1
0-dimensional Array{Float64,0}:
1.0

julia> x .* 1
1.0

julia> 1x
1.0

julia> 1*x
1.0

julia> x+x
2.0                                                                                                                                                                                                                                                                               

[tomaklutfu]

I think there is consistent behaviour because rhs always treats 0-dim as scalar. The difference is the first 2 are broadcast! returning 0-dim x, while the others return just the operation results whether the function broadcast or +. * treating x scalar.

[abraunst]

I think there is consistent behaviour because rhs always treats 0-dim as scalar. The difference is the first 2 are broadcast! returning 0-dim x, while the others return just the operation results whether the function broadcast or +. * treating x scalar.

I mean inconsistency wrt arrays of higher dimension. I was expecting to need to explicitly use x[] to convert to scalar.

[mbauman]

Yeah, this was an intentional design choice specifically for broadcasting, arising from the fact that ndims(1) == 0 and we wanted 1 .+ 1 == 2. It's definitely the kind of thing that I generally dislike, but I made an exception in this case. I still do wonder how much we would have seen complaints if 1 .+ 1 == fill(2).

See also #28866.

[abraunst]

Thanks for the explanations. I'll close this.

[pablosanjose]

As commented by Andreas Peter on Slack, this makes the following behavior inconsistent

julia> conj(reshape([1]))
0-dimensional Array{Int64,0}:
1

julia> conj(reshape([1 + 1im]))
1 - 1im

The first does not trigger the broadcast machinery due to a conj(x::Array{<:Real}) = x fastpath.

I think we should keep this open.

[mbauman]

The disconnect there is slated to be fixed in #32122. The bigger broadcast design issue is now being discussed in #28866.