QR/RQ/QL/LQ factorizations

QR/RQ/QL/LQ factorizations of an array.

Description

Currently RQ, QL, and LQ factorizations are not included in Matlab. Therefore I wrote these mex files, which uses the LAPACK routines. (although these factorizations can also be done by QR and additional matrix manipulations) QR1 is added to complete the set. They can also handle empty matrices. Pivoting algorithms are not included.

• MATLAB release: MATLAB 7.9 (R2009b)
• Other requirements: BLAS/LAPACK

[Hisham]

PLS is there anyone used this function in signal processing???
If there is anyone could you please refer me to any article who used it in signal processing. This part is important for me to do my thesis so I understand more about this fucntion in signal processing and to put some references.
I couldnt find any

THANKS

[Pablo]

Hi, i'm a student and i have some problems with the functions.
- How it works?, because i put,for example, [L,Q]=LQ(A) and matlab displays this message:
"??? Attempt to execute SCRIPT lq as a function"
I put all files in the current directory, and i did File -> Set Path....., but the same message is displayed.
Please help! :(

[Vincent]

Excellent functions. Works perfect for me. Thank you very much!

[Ivo Houtzager]

Thank you for your suggestions. I will go to work again.

[James Tursa]

Correction:

1) It is versions R2007a and earlier that do not have the blas.h and lapack.h header files available.

[James Tursa]

P.S. Your build file looks very nice ... I may adapt your non-PC stuff for my mex submissions.

[James Tursa]

Follow-up:

1) This was based on a quick look at your source code. I didn't see anything in there that looked like macros for this. But as you correctly point out, it is included in blas.h or lapack.h which is included in factor.h which is included in your source code, so you are covered here for later versions of MATLAB. But you are still not covered for earlier version of MATLAB that do not have blas.h or lapack.h available. So your code will not work on those versions (R2006a and earlier??). So you might consider writing your own macros for this, particularly since there are only a handful of functions involved.

3) I think R2006a and earlier do not have the mwSize etc type definitions available.

5) This was based on a quick look at your code. In particular lines like this from your source code:

* compile command:
* mex -O lq.c libmwlapack.lib
* or
* mex -O lq.c libmwblas.lib libmwlapack.lib (>= R2007B)

There is no mention of a build file in the source code, so I didn't realize that the make_factor.m was included for that purpose.

And I will add one addition suggestion:

6) Include in your package help for all of the files. That means including files lq.m, ql.m, qr1.m, and rq.m with the relevant H1 line and associated help text. That way the user can type "help lq" and get some info on the function (e.g., include general syntax and which LAPACK routines are used, etc.). You might also expand the help text in make_factor.m so that "help make_factor" prints out something more descriptive than just "Compilation of mex-files". And add an H1 line to this file too, so that it is easy to find and associate with the functions lq etc. For example, if the user types "lookfor lq" it would be nice if your lq.m help file showed up as well as your make_factor.m file.

[Ivo Houtzager]

Thank you for your suggestions. But I have some remarks:

1) It is not hard coded. If you include the headers "lapack.h" and "blas.h" (see also "factor.h") it will automatically add underscore during preprocessing.

2) I will correct that.

3) For which versions is this?

4) This option is already included in make_factor.m

5) There is already a make_factor.m included for building the mex-files.

[James Tursa]

Some notes on linking with BLAS/LAPACK libraries you might want to incorporate:

1) Don't hard-code the function names because UNIX based systems have different names than WINDOWS systems, typically with an added underscore at the end. Instead put something like this at the top of the routine and then use the macros in your code. e.g.,

#if defined(_WIN32) || defined(_WIN64)
#define DGELQF dgelqf
#define ZGELQF zgelqf
:
etc
#else
#define DGELQF dgelqf_
#define ZGELQF zgelqf_
:
etc
#endif

Then in your code call DGELQF or ZGELQF (uppercase), etc.

2) Don't use mwSize for your integer types to be passed to the BLAS/LAPACK library functions. This only works for 32-bit installations. Use mwSignedIndex instead. For example, this code:

mwSize m, n ... etc
:
dgelqf(&m, &n, Ap, &lda, ptau, pwork, &lwork, &info);

may not work in all cases. But if you change the definitions of m, n, lda, etc then you can make it robust for the 64-bit case.

3) Older MATLAB versions do not have mwSize, mwSignedIndex, etc defined. Put this at the top of your code after the #include "mex.h" line:

#ifndef MWSIZE_MAX
#define mwIndex int
#define mwSignedIndex int
#define mwSize int
#endif

4) For 64-bit versions, the mex build command will have to include the -largeArrayDims flag. This will soon become the default, but for current and past versions this will be needed.

5) For extra points, you could include a build file that automatically looks for the BLAS/LAPACK libraries and links them in as appropriate so the user doesn't have to do this.

If you need any help with this feel free to e-mail me and we can get it worked out.

[piao lin]

very useful code !

thank you very much indeed

[Tim Davis]

This file has collected some very unfair reviews. First, do any of you realize how difficult it is to write a mexFunction that handles both the real and complex cases? In some cases, it's like writing a completely separate code for the complex case. MATLAB stores its complex matrix in a non-standard way that doesn't map directly to C, C++, or Fortran.

So if a code doesn't handle the complex case, and you want the complex case, it's hardly fair to bash a code because of that. The real case may be the only one the author needs. It's almost like saying a Cholesky factorization is useless because it doesn't handle unsymmetric matrices. Please...

Finally, I also find ratings with no comments to be particularly useless. So why is it poor, Nahla? And why do you need to rate it twice? If you rate a code, give specific reasons why it's good or bad. Otherwise your rating is worthless. Worse than useless, because the reason you say it's poor might be for a fairly self-centered reason (such as the complex / real case I mention above).

I haven't read this code yet (I plan to). I give it a 5 simply to discount the spurious and useless ratings given to it so unfairly, and to place my "vote" against them.

Particularly when the author has now posted an update that *does* handle the complex case . Jacob says it's excellent for the real case ... so why does he unfairly rate this as "poor"?

[nahla alkhliefa]

qr factorization

[nahla alkhliefa]

 

[Jacob Tuchler]

excellent for real matrices but I use complex matrices, therefore worthless.

[Fredrik Rusek]

It cannot handle the complex case!!!

[Nu Pra]

Thank you so much for useful codes