Repository navigation
The matrix size of LAPACKE_sge_trans in lapacke_sgeqrt_work.c seems to be not correctย #766
Description
Activity
Thanks. I agree this is an issue, and your proposed change would fix it. Can you please submit a pull request for LAPACKE_sgeqrt? And also LAPACKE_cgeqrt, LAPACKE_dgeqrt, and LAPACKE_zgeqrt?
I want to follow up on this issue, the proposed fix corrects the segmentation fault and this is a good thing.
However there is something that I do not like in how this LAPACKE routine works. The process, right now, is (1) the user works in row major, () they give an array T for the T matrix, () column major LAPACK works in the lower parts of T, (*) in order to return in row major, we transpose the array T.
However, we could ask ourselves whether it is OK for LAPACK to write in the strictly lower parts of T. As of now, I am reading the headers of DGEQRT and there is no promise to leave the strictly lower parts of T unchanged. So what LAPACKE does not break the headers. But we can wonder whether we want to make the header of DGEQRT more strict and guarantee that LAPACK will not write in the strictly lower parts of T.
All in all, I think maybe, in LAPACKE, we should (step 1) transpose T before calling Column Major LAPACK, (step 2) call Column Major LAPACK, and (step 3) transpose T after.
This is the same as what is done to the array A.
My preference would be do add a
LAPACKE_sge_trans(LAPACK_COL_MAJOR, nb, MIN(m,n), t_t, ldt_t, t, ldt );
before calling
LAPACK_dgeqrt( &m, &n, &nb, a_t, &lda_t, t_t, &ldt_t, work, &info );
(And one after too as proposed by @sbite0138.)
Thank you for your response.
Can you please submit a pull request for LAPACKE_sgeqrt? And also LAPACKE_cgeqrt, LAPACKE_dgeqrt, and LAPACKE_zgeqrt?
My preference would be do add a
LAPACKE_sge_trans(LAPACK_COL_MAJOR, nb, MIN(m,n), t_t, ldt_t, t, ldt );
before callingLAPACK_dgeqrt( &m, &n, &nb, a_t, &lda_t, t_t, &ldt_t, work, &info );
(And one after too as proposed by @sbite0138.)I see. I agree with this method of implementation. I will create a PR using the method you suggested.
Sorry for the delay. I created a pull request.
While reading the code, I felt that the value ofldt_tneeded to be changed as well. Currentlyldt_tis defined as follows:
lapack/LAPACKE/src/lapacke_sgeqrt_work.c
Line 48 in 77fac7e
lapack_int ldt_t = MAX(1,ldt);
Here,ldtis the leading dimension oft, and sincetis a row major,ldtis the "horizontal" length.
On the other hand, sinceldt_tis the leading dimension oft_tandt_tis col major, this value should be a "vertical" length.I think the value of
ldt_tshould be as follows:lapack_int ldt_t = MAX(1,nb);
The pull request also reflects the above change, but if I have misunderstood, I would appreciate it if you could point this out to me.
Hi @sbite0138
I think we want to leave the line
lapack/LAPACKE/src/lapacke_sgeqrt_work.c
Line 48 in 77fac7e
lapack_int ldt_t = MAX(1,ldt); @scr2016: can you pitch in?
Julien.
Hi @langou
I am very sorry for the delay in replying.
I think we want to leave the line
OK, I have pushed back the changes regarding ldt_t.
If you don't mind, may I ask the reason why the change should not be made?If you don't mind, may I ask the reason why the change should not be made?
If T has a leading dimension, (meaning
ldtis strictly larger thannb) and you writelapack_int ldt_t = MAX(1,nb);
then the code will write in some part of the
ldt*narrayTthat you do not want it to write. It will work on thenb*nfirst entries ofT. (It's more complicated than that because we have a sequence of upper nb-by-nb triangle, but that's the idea.) What you want it to do is to work on[0 to nb-1], then[ldt to ldt+nb-1], then[2*ldt to 2*ldt+nb-1], etc. That's the samenb*nentries. But not in the same positions inldt*narrayT.This is only when
ldt>nb.Julien.
Thank you for your response. I apologize for the late reply.
then the code will write in some part of the
ldt*narrayTthat you do not want it to write. it will work on thenb*nfirst entries ofT.Just to confirm, does this mean that any write to
T_twill also affect the originalTarray?
From my understanding, sinceldt_tis used as the leading dimension forT_tandT_tis newly malloc'd (not a pointer toT), a write toT_tshould not impact the originalTarray. Therefore, it seems unnecessary to setldt_ttoMAX (1,ldt).Please let me know if there are any other considerations that I am missing.
Description
When LAPACKE_sgeqrt is executed with row major, the following code is executed to convert the result obtained with column major to row major.
lapack/LAPACKE/src/lapacke_sgeqrt_work.c
Lines 82 to 83 in 77fac7e
Here,
ldt * MIN(m,n)should be the number of elements int_t(= the number of elements int), but this expression takes more values whenldt > nbnb > n.This causes a segmentation fault when
LAPACKE_sgeqrtis executed with row major andldt > n.Here is an example that causes the problem:
Shouldn't this line look like this?
I'm thinking that other
LAPACKE_*geqrtfunctions may contain similar problems.Checklist