You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LAPACKE_?larfb_work passes work and ldwork to the Fortran routine unmodified even if the matrix layout is row major. This is extremely surprising bordering a bug because it means that the work matrix has to be column major while all the other matrices are treated as row major. Interestingly, LAPACKE_?larfb follows the game and the work matrix it allocates (due to ldwork it uses) is column major.
I might be wrong but the only reasonable solution I see is not to allocate work in LAPACKE_?larfb and allocate it in LAPACKE_?larfb_work instead while ignoring work and ldwork parameters passed to it.
It seems that LAPACKE_?tprfb_work and LAPACKE_?trsna_work suffer from the same problem.
The text was updated successfully, but these errors were encountered:
Recently I've been thinking about this issue again and even after this long time I'm still unsure whether lapacke should allocate a new work matrix or not. I lean towards yes. For example, LAPACKE_dlange_work does allocate a new work array in case of 1-norm (which translates to inf-norm for the Fortran call). This suggests that the author was aware that in a row-major implementation the work array is needed/useful in a different situation than in the Fortran implementation. However, this allocation does not happen in LAPACKE_dlantr_work (which has caused me a lot of pain in our Gonum interface before I figured it out). In other words, there is an inconsistence between LAPACKE_dlange_work, which allocates, and a bunch of other function, which don't and therefore cause surprises.
LAPACKE_?larfb_work
passeswork
andldwork
to the Fortran routine unmodified even if the matrix layout is row major. This is extremely surprising bordering a bug because it means that the work matrix has to be column major while all the other matrices are treated as row major. Interestingly,LAPACKE_?larfb
follows the game and the work matrix it allocates (due toldwork
it uses) is column major.I might be wrong but the only reasonable solution I see is not to allocate work in
LAPACKE_?larfb
and allocate it inLAPACKE_?larfb_work
instead while ignoringwork
andldwork
parameters passed to it.It seems that
LAPACKE_?tprfb_work
andLAPACKE_?trsna_work
suffer from the same problem.The text was updated successfully, but these errors were encountered: