Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Style guide for creating arrays #32618

Closed
tianrluo opened this issue Jul 18, 2019 · 8 comments
Closed

Style guide for creating arrays #32618

tianrluo opened this issue Jul 18, 2019 · 8 comments

Comments

@tianrluo
Copy link

tianrluo commented Jul 18, 2019

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.)

@tianrluo tianrluo changed the title Style guide for creating array Style guide for creating arrays Jul 18, 2019
@tpapp
Copy link
Contributor

tpapp commented Jul 18, 2019

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.

@tianrluo
Copy link
Author

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.

@tpapp
Copy link
Contributor

tpapp commented Jul 18, 2019

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.

@JeffBezanson
Copy link
Member

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].

@tianrluo
Copy link
Author

tianrluo commented Jul 18, 2019

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)

@StefanKarpinski
Copy link
Member

StefanKarpinski commented Jul 18, 2019

  • [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.

@JeffBezanson
Copy link
Member

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.

@ViralBShah
Copy link
Member

Is there anything we are going to do here? Can we close this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants