3 ms·

<as long as they are required to preface every module and program with `implicit none`> A small price to pay for being able to run code from 60 years ago. And

<as long as they are required to preface every module and program with `implicit none`> A small price to pay for being able to run code from 60 years ago. And no, there is no such requirement as such. <need to specify the "leading dimension of A"> A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. Nothing to do with dynamic memory allocation and you know the compiler will have no excuse to copy data. Why is it a defect that I/O needs keyword? Fortran has doubled-down on that "defect" by making coarray references through syntax [] and not an MPI-like procedure call. I don't think it's a defect at all, it's a strength.

BlackFly 5y ago
I really don't understand why you're arguing with my explanation. I'm not attacking fortran, I'm explaining why it will feel old to people: because it has things in it that people moved on from. Heck, I'd even agree that it is a sort of bad attitude to automatically discount something because of such legacy. But there are clear historical artifacts in the language (like most languages today). > A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. This isn't why you specify the leading dimension, it is just a useful feature of the leftover artifact of the lack of dynamic allocation. If the algorithms were written today, the array slicing notation would simply be used to achieve that. Back in Fortran 66 days, you would compile a large 2d array to solve the biggest problem you wanted to solve because you couldn't dynamically allocate. The alternative would be to change the source code and compile, but that was untenable. Then you would set your array elements with ordinary matrix notation but you would need to specify the stride to the solver to work with that: thus yes, it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Alternatively they could have required people to work with 1d arrays and manually handle the matrix indexing, but that would have been unfriendly.
- jabl 5y ago
  > it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Nope, you can solve any submatrix by passing the address of some other element than the upper left corner as the address of the array.
  - BlackFly 5y ago
    Except that LOC doesn't take an offset and pointer arithmetic in fortran isn't guranteed to be safe. No practitioner that I ever worked with ever used them besides. I mean you could have simply argued that malloc existed. Anyways, from the original guide of fortran (maybe I am mischaracterizing their rationale, but from the horse's mouth): > However an assumed-size array declaration has been used in the software, in order to overcome some limitations in the Fortran 77 standard. [LAPACK Users' Guide Third Edition] It doesn't matter what the real reason is. The interface to matrix solving algorithms is archaic feeling: DGTTRF( N, DL, D, DU, DU2, IPIV, INFO ) DGTTRS( TRANS, N, NRHS, DL, D, DU, DU2, IPIV, B, LDB, INFO ) Yes, I understand the purpose of every argument, I even understand the weird naming convention. Everything about this feels old and a newer language (such as a newer fortran) could just give you x, _ = A.solve(b) Or something similar and still manage to capture the dynamic sizing, the efficient tridiagaonal storage, sub-block structure if needed, and error information via info; you can trivially make a signature that does it in place if you don't want a silently copying version. There's that LDB, and it certainly has nothing to do with a sub-block of the matrix since it has to do with the storage of the right hand side and enabling a single call to provide multiple solutions while assuming a particular array layout. Anyways, nobody is really engaging with the real point: that it is obvious with use that Fortran is an old language because there are all kinds of these historical artifacts laying around. As I said, everyone knows it, everyone who interacts with it will feel it. But by now fortran isn't alone in this camp. Moreoever, so what? You should be able to admit to yourself that Fortran is an old language (that is simply a fact), that it gives the impression to most people of being an old language (that is again, simply a fact and why shouldn't it?), yet it has many modern features and people can be quite productive in it for some problem domains. Adding modern features isn't going to win people over that are prejudiced against Fortran.

BlackFly 5y ago

I really don't understand why you're arguing with my explanation. I'm not attacking fortran, I'm explaining why it will feel old to people: because it has things in it that people moved on from. Heck, I'd even agree that it is a sort of bad attitude to automatically discount something because of such legacy. But there are clear historical artifacts in the language (like most languages today). > A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. This isn't why you specify the leading dimension, it is just a useful feature of the leftover artifact of the lack of dynamic allocation. If the algorithms were written today, the array slicing notation would simply be used to achieve that. Back in Fortran 66 days, you would compile a large 2d array to solve the biggest problem you wanted to solve because you couldn't dynamically allocate. The alternative would be to change the source code and compile, but that was untenable. Then you would set your array elements with ordinary matrix notation but you would need to specify the stride to the solver to work with that: thus yes, it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Alternatively they could have required people to work with 1d arrays and manually handle the matrix indexing, but that would have been unfriendly.

jabl 5y ago
> it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Nope, you can solve any submatrix by passing the address of some other element than the upper left corner as the address of the array.
- BlackFly 5y ago
  Except that LOC doesn't take an offset and pointer arithmetic in fortran isn't guranteed to be safe. No practitioner that I ever worked with ever used them besides. I mean you could have simply argued that malloc existed. Anyways, from the original guide of fortran (maybe I am mischaracterizing their rationale, but from the horse's mouth): > However an assumed-size array declaration has been used in the software, in order to overcome some limitations in the Fortran 77 standard. [LAPACK Users' Guide Third Edition] It doesn't matter what the real reason is. The interface to matrix solving algorithms is archaic feeling: DGTTRF( N, DL, D, DU, DU2, IPIV, INFO ) DGTTRS( TRANS, N, NRHS, DL, D, DU, DU2, IPIV, B, LDB, INFO ) Yes, I understand the purpose of every argument, I even understand the weird naming convention. Everything about this feels old and a newer language (such as a newer fortran) could just give you x, _ = A.solve(b) Or something similar and still manage to capture the dynamic sizing, the efficient tridiagaonal storage, sub-block structure if needed, and error information via info; you can trivially make a signature that does it in place if you don't want a silently copying version. There's that LDB, and it certainly has nothing to do with a sub-block of the matrix since it has to do with the storage of the right hand side and enabling a single call to provide multiple solutions while assuming a particular array layout. Anyways, nobody is really engaging with the real point: that it is obvious with use that Fortran is an old language because there are all kinds of these historical artifacts laying around. As I said, everyone knows it, everyone who interacts with it will feel it. But by now fortran isn't alone in this camp. Moreoever, so what? You should be able to admit to yourself that Fortran is an old language (that is simply a fact), that it gives the impression to most people of being an old language (that is again, simply a fact and why shouldn't it?), yet it has many modern features and people can be quite productive in it for some problem domains. Adding modern features isn't going to win people over that are prejudiced against Fortran.