Thread: [Lapackpp-devel] Tested LaLinearSolve(LaGenMatDouble, LaGenMatDouble &, LaGenMatDouble) ?
Status: Beta
Brought to you by:
cstim
Menu
▾
▴
lapackpp-devel
|
From: Jacob \(Jack\) G. <jg...@cs...> - 2004-08-10 01:02:17
|
Hi, I've been trying to solve a matrix equation Ax=b with all 3 variables, A,x, and b, being LaGenMatDoubles. I've used tried the function LaLinearSolve(LaGenMatDouble, LaGenMatDouble &, LaGenMatDouble), however, my results are clearly not correct. (Maybe I'm doing something wrong) Has this been tested? I've noticed the tGenSolve.cc program does not contain a test for the linear solve of 3 matricies. ps. if you haven't noticed, I posted the row-order changes to cvs last night. Jack |
|
From: Christian S. <sti...@tu...> - 2004-08-10 08:09:06
|
Hi, Jacob (Jack) Gryn schrieb: > ps. if you haven't noticed, I posted the row-order changes to cvs last > night. Yes, thanks a lot. This looks very nice. I have noticed and I also added some more documentation in the header. > I've been trying to solve a matrix equation Ax=b with all 3 variables, > A,x, and b, being LaGenMatDoubles. > > I've used tried the function LaLinearSolve(LaGenMatDouble, > LaGenMatDouble &, LaGenMatDouble), however, my results are clearly not > correct. (Maybe I'm doing something wrong) > > Has this been tested? I've noticed the tGenSolve.cc program does not > contain a test for the linear solve of 3 matricies. I did not test the real-valued functions at all since I only use the complex-valued matrices and functions. It may very well be that there is some kind of bug. However, I would be quite surprised if this is the case since the linear solve routines really do not contain any non-trivial operations. Could you document the problem further? I know for sure the LaLinearSolve with LaGenMatComplex works correct, either for vectors or for matrices. Can you try for X and B vectors and then for some simple matrices? Maybe you could post a simple example (3x3) here? Christian |
|
From: Jacob \(Jack\) G. <jg...@cs...> - 2004-08-10 13:31:04
|
I'll look into it some more later today when I get a chance, keep in mind that the code runs differently for square matrices (calls the LaLULinearSolve function) vs non-square matrices (calls the LaQRLinearSolve). I remember that my resulting matrix, X, only had values in the leftmost column, and all were in the order of 10^-306 (I've never seen such small numbers in my life :) ) when matlab's \ operator gave be good results. I'll try the same thing with complex matrices to see what happens, maybe I'm doing something wrong. Jack -----Original Message----- From: Christian Stimming [mailto:sti...@tu...] Sent: Tuesday, August 10, 2004 4:09 AM To: Jacob (Jack) Gryn Cc: lap...@li... Subject: Re: [Lapackpp-devel] Tested LaLinearSolve(LaGenMatDouble, LaGenMatDouble &, LaGenMatDouble) ? Hi, Jacob (Jack) Gryn schrieb: > ps. if you haven't noticed, I posted the row-order changes to cvs last > night. Yes, thanks a lot. This looks very nice. I have noticed and I also added some more documentation in the header. > I've been trying to solve a matrix equation Ax=b with all 3 variables, > A,x, and b, being LaGenMatDoubles. > > I've used tried the function LaLinearSolve(LaGenMatDouble, > LaGenMatDouble &, LaGenMatDouble), however, my results are clearly not > correct. (Maybe I'm doing something wrong) > > Has this been tested? I've noticed the tGenSolve.cc program does not > contain a test for the linear solve of 3 matricies. I did not test the real-valued functions at all since I only use the complex-valued matrices and functions. It may very well be that there is some kind of bug. However, I would be quite surprised if this is the case since the linear solve routines really do not contain any non-trivial operations. Could you document the problem further? I know for sure the LaLinearSolve with LaGenMatComplex works correct, either for vectors or for matrices. Can you try for X and B vectors and then for some simple matrices? Maybe you could post a simple example (3x3) here? Christian |
|
From: Jacob \(Jack\) G. <jg...@cs...> - 2004-08-10 19:38:34
|
I tried it out again with both square and non-square matricies on both complex and doubles: Results are the same for both Complex matricies and Doubles. With square matrices, the results are more viable. The equation AX=B, with A and B being the same, X should return the identity matrix; however it does not. Although through multiplying AX, the result still is B. With rectangular matrices, the results are the same in both complex and doubles, but AX != B; X is usually all 0's, or very close to 0's (10e-300). Any thoughts? Jack -----Original Message----- From: lap...@li... [mailto:lap...@li...] On Behalf Of Jacob (Jack) Gryn Sent: August 10, 2004 9:31 AM To: 'Christian Stimming' Cc: lap...@li... Subject: RE: [Lapackpp-devel] Tested LaLinearSolve(LaGenMatDouble, LaGenMatDouble &, LaGenMatDouble) ? I'll look into it some more later today when I get a chance, keep in mind that the code runs differently for square matrices (calls the LaLULinearSolve function) vs non-square matrices (calls the LaQRLinearSolve). I remember that my resulting matrix, X, only had values in the leftmost column, and all were in the order of 10^-306 (I've never seen such small numbers in my life :) ) when matlab's \ operator gave be good results. I'll try the same thing with complex matrices to see what happens, maybe I'm doing something wrong. Jack -----Original Message----- From: Christian Stimming [mailto:sti...@tu...] Sent: Tuesday, August 10, 2004 4:09 AM To: Jacob (Jack) Gryn Cc: lap...@li... Subject: Re: [Lapackpp-devel] Tested LaLinearSolve(LaGenMatDouble, LaGenMatDouble &, LaGenMatDouble) ? Hi, Jacob (Jack) Gryn schrieb: > ps. if you haven't noticed, I posted the row-order changes to cvs last > night. Yes, thanks a lot. This looks very nice. I have noticed and I also added some more documentation in the header. > I've been trying to solve a matrix equation Ax=b with all 3 variables, > A,x, and b, being LaGenMatDoubles. > > I've used tried the function LaLinearSolve(LaGenMatDouble, > LaGenMatDouble &, LaGenMatDouble), however, my results are clearly not > correct. (Maybe I'm doing something wrong) > > Has this been tested? I've noticed the tGenSolve.cc program does not > contain a test for the linear solve of 3 matricies. I did not test the real-valued functions at all since I only use the complex-valued matrices and functions. It may very well be that there is some kind of bug. However, I would be quite surprised if this is the case since the linear solve routines really do not contain any non-trivial operations. Could you document the problem further? I know for sure the LaLinearSolve with LaGenMatComplex works correct, either for vectors or for matrices. Can you try for X and B vectors and then for some simple matrices? Maybe you could post a simple example (3x3) here? Christian ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ lapackpp-devel mailing list lap...@li... https://lists.sourceforge.net/lists/listinfo/lapackpp-devel |
|
From: Christian S. <sti...@tu...> - 2004-08-10 20:51:41
|
Am Dienstag, 10. August 2004 21:38 schrieb Jacob \(Jack\) Gryn: > I tried it out again with both square and non-square matricies on both > complex and doubles: > > Results are the same for both Complex matricies and Doubles. > > With square matrices, the results are more viable. The equation AX=B, with > A and B being the same, X should return the identity matrix; however it > does not. Although through multiplying AX, the result still is B. > > With rectangular matrices, the results are the same in both complex and > doubles, but AX != B; X is usually all 0's, or very close to 0's > (10e-300). When you say AX != B, how large is the actual difference, that is D=(AX-B) and what is the Mat_Norm2(D)? If that's in fact in the region of 10e-15 or smaller, then you are only seeing some rounding effects due to the floating point representation -- I wouldn't consider this a problem. If you have matrices with numbers in normal regions, then simply consider anything below 10^-10 as zero and you're fine. Did I misunderstand something? Christian |
|
From: Jacob \(Jack\) G. <jg...@cs...> - 2004-08-10 21:07:55
|
The numbers aren't even close, either 0, or 1e-300. I tested, for example, the following. A= [1 1 1 3 3 1 3 2 7 3 2 7] X is a blank 3x3 matrix B=A= [1 1 1 3 3 1 3 2 7 3 2 7] The resulting X is all 0's; when it should be a 3x3 identity matrix. Am I possibly using the function wrong or something? PS. For testing, I've been doing a lot of copying/pasting into matlab and maple; it would be nice if a flag could be set to tell the operator<< call to output the display in various formats. Jack -----Original Message----- From: Christian Stimming [mailto:sti...@tu...] Sent: August 10, 2004 4:46 PM To: Jacob (Jack) Gryn Cc: lap...@li... Subject: Re: [Lapackpp-devel] LaLinearSolve not totally exact Am Dienstag, 10. August 2004 21:38 schrieb Jacob \(Jack\) Gryn: > I tried it out again with both square and non-square matricies on both > complex and doubles: > > Results are the same for both Complex matricies and Doubles. > > With square matrices, the results are more viable. The equation AX=B, > with A and B being the same, X should return the identity matrix; > however it does not. Although through multiplying AX, the result still is B. > > With rectangular matrices, the results are the same in both complex > and doubles, but AX != B; X is usually all 0's, or very close to 0's > (10e-300). When you say AX != B, how large is the actual difference, that is D=(AX-B) and what is the Mat_Norm2(D)? If that's in fact in the region of 10e-15 or smaller, then you are only seeing some rounding effects due to the floating point representation -- I wouldn't consider this a problem. If you have matrices with numbers in normal regions, then simply consider anything below 10^-10 as zero and you're fine. Did I misunderstand something? Christian |
|
From: Jacob \(Jack\) G. <jg...@cs...> - 2004-08-11 00:09:53
|
I believe I solved the problem. The in the linslv.cc function, Xtmp should be a copy of B; however, at no point is an actual copy made. Xtmp is left at 0's before making the dgels call. I replaced line 219 with the line Xtmp=B; and it seems to fix the problem. The output result appears to be correct, at least for an AX=A style problem, where X should return the identity matrix. Although it actually returns I + some small values in the order of 10e-17; whereas CLAPACK returns 0's in these places for the same problem. Is this only something that displays with higher precision, or is there actually a 10e-17 error intruduced somewhere? Jack -----Original Message----- From: lap...@li... [mailto:lap...@li...] On Behalf Of Christian Stimming Sent: August 10, 2004 4:46 PM To: Jacob (Jack) Gryn Cc: lap...@li... Subject: Re: [Lapackpp-devel] LaLinearSolve not totally exact Am Dienstag, 10. August 2004 21:38 schrieb Jacob \(Jack\) Gryn: > I tried it out again with both square and non-square matricies on both > complex and doubles: > > Results are the same for both Complex matricies and Doubles. > > With square matrices, the results are more viable. The equation AX=B, > with A and B being the same, X should return the identity matrix; > however it does not. Although through multiplying AX, the result still is B. > > With rectangular matrices, the results are the same in both complex > and doubles, but AX != B; X is usually all 0's, or very close to 0's > (10e-300). When you say AX != B, how large is the actual difference, that is D=(AX-B) and what is the Mat_Norm2(D)? If that's in fact in the region of 10e-15 or smaller, then you are only seeing some rounding effects due to the floating point representation -- I wouldn't consider this a problem. If you have matrices with numbers in normal regions, then simply consider anything below 10^-10 as zero and you're fine. Did I misunderstand something? Christian ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ lapackpp-devel mailing list lap...@li... https://lists.sourceforge.net/lists/listinfo/lapackpp-devel |
|
From: Christian S. <sti...@tu...> - 2004-08-11 20:49:52
|
Am Mittwoch, 11. August 2004 02:09 schrieb Jacob \(Jack\) Gryn: > I believe I solved the problem. > > The in the linslv.cc function, Xtmp should be a copy of B; however, at no > point is an actual copy made. Xtmp is left at 0's before making the dgels > call. > > I replaced line 219 with the line Xtmp=B; and it seems to fix the problem. > > The output result appears to be correct, at least for an AX=A style > problem, where X should return the identity matrix. That's good :-))) . I think I really didn't work much with the QRSolve functions, so it might well be the case that you just discovered and fixed a bug. However, I thought in line 219 this assignment with LaIndex on the left and on the right should actually do some copying? Whatever. If you say it doesn't, then it probably doesn't and needs to be fixed. If you replace that line with a direct operator=, doesn't it run into some problems with the matrix dimension? The comment there seems to imply this. But of course that comment may well be wrong. If you see that it really is fixed by your proposal, then just go ahead and commit it. > Although it actually returns I + some small values in the order of 10e-17; > whereas CLAPACK returns 0's in these places for the same problem. Is this > only something that displays with higher precision, or is there actually a > 10e-17 error intruduced somewhere? I believe the 1e-17 is the actual epsilon, the machine precision. I see them more than once at places where analytically a zero (like, zero) should be found. But then, in real-world signals there is noise anyway, so these small numbers can really safely considered to be zero. Or in other words, I thought this is just the normal effect of finite-precision arithmetic. Christian |
|
From: Jacob \(Jack\) G. <jg...@cs...> - 2004-08-20 22:17:02
|
Hi, I'm going to commit this fix in linslv.cc to CVS; at the moment, I don't have time to test and implement the same things for the other matricies. Jack -----Original Message----- From: lap...@li... [mailto:lap...@li...] On Behalf Of Christian Stimming Sent: August 11, 2004 4:44 PM To: Jacob (Jack) Gryn Cc: lap...@li... Subject: Re: [Lapackpp-devel] LaLinearSolve not totally exact Am Mittwoch, 11. August 2004 02:09 schrieb Jacob \(Jack\) Gryn: > I believe I solved the problem. > > The in the linslv.cc function, Xtmp should be a copy of B; however, at > no point is an actual copy made. Xtmp is left at 0's before making > the dgels call. > > I replaced line 219 with the line Xtmp=B; and it seems to fix the problem. > > The output result appears to be correct, at least for an AX=A style > problem, where X should return the identity matrix. That's good :-))) . I think I really didn't work much with the QRSolve functions, so it might well be the case that you just discovered and fixed a bug. However, I thought in line 219 this assignment with LaIndex on the left and on the right should actually do some copying? Whatever. If you say it doesn't, then it probably doesn't and needs to be fixed. If you replace that line with a direct operator=, doesn't it run into some problems with the matrix dimension? The comment there seems to imply this. But of course that comment may well be wrong. If you see that it really is fixed by your proposal, then just go ahead and commit it. > Although it actually returns I + some small values in the order of > 10e-17; whereas CLAPACK returns 0's in these places for the same > problem. Is this only something that displays with higher precision, > or is there actually a > 10e-17 error intruduced somewhere? I believe the 1e-17 is the actual epsilon, the machine precision. I see them more than once at places where analytically a zero (like, zero) should be found. But then, in real-world signals there is noise anyway, so these small numbers can really safely considered to be zero. Or in other words, I thought this is just the normal effect of finite-precision arithmetic. Christian ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ lapackpp-devel mailing list lap...@li... https://lists.sourceforge.net/lists/listinfo/lapackpp-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X