dgemm subroutine in BLAS - I think I've cracked the difference, please confirm
From: Dawn Minnis (dawn.minnis_at_btinternet.com)
Date: Sat, 12 Feb 2005 09:43:33 -0000
Oh do you know I may have just got a blow to the head there. By any chance
does LDA,B,C define the size of one dimension of the BIG BIG BIG outer
matrix and m,n,k define the dimensions of the actual matrix to be worked
upon. And going on that, LDA, B, C explain what the jump is between one
element in row eg 3 and the next element (ie in the next col)?
Ok, if thats right then I get it. I was actually working on it the wrong
way round thinking that m,n,k defined the outer matrix and LDA,B,C defined
the inner size.
So I build a matrix first of all, being of size A=(LDA, k) B=(LDB, n) and
C=(LDC, n) and then only work with the submatrix A=(m, k) B=(k, n) and C=(m,
ok, (as you can see I'm talking this out as I understand it so even I can
see what I'm talking about), so in the current state of memory allocation,
given that there is a function malloc() which I am using to allocate the
required memory for A,B and C, is there acually any need to define LDA,B,C
anymore? I mean, if you are wanting to perform multiplication of matrix A*B
then why bother defining a larger matrix to begin with that takes up
Btw, thanks for the humour throughout this thread, I've been at the point of
tearing my hair out for ages now and this really helps.
"glen herrmannsfeldt" <email@example.com> wrote in message
> Dawn Minnis wrote:
>> Believe it or not I'm beginning to get the hang of this. That
>> explanation was way easier to comprehend after the extra (dumbed down)
>> So, looking at my other posting (further down this thread) can you maybe
>> give me an example where LDA, LDB and LDC are NOT equal to m,n,k and show
>> me what how that would work.
>> I know I'm a pain, but I'm just a silly little girlie at the end of it
>> all. I have enough brains to comprehend most of what you all just told
>> me, but I have a problem when it comes to applying the dimensions.
> In the Fortran 66 days it was because dynamic allocation didn't exist, so
> you allocate arrays big enough for the largest problem you might run into.
> Say, though, that you want to read the array in. You could do something
> DOUBLE PRECISION A(100,101), B(101,100), C(102,100)
> READ(*,*) m, k, n, ((a(i,j),i=1,m),j=1,k),
> X ((b(i,j),i=1,k),j=1,n), ALPHA
> CALL DGEMM ( 'N', 'N', M, N, K, ALPHA, A, LDA, B,
> X LDB, 0.D0, C, LDC )
> C note the subscript order in the next statement!
> WRITE(*,*) ((c(i,j),j=1,n),i=1,m)
> That will read in m, k, n and the two arrays a and b, and alpha, process
> them accordingly and print the result, for m and n less than or equal to
> 100, and k less than or equal to 101.
> Since the arrays are allocated before reading, it is unlikely that LDA,
> LDB, equal m, k, and with LDC=102, extremely unlikely
> that LDC will equal m. (The first subscript of C goes with m.)
> The arrays are read in the order they are stored in memory,
> but printed in the subscript reversed order, either of which could be
> changed by changing the implied DOs.
> Note that in this program m, k, n are read in the same statement where the
> arrays are read, which would make dynamic allocation difficult to do.
> -- glen