Related doc: Performance Tips · The Julia Language For a matrix julia> x = [1 2; 3 4] 2×2 Matrix{Int64}: 1 2 3 4 The correct order of element is julia> for e = x println(e) end 1 3 2 4 To exactly reproduce the above sequence in a double-index fashion, we have to write jul…

[x[r, c] for r=1:2, c=1:2]: r is the rows, c is the columns. It will give a multi-dimension array, where the index does not rely on each other/another/any other when the array is generating. Totally it is not the syntactic sugar of for loop.

@WalterMadelim the other thing to keep in mind is: the behaviour is what it is. We won’t be changing it because it would be breaking, both in JuMP and in Julia. Just learn to live with previous decisions :smile:

You’re suggesting that [x[r, c] for r=1:2, c=1:2] == x where == reads “recovers”. Okay I think this make sense at the beginning for everyone, as it is highly intuitive. The main concern is that It doesn’t co-exist well with julia’s column-major Arrays, which I pointed out in my #1 post.

I think the crux of this topic is that: for a julia Matrix A_{rc}, whose element is called by A[r, c], the c index is considered at a higher rank. In this expression for c=1:2, r=1:2, the c index is considered at a higher rank. The word “higher” is also perceived as being “outer”, “independent”, …

Identical issue has been discussed a number of times here. In particular, I recommend Why column major? , in which you can find a few useful explanations. Perhaps my take Why column major? - #36 by zdenek_hurak could be one of them.

Also relevant is this post. :wink: [image] PSA: Julia is not at that stage of development anymore Internals & Design You heard about this brand new exciting programming language called Julia and have some suggestions for how it should work. Wonderful! We’re hap…

I agree with @jules that this convention makes sense when you switch from prefix for to postfix for. For me it’s natural to consider [x[r, c] for r=1:2, c=1:2] to be equivalent to something like [(x[r, c] for r=1:2) for c=1:2] (though this is already valid syntax creating a Vector of generators)…

[image] eldee: julia> [x[r, c] for r=1:2 for c=1:2] # unexpected 4-element Vector{Int64}: 1 2 3 4 This is exactly where the current comprehension design is not consistent. To follow the current comprehension grammar, one needs to remember the “folklore” convention [image] jules: th…

By the way, this topic is essentially a duplicate of [image] `for i = 1:M, j = 1:N` discrepancy (loop vs comprehension/generator) Internals & Design I noticed the following about the for i = 1:M, j = 1:N syntax. When using this syntax as part of a normal for-l…

[image] eldee: is essentially a duplicate of The discussion there is of high quality. But I think my depiction of this issue in my #1 post here conveys a sharper contradiction. [image] eldee: okatsn’s summary at the end. First of all, that post is quite lengthy and make use of if-else …

Array comprehension is inconsistent, given the column-major property of julia

Internals & Design

nalimilan January 8, 2026, 9:03am 8

Also relevant is this post.

Topic		Replies	Views
`for i = 1:M, j = 1:N` discrepancy (loop vs comprehension/generator) Internals & Design syntax , loops	26	4601	December 28, 2022
Why column major? General Usage question , array , linearalgebra , column-major	58	21118	February 17, 2024
Nested loop confusion General Usage loops	3	600	December 1, 2022
Comprehensions and vectorization New to Julia	13	5217	September 20, 2017
Documentation for comprehensions with if and/or w/o comma General Usage question	3	656	April 17, 2019

Array comprehension is inconsistent, given the column-major property of julia

Related topics