### I want some test data for LU or QR

Posted:

**Thu Dec 10, 2009 12:09 am**I want to find some huge test data. They should be big enough, so that I can compare my CUDA program with CULA'S LU OR QR. If you know, please tell me. Thanks!

GPU Accelerated Linear Algebera

http://www.culatools.com/forums/

Page **1** of **1**

Posted: **Thu Dec 10, 2009 12:09 am**

I want to find some huge test data. They should be big enough, so that I can compare my CUDA program with CULA'S LU OR QR. If you know, please tell me. Thanks!

Posted: **Thu Dec 10, 2009 8:34 am**

For the most part you should be able to use random data for testing purposes if your main interest is speed (it's a different story if you're examining accuracy). QR executes in a data-independent manner, so as long as you don't have any under/overflow then it will execute in the same amount of time whether the data is random or structured. LU's execution is data dependent, and the number of row swaps performed will (probably) increase with random data so there might be a small performance penalty but at least it will apply to both solvers.

I hope that helps,

John

I hope that helps,

John

Posted: **Fri Dec 18, 2009 8:06 am**

I'm finding that the R matrix (taken by copying the upper part of A) from:

culaDeviceSgeqrf((int)mrowsA, (int)ncolsA, A_d, (int)mrowsA, tau_d);

has rows that differ randomly in sign with the matlab [Q,R] = qr(X,0) call.

It could be the 3rd, 5th, 6th, 10th, etc. About half of the row exhibit this error.

I've tested my wrapper by using dgeqrf from glapack_090209 written by Volkov et. al and don't get these sign changes.

I'm using Cula Basic 1.1 (on Vista 64) that I downloaded this week (Dec. 16th).

dgetrf() is fine BTW (with the associated visible loss of precision on 64 x 64 input matrix of floats)

I'll check if culaSgeqrf() has the same issue.

culaDeviceSgeqrf((int)mrowsA, (int)ncolsA, A_d, (int)mrowsA, tau_d);

has rows that differ randomly in sign with the matlab [Q,R] = qr(X,0) call.

It could be the 3rd, 5th, 6th, 10th, etc. About half of the row exhibit this error.

I've tested my wrapper by using dgeqrf from glapack_090209 written by Volkov et. al and don't get these sign changes.

I'm using Cula Basic 1.1 (on Vista 64) that I downloaded this week (Dec. 16th).

dgetrf() is fine BTW (with the associated visible loss of precision on 64 x 64 input matrix of floats)

I'll check if culaSgeqrf() has the same issue.

Posted: **Fri Dec 18, 2009 9:15 am**

Hi Morris,

Have you attempted to reconstruct the matrix and/or use the QR results? We tested against Matlab a few minutes ago to confirm and found that while there were differences, BOTH QR results were valid. Our answer matched MKL's as well.

The QR factorize isn't unique unless the diagonal values of R are all positive, which ours are (and Matlab's aren't). I think you're just observing two correct but different answers.

Regards,

John

Have you attempted to reconstruct the matrix and/or use the QR results? We tested against Matlab a few minutes ago to confirm and found that while there were differences, BOTH QR results were valid. Our answer matched MKL's as well.

The QR factorize isn't unique unless the diagonal values of R are all positive, which ours are (and Matlab's aren't). I think you're just observing two correct but different answers.

Regards,

John

Posted: **Mon Dec 21, 2009 9:44 am**

John,

Indeed, diag(R) from Matlab are not all positive, but absolutely they match the diag of gpu R matrix: norm(diag(R) - abs(diag(Rgpu))) is like 10e-6 (expected for a 64x64 matrix of randn floats).

I was hoping to run:

sorgqr((int)mrowsA, (int)min, (int)min, A_d, (int)mrowsA, tau_d);

which generates the orthogonal matrix Q from the compact representation returned by sgeqrf(), but sorgqr() is not part of Cala Basic.

I do believe that I'm indeed observing different factorizations. I'll have to dig a bit in our software lib for sorgqr.

Regards,

Morris

Indeed, diag(R) from Matlab are not all positive, but absolutely they match the diag of gpu R matrix: norm(diag(R) - abs(diag(Rgpu))) is like 10e-6 (expected for a 64x64 matrix of randn floats).

I was hoping to run:

sorgqr((int)mrowsA, (int)min, (int)min, A_d, (int)mrowsA, tau_d);

which generates the orthogonal matrix Q from the compact representation returned by sgeqrf(), but sorgqr() is not part of Cala Basic.

I do believe that I'm indeed observing different factorizations. I'll have to dig a bit in our software lib for sorgqr.

Regards,

Morris