4 ms·
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 besi
by 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.
- theodorethomas 5y agoLOC is not Fortran. C_LOC is. "pointer arithmetic" is not Fortran. The Fortran POINTER should not be confused with a C pointer (POINTER has more information). You cannot do arithmetic with a TYPE(C_PTR), either. LDB allows you to solve the 3rd and 5th RHSs only, when B is dimensioned (1000,100): call with NRHS=2, B=B(1,3) and LDB=2000 You can write a type-bound procedure call x = A%solve(b) with today's Fortran. LAPACK calls can be hidden from the casual user. I doubt that a casual user of C++ would enjoy looking at the implementation of its standard library, either. Yes, 29 year-old code written to a 43-year old standard looks old. How is that a Fortran issue? Would it look any newer if it was written in another 40-year old language? The fact that this code is still the mainstay of scientific computation is evidence of the strength of its design and the design of the programming language.
- BlackFly 5y agoFriend, you need to stop missing the forest for the trees.
- jabl 5y agoI meant that instead of passing the array as A or A(1,1) you can pass, say, A(6, 42), if you want to work on the submatrix starting at element (6,42).