Below is an example on the potentially problematic way of creating arrays. It can be confusing and accidentally lead to bugs:
julia> a, b, c = 1, 2, ones(1,3)
(1, 2, [1.0 1.0 1.0])
julia> [0 1 (a-b)] # Good style
1×3 Array{Int64,2}:
0 1 -1
julia> [0 1 a - b] # Bad style
1×3 Array{Int64,2}:
0 1 -1
julia> [0 1 a -b]
1×4 Array{Int64,2}:
0 1 1 -2
It may not be obvious in the above code block.
For elaboration, instead of a - b
, imagine you want to insert some computations into the creation of an array, so that your code stays concise.
julia> [c[:,1:end-1] (a^2+b^2)/2 - (a*b)] # Bad style
1×3 Array{Float64,2}:
1.0 1.0 0.5
Now accidentally missing the second space causes unexpected behavior:
julia> [c[:,1:end-1] (a^2+b^2)/2 -(a*b)] # Oops
1×4 Array{Float64,2}:
1.0 1.0 2.5 -2.0
It can be uneasy for debugging, suppose the length of c
is unknown at runtime. So, no clear expectation of how long the composed array should be.
(Matlab also has this confusion problem. Python does not as it rejects space as element splitter in the first place.)
Personally, I think of both
[0 1 a-b]
# and
[0 1 a - b]
are bad style, and prefer
[0 1 (a - b)]
Cf discussion in #7128.
Personally, I think of both
[0 1 a-b] # and [0 1 a - b]
are bad style, and prefer
[0 1 (a - b)]
Cf discussion in #7128.
Agreed, main text edited.
Just to clarify: the above is my personal preference on this, not something directly implied by either the linked discussion or the existing style guide. I linked #7128 because it discusses the unfortunate consequences of whitespace being significant in the surface syntax for hvcat
.
I am not sure that the style guide is the best place to fix this. Generally, I think that one should avoid cases where the programmer would have to think about what the parser would do, or clarify with ()
s. This is a special case of that.
Disallowing one of these forms, eg the one with whitespace between terms (eg [0 1 a - b]
) is an option, but it would be breaking.
Longer term we might want to disallow asymmetric spacing around infix operators (1 +2
as infix, outside an array expression). I think that's a bigger problem than allowing [a - b]
or [a -b]
.
Just out of curiosity, why did Julia choose to put both ,
and ;
as row-wise splitter, and leave '' as column-wise splitter?
(Was thinking if ,
remained as column-wise splitter, like matlab, then maybe the community just need to abandon '' as a splitter in the future to avoid confusion)
[a, b]
creates a vector containing the values a
and b
regardless of what they are.[a b]
does horizontal concatenation of a
with b
treating them as collections.[a; b]
does vertical concatenation of a
with b
treating them as collections.One concern was that [a, b]
should create a 1-d vector, since that's the most natural syntax for "CS-style" arrays (as opposed to "linear algebra-style"). A programmer writing [a, b]
would be surprised if it gave some weird row matrix thing.
Is there anything we are going to do here? Can we close this issue?
Most helpful comment
[a, b]
creates a vector containing the valuesa
andb
regardless of what they are.[a b]
does horizontal concatenation ofa
withb
treating them as collections.[a; b]
does vertical concatenation ofa
withb
treating them as collections.