Dear all,

I have found a bug in one of my codes and the way it passes a Numpy matrix to MKL's dgemm routine.  Up to now I was assuming that the matrixes are using C order.  I guess I have to correct this assumption :-).

I have found that the numpy.linalg.svd algorithm creates the resulting U, sigma, and V matrixes with Fortran storage.  Is there any way to force these kind of algorithms to not change the storage order?  That would make passing the matrixes to the native dgemm operation much easier.

Cheers,
        -michael

Dr.-Ing. Michael Klemm
Senior Application Engineer
Software and Services Group
Developer Relations Division
Phone   +49 89 9914 2340
Cell    +49 174 2417583


Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Why not just call the algorithm on the transpose of the original array? That will transpose and reverse the order of the SVD, but taking the transposes once the algorithm is finished will ensure they are C ordered. You could also use np.ascontiguousarray on the output arrays, though that results in unnecessary copies that change the memory layout.
Best of luck!