Why column major?

Exactly. Linear algebra and text chose different conventions, and we’re paying the price for that. Either we change how linear algebra notation works or we start reading column-major like Traditional Chinese (except with columns left to right). I didn’t know images were row-major, but I guess it makes sense if they needed to be used as input for dot-matrix printers.

Simple, create a package called “Row Major Linear Algebra”. Problem solved.

When you read a book, you read a word, then the next line, then the next page, then the next book.

With your scheme there is also no fixed meaning to the dimensions. If you start with a book, you find the specific word along the third dimension. If you start with a library, it’s the fourth (or maybe you count sections, so fifth?). If it’s a multiverse, it’s, I dunno.

There’s no fixed point when you start from the outside going in, the dimensions are just endlessly pushed outwards in a mindwarping way. Instead, start on the inside, and build out. Later dimensions are further out, referring to larger entities.

1 Like

Just to be clear: what I’m dreaming of is ‘first index major’, but the first index moves along the rows.

I actually meant to reply to yha but I mis-clicked your reply button. We’re on the same page here, I totally agree with everything you’ve said. I can’t change who I reply things to, but I can edit my previous comment to emphasize that I agree with you. Sorry, what a mess.

1 Like

Interesting. I see your point now, though this never bothered me at all when using MSB-first indexing in numpy. Possibly because I tend to think in abstract terms of “k-th dimension” rather than rows/columns whenever the arrays are more than 2d.
(but if I were dictator of Julia, I’d still choose to copy numpy rather than MATLAB on this issue)

No problem at all😄

I guess there’s no way to be truly consistent, sometimes it makes sense to start on the inside and build outwards, sometimes you drill down. But I really have a problem with ‘fastest index moves outwards’. I like ‘first index is fastest, period.’

Is there a package for “first index fastest”?

but in a simple table like this:

John      54kg    1.80m
Paul      80kg    1.70m
Denis     70kg    1.60m

isn’t it natural that running over columns (to compute average properties, for instance) should be the fastest?


What is “natural” in these discussions may be very application-dependent. Some applications benefit from either choice, or possible hybrids (eg block storage).

The Julian answer to “row or column major” is that

  1. yes, the language provides a default for Array,

  2. but the important thing is that there is an abstract interface for most operations (indexing, iteration, etc) so that users are free to define their own container types that does what they please.

(Also, a quick & dirty row major array is just a PermutedDimsArray away).


Regarding your example:

Its transpose is as simple or natural:

        John    Paul    Denis
Weight  54kg    80kg    70kg
Height  1.80m   1.70m   1.60m

Think about the weight and height of a population and put that in that table (or the grades of an exam). The point is that the number of values is much greater than the number of categories.

But of course this is case dependent an application dependent. My note was only because sometimes seeing one example where the option makes sense helps us remember why it is as it is (even if it could be otherwise because of other cases).

Sure, I was thinking of plain numeric arrays, tables would be different.

1 Like