Julia: error with using end as an index in an array of arrays

[johndrummond]

a = {[1,2,3],1,3,[1,2,3,4]}
println(a[4][3])
println(a[4][end -1])

gives
3
LoadError("N:/test/rawTrades/test2.jl",7,MethodError(Array{T,N},([1,2,3,4],1,2)))
i.e. using end to reference doesn't work.
also I'm not clear why a[1,1] doesn't work and I need to use a[1][1]

[milktrader]

a[1,1] works. It gives you the first element of your 1-dimensional Any array, which is [1,2,3] (a 3-element, one-dimensional Int Array)

Also, I get this in repl

julia> a[4][end-1]
3

tip: you don't need to wrap the array elements in println()

[ivarne]

I can confirm the bug (as described) on a 1 day old master.

[milktrader]

end -1 gives the error while end-1 gives the expected result.

[cbecker]

The problem is the space, as @milktrader says.
This is related to how Julia treats input, see https://github.com/JuliaLang/julia/issues/6405

[milktrader]

Precisely, and this is probably not a bug. The clue is in the description of the method error

julia> a[4][end -1]
ERROR: no method Array{T,N}(Array{Int64,1}, Int64, Int64)

end and -1 are treated as two Int64 while end-1 is treated as a single Int64.

This is more obvious by replacing end with 4

julia> a[4][4-1]
3

julia> a[4][4 -1]
ERROR: no method Array{T,N}(Array{Int64,1}, Int64, Int64)

[johndrummond]

@milktrader
thanks for spotting a workaround, or as cbecker and you point out it may not be a bug.
and interestingly a[1][end - 1]
with spaces round the minus sign does work.
Maybe there could be a flag to switch off magic handling of spaces, i'm happy to put in a comma
or special quoting of them as I'm for one clearly going to spend time hoping I've put them in correctly to find I haven't

Apologies if what I'm seeing is meant to happen.

a[1,1] works. It gives you the first element of your 1-dimensional Any array, which is 1,2,3
I suppose I had a mental model from Mathematica and Perl of everything being or addressable as lists or lists of lists etc.
Yes I'm often surprised by trying to index elements in data structures in R as well.

[StefanKarpinski]

This isn't "magic" handling of spaces – it's a different syntax with a different meaning. [1 2 3] is an input syntax for a row matrix.

[johndrummond]

a[4][(end -1)] # expression
a[4][end - 1] # expression
a[1][end-1] # expression
a[1][end -1] # row matrix syntax and error raised

I understand now this is what is supposed to happen and isn't a bug or magic handling of spaces.
Sorry for taking your time.
It wasn't and will continue to be non obvious for me to parse.

[StefanKarpinski]

No worries – I agree that it's annoyingly fiddly. This has arisen from trying to keep some compatibility with the way Matlab lets you express these things. The result is that the parsing rules can be a little subtle inside of brackets. You are by far not the only one who's been tripped up by this.

[tkelman]

Except that there only ends up being compatibility with the Matlab entry method that uses whitespace as the delimiter - not the entry method with an explicit delimiter, since Julia has an entirely different interpretation of commas. If you're like me and have gotten in the habit of using commas 100% of the time for horizontal concatenation in Matlab, Julia's choice of syntactic whitespace for horizontal concatenation feels like a bad decision.

[StefanKarpinski]

This was a really tough corner to be in since anyone coming from normal programming languages would expect [1,2,3] to be a vector, not a row matrix. They may not have such an expectation of [1 2 3].

[tkelman]

The different interpretation of commas makes sense, especially with Julia having true 1-d vectors unlike Matlab. But it makes semicolons almost redundant as delimiters, at least in the case where you're only using one or the other - [1,2,3] and [1;2;3] are the same, yes? Switching the meaning of semicolon so it is horizontal concatenation and comma is vertical could prevent the whitespace sensitivity, but would be even more confusing to Matlab users. It's too bad there aren't more easily-usable, clean-looking, baggage-free punctuation characters available...

[cmundi]

Would it be heresy to ask whether (a degree of) compatibility with Matlab should drive Julia syntax?

[StefanKarpinski]

No, that's not heretical at all. It seemed more important when we were starting out. Less so now.

[nalimilan]

In the present case Matlab compatibility comes at quite a high price indeed. It's not common for spaces around math operators to make such a difference.

[JeffBezanson]

In the case of block matrix syntax, I think distinguishing [x -y] and [x - y] is reasonable. The syntax A[x y] is more suspect and I lean towards changing/removing it. It might also be good to give a syntax error for writing function calls as f (x) and indexing as a [i].

[cmundi]

+1 for keeping [x -y] distinct from [x - y] just because unary minus needs to have higher precedence than the whitespace "operator" which in the vector context means "append to list what follows"

Although I happen to think that f (x) and a [i] are ugly, I know many people like that style. See my next comment.

I confess I have mixed feelings about A[x y] which I cannot articulate. If the truth be told, I don't like syntactic whitespace at all -- no matter how useful python is. Any objection to "curly brace noise" is totally trumped in production by the virtue of clarity that comes with explicit delimiters. Again, I respect opposing opinions. It's just that when I'm crunching data I don't care about winning a beauty contest. I want syntax (and semantics!) which don't depend on me counting spaces. At least with Julia the only question is space(s)-or-no-space and not counting. :)

[tonyhffong]

Lint.jl now warns on a[end -1]