C, as an operating system implementation language, is trying to do something fundamentally different than Fortran.
You live by memory address, you die by memory address.
77 karma · joined August 9, 2021
C, as an operating system implementation language, is trying to do something fundamentally different than Fortran.
You live by memory address, you die by memory address.
A Fortran program that reads its input, calculates and finally writes out its output does not have to execute any particular instruction at all. As long as the answer is "AS IF" it had done the user-specified computation, the Fortran compiler has done its job. In between I/O, it submerges into the ineffable like a Cold War SSBN.
C is about the instruments, the players and the conductor, Fortran is about the music.
As far as I know, two sectors claim they need it: finance and climate.
"Do you want a better answer?"
"No, I want the same wrong answer that I got last Tuesday."
Science/Mathematics can't fix this.
"The result of NORM2 (X) has a value equal to a processor-dependent approximation to the generalized L2 norm of X, which is the square root of the sum of the squares of the elements of X. If X has size zero, the result has the value zero."
Can someone please tell the clang compiler folks?
describes use of Fortran dummy arrays before Fortran IV. No LDA/B/C in the example provided. But I find it hard to believe that once a compiler existed that would compile that example, people took more than a week to realize that by adding LDA/B/C you can write a general DGEMM that can multiply submatrices.
We need to remember that first there was a compiler implementation and the language was secondary to that. Language extensions that the compiler could do "easily" get implemented quickly. Sequence association was one of those things and I still maintain that it would be needed (in the absence of array expressions) even if there was dynamic allocation in Fortran I.
Consider a subroutine that is expected to take the 1st column and the last column of an array, sum them, and put the result in the 1st column. You want to write
allocate(a(3,5),source=b); call sub(a) deallocate(a) allocate(a(2,4),source=c); call sub(a)
Can you reuse sub to only sum the bottom half of the columns? Not without allocating a new array and copying before passing the copy to sub. With sequence association, LDA and adjustable or assumed-size arrays and extra integer arguments, you can and it will work for any rank.
The alternative coding that I have seen (and abhor), is putting an LDA in a COMMON and then all your subroutines pick up an LDA from there. Such codes are usually riddled with errors.
"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.
To summarise: F77 has no array expressions so the only way to pass a subobject of an array is through sequence association, as described.
If it had dynamic allocation and no array expressions, sequence association would still be needed. In fact, most F77 compilers supported dynamic allocation as a non-standard extension and STILL used sequence association to pass subobjects of arrays.
Whether you pass a whole array or use sequence association, the meaning of LDA is clear: it determines how sequence association will work between rank-2 dummy and actual array. And, yes, you can use different LDAs (as long as you don't step over the bounds) to effectively walk the diagonal or skip columns.
It was “array slicing” (array expressions) that was missing in F77. That’s what sequence association was meant to help with. You pass a scalar that is an element of an array and the corresponding dummy is an array. The dummy gets associated with an array that starts at that element and then continues with all the other elements of the actual argument array in array element order. You then use the LDA argument to give a 2d view of the same array in the dummy so you can step to the next column (or every other column if you want, just double the LDA) no matter where you started from.
Programs back then had no need for dynamic memory, they were the only thing running on the machine, no kernel, no other processes or users, why not just grab the entire memory? They booted in a blink of an eye, too. Now, not even our supercomputers run like that. You never know who else is using the resources of the machine.
! MARK 1 RELEASE. NAG COPYRIGHT 1971.
It has been revised since then to use free form, structured programming, MODULEs, KINDs, INTENTs and IMPLICIT NONE.
If we can do it, everybody can. I have already mentioned some reasons that people don't do it. None of the reasons I have heard are "Fortran is too old and clunky".
-But we can build with concrete and steel and plastics and all sorts now.
-Most people use bricks though. And people are not tearing their brick houses down to rebuild them in steel. See? Building is old fashioned, antiquated!
In fact, nobody now starts a new project in F77. There’s a lot of F77 brick code around, yes. And it still does the job it was asked to do even though it gets moved to a new district every ten years.
People don’t modernize their codes because the Fortran compilers allow them to, and the Standard is reluctant to delete old features (and compilers would not delete them anyway).
Unfortunately, that means that old bugs can lie undetected. I don’t think any other language/compilers have squared that circle.
And there’s plenty of new projects started in Fortran.
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.