Matrix literals

[FortranFan]

As proposed by a reader at comp.lang.fortran: https://groups.google.com/d/msg/comp.lang.fortran/m6qz7hC4a7M/78maOb9uEgAJ
(see the thread for further comments and discussion)

Adding matrix literals
This is mostly a quality of life thing, but something like

INTEGER, DIMENSION(2, 2) :: A = [1, 2; 3, 4]

representing the matrix
/ 1 2 \
\ 3 4 /

is, to me, a lot more readable than

INTEGER, DIMENSION(2, 2) :: A = TRANSPOSE(RESHAPE([1, 2, 3, 4], [2, 2]))

This could even be extended to more complex arrays by, for instance, repeating
semicolons, eg.

INTEGER, DIMENSION(2, 2, 2) :: B = [1, 2; 3, 4;; 5, 6; 7, 8]

One issue with this syntax is of course that the values are given row major,
which is different from the memory layout of Fortran an thus also the way
RESHAPE works.

Alternatively [1, 2; 3, 4] could represent
/ 1 3 \
\ 2 4 /

[certik]

Yes! I've been wishing something like this for years.

[jacobwilliams]

Agreed. The reshape thing is not ideal. I wish there was some way to declare a matrix that didn't require you to know that the compiler was using column major order. That always seemed to me a low-level detail that a user shouldn't have to know about.

[LKedward]

Agreed. The reshape thing is not ideal. I wish there was some way to declare a matrix that didn't require you to know that the compiler was using column major order. That always seemed to me a low-level detail that a user shouldn't have to know about.

Not sure about this.
I wouldn't use a language if I couldn't be sure about the storage layout of higher dimension arrays.
It's absolutely necessary to know storage layout a priori in order to ensure memory access is contiguous and therefore efficient.
Performance difference between strided access and contiguous access is very significant.

Otherwise I agree with the usefulness of matrix literals.

[jacobwilliams]

Sure, for performance you need to know that. But for showing a beginner how to declare a 3x3 matrix parameter it's not really that great.

[certik]

Indeed. You need to know the memory layout to write performant code, but it should not be necessary to know the layout just to write correct code (even if slow).

…

On Thu, Nov 28, 2019, at 8:57 AM, Jacob Williams wrote: Sure, for performance you need to know that. But for showing a beginner how to declare a 3x3 matrix parameter it's not really that great. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#102?email_source=notifications&email_token=AAAFAWGUE4ITA6HAVQQQ4VLQV7S7ZA5CNFSM4JSOR54KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFM7NNA#issuecomment-559543988>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWBGWAJ7YPPOS3JGPDLQV7S7ZANCNFSM4JSOR54A>.

[LKedward]

Sure, for performance you need to know that. But for showing a beginner how to declare a 3x3 matrix parameter it's not really that great.

Agreed, I'd interpreted your sentiment as a more general desire to completely abstract away storage order to compiler implementation.

[gronki]

I understand that matrix literals are for defining small matrices anyway. I agree that better syntax is needed. czw., 28 lis 2019, 17:14 użytkownik LKedward <notifications@github.com> napisał:

…

Sure, for performance you need to know that. But for showing a beginner how to declare a 3x3 matrix parameter it's not really that great. Agreed, I'd interpreted your sentiment as a more general desire to completely abstract away storage order to compiler implementation. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#102?email_source=notifications&email_token=AC4NA3MT33YGMME4BXXBX63QV7U6JA5CNFSM4JSOR54KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFNAVJY#issuecomment-559549095>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4NA3PLH3FJE5AIC7H7K3DQV7U6JANCNFSM4JSOR54A> .

[LKedward]

I wish there was some way to declare a matrix that didn't require you to know that the compiler was using column major order.

But for showing a beginner how to declare a 3x3 matrix parameter it's not really that great.

With these things being said, and returning to the last point in the original post, there is an argument for using row-major in the literal syntax in that it is the same as MATLAB and therefore will be familiar to beginners coming from MATLAB.
Indeed, I understand that MATLAB uses row-major syntax despite being column major storage.

[LKedward]

MATLAB also accepts commas as column delimiters instead of spaces and this is generally recommended for readability.

i.e. The following are equivalent in MATLAB

a = [1 2 3; 4 5 6; 7 8 9];

a = [1, 2, 3; 4, 5, 6; 7, 8, 9];

It is the same comma/semicolon syntax as suggested in the original post.

An alternative syntax not using the semicolon could be nested array literals:

integer :: a(3,3)
a = [[1,2,3],[4,5,6],[7,8,9]]

but this again raises the row-major/column-major syntax question.

[jacobwilliams]

I certainly think that the limitations of fixed-form source should not enter the deliberations. It's long past time for that to be eliminated (#108).

[rweed]

After spending several days recently typing in data to create equation of state tables, I can say from experience that anything like the MATLAB way of defining multi-dimensional arrays would be a big improvement over RESHAPE. I've never understood why you need RESHAPE if you are entering data in column major order in the first place.

[sblionel]

I could certainly see relaxing the shape matching rules if the right side was a rank-1 array with the same SIZE as the left. I do wonder how these proposals would extend to rank 3 and greater arrays.