admin 管理员组

文章数量: 1086019

I find that MKL and OpenBLAS give slightly different SVD decompositions.

I have this declaration of dgesvd,

extern "C" {
    void dgesvd_(char const& jobu, char const& jobvt, int const& mm, int const& nn, double* aa, int const& lda, double* s, double* u, int const& ldu, double* vt, int const& ldvt, double* work, int const& lwork, int& info);  // NOLINT_INT(readability-identifier-naming)
}

This declaration works in principle with generic implementations of BLAS/LAPACK, such as OpenBLAS, and also with Intel MKL.

When I pass this array as input

0.5 1
2 2.5

I get for s, vt, and u outputs, respectively as

3.38391 0.221637 

-0.324536 0.945873 
-0.945873 -0.324536

-0.606994 -0.794707 
-0.794707 0.606994

When I link with generic LAPACK, I reconstruct the original array as vt^T.Diag(s).u.

However when I link to MKL, (same code), I get this instead

3.38391 0.221637 

0.324536 0.945873 
0.945873 -0.324536 

0.606994 0.794707 
-0.794707 0.606994

I have to reconstruct the original array in a different way as vt.Diag(s).u, that is there is an extra transposition.

So, it seems that these implementations give different kinds of SVD decompositions. Differing on the transposition on one of the array in the reconstruction.

I am reporting these arrays in C-ordering, (that is why V appears on the left), but this is not the source of the problem.

Is this a bug in MKL? or am I missing something? Is this expected?

(This is very inconvinient because the program cannot be linked to generic BLAS and MKL.)

本文标签： lapackOpenBLAS and MKL give incosistent SVD decompositionsStack Overflow

版权声明：本文标题：lapack - OpenBLAS and MKL give incosistent SVD decompositions? - Stack Overflow 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://roclinux.cn/p/1744054528a2525626.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。