3 ms·

As I said, it is a historical argument to argue why something was designed in a particular way. You do not seem at all interested in attempting a historical arg

As I said, it is a historical argument to argue why something was designed in a particular way. You do not seem at all interested in attempting a historical argument. You aren't going to convince me without offering something in the way of common uses of block matrices in numerical linear algebra in the early 70s or without technical notes describing the intent of the parameter to be used for general block submatrix purposes. Yes, what you are saying is correct about the technical capabilities of the parameter; I have agreed with you 3 times already, but it is irrelevant. You keep ignoring the actual point: an answer of what you can use the parameter for is not the same as an answer to why that parameter is there. You can be quite right about what the parameter allows you to do and quite wrong about why it was added in the first place. The origin of LDA as an argument traces all the way back to LINPACK. Just read chapter 1 of the LINPACK user's guide, https://doi.org/10.1137/1.9781611971811.ch1 https://doi.org/10.1137/1.9781611971811.ch1 and see them using the parameter as I describe. It is used precisely to over allocate an array in a program so that it can be dynamically sized at runtime. The allocate an array A of size 50 x 50, specify LDA to be 50, then assign N to some value and use 2d array notation to set a block of the array A to a matrix. My assertion is that is precisely the use case they designed that parameter to be used for. That usage is why algorithms with LDA are first class and there are no variants (and they offer many variants) without it: because they knew that people would compile programs with overallocated arrays and require it. LINPACK predates even fortran 77, tracing back into subroutines developed by Wilkinson this sort of use arises from fortran 66. I'm having a hard time finding technical notes describing those routines though. I'm curious if LDA shows up in the ALGOL 60 versions. In any case all this history was relayed to me by my supervisor who worked worked much closer to this history than me so I trust that quite implicitly. For you, maybe it was enough to see that the parameter was a stride and stop digging. For me, I saw that, saw it always being set equal to N (and M = N) in all actual uses in the modern code I was working with and I was curious why it wasn't abstracted away because even at Fortran 77 is was easy to hide it behind a zero cost abstraction. So I went down the historical rabbit hole. Maybe I should have just pointed out that the names of the subroutines are limited to 6 characters because of history and you would have agreed that use of LAPACK is a trigger for most people to realize that fortran is filled with historical artifacts.

theodorethomas 5y ago
http://www.lahey.com/nl00apr.htm#Fortran_and_the_Space_Program http://www.lahey.com/nl00apr.htm#Fortran_and_the_Space_Progr... 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.

theodorethomas 5y ago

http://www.lahey.com/nl00apr.htm#Fortran_and_the_Space_Program http://www.lahey.com/nl00apr.htm#Fortran_and_the_Space_Progr... 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.