Error message in array indexing

Hi!

I’m on Julia 1.5.3

The last expression is the result of a typing error that I made. The previous expression is something I was aiming to type. Probably this is something that I should know but here goes. In REPL ;

julia> k = [1, 2, 3]
3-element Array{Int64,1}:
 1
 2
 3

julia> m = 1
1

julia> n = 2
2

julia> k[m + n]
3

julia> k[m +n]
ERROR: MethodError: no method matching typed_hcat(::Array{Int64,1}, ::Int64, ::Int64)
Closest candidates are:
  typed_hcat(::Type{T}, ::Number...) where T at abstractarray.jl:1365
  typed_hcat(::Type{T}, ::Union{Number, LinearAlgebra.Adjoint{T,var"#s828"} where var"#s828"<:(AbstractArray{T,1} where T) where T}...) where T at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\LinearAlgebra\src\adjtrans.jl:236
  typed_hcat(::Type{T}, ::Union{Number, LinearAlgebra.Transpose{T,var"#s828"} where var"#s828"<:(AbstractArray{T,1} where T) where T}...) where T at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\LinearAlgebra\src\adjtrans.jl:237
  ...
Stacktrace:
 [1] top-level scope at REPL[25]:1

I’m sorry if I have bothered you for nothing but I really would like to know what’s going on.

Jussi Salmela

1 Like

This is one of the handful of places where whitespace matters. In short, it’s the same as the difference between [1 + 2] and [1 +2]:

julia> [1 + 2]
1-element Array{Int64,1}:
 3

julia> [1 +2]
1×2 Array{Int64,2}:
 1  2

In the latter case, the + becomes a unary operator and you get a horizontal concatenation (that’s why hcat is showing up in the error).

8 Likes

Thanks for your answer. I understand what is happening but I can’t find this in the documentation. Has this feature a name I could search for? And, being a noob, I can’t understand what is the use case for this i.e. what is the rationale of this feature. I’m asking this because with the values m==1 & n==2 these
[m n]
[m +n]
produce the same result. So I’m wondering if there are more complicated situations where this feature is essential or makes coding essentially easier.

Probably the implementation of that is essentially easier. In that context spaces are used to indicate a row-major array instead of a column vector which you would get with commas. Of course [ 1 -2 ] should parse to

julia> [ 1 -2 ]
1×2 Array{Int64,2}:
 1  -2

Thus, for [ 1 +2 ] to be parsed otherwise there should be a specific implementation for that case. And things could get strange. For example, to what [ 1 +2 -5 ] should be parsed to?

Yeah, it’s the same as [1 -2] or [3 :end]. It’s not really about the ease of implementation, it’s just an unfortunate ambiguity that comes with the combination of:

  • space-delimiting elements in a horizontal concatenation
  • allowing optional spaces around infix operators like + and - and :
  • parsing expressions like 1 + 2 and 3 - 4 to be a single element
  • supporting + and - as both infix and unary operators
  • unary operators take precedence over infix ones

Change any one of those things and the behavior here would change.

As far as why + is a unary operator in the first place, I can see two reasons:

  • Symmetry with -. This is why C introduced it. Besides just following that tradition, it can be handy for some interop; some programs always output numbers with an explicit prefixed + or -.
  • While it is a no-op for all builtin types, it could be extended to do something different. Not sure what, and it doesn’t seem like the ecosystem has done that in my quick scan.
3 Likes

Thanks to both for answering although this is a very minor detail in the Julia environment. The incidence was caused by my mistyping of leaving the space out after the plus sign. Now I’m familiar with this so I don’t have to ask again in case I do it again which is quite probable.

1 Like