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.
Great submission, very useful for a lot of purposes! But I found out that there might be some bugs, or maybe it is only because of my Matlab version (2012a), I'm not sure..
For example, when I want to get the QL-decomposition, it's fine for square matrices, but for any kind of non-square matrix, I get a fatal error and Matlab shuts itself down. Did anybody also notice such kind of error?
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
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! :(
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:
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.
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.
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.,
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.
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"?
24 Dec 2007
nahla alkhliefa
qr factorization
22 Dec 2007
nahla alkhliefa
09 Nov 2007
Jacob Tuchler
excellent for real matrices but I use complex matrices, therefore worthless.
08 Nov 2007
Fredrik Rusek
It cannot handle the complex case!!!
08 Nov 2007
Nu Pra
Thank you so much for useful codes
Updates
24 Sep 2007
add mex files
12 Nov 2007
Now also supports single precision and complex matrices.