Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's
On 04/26/2011 10:19 AM, Ralf Gommers wrote: If it is an Accelerate bug it got fixed on OS X 10.6. Below is the output with both current master and 1.5.1. It may be worth checking this on 10.5 with the binary Numpy installer from Sourceforge to make sure it's not the Sage build process causing this somehow. Thanks, Ralf. Indeed, we have no reports of problems on OSX 10.6, and it is likely there have been many tests on that platform. So a test of numpy on 10.5, independent of Sage's build process, would be useful. I don't have access to a Mac, but I posted your suggestion to the Sage ticket for this, where hopefully somebody will take it up. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's
On 04/26/2011 11:25 AM, Pauli Virtanen wrote: I think it is worth testing if this change fixes it. Note that current LAPACK docs have the number 7 there instead of 5, so there may really be a bug here. It appears to me the problem is more subtle than just a strict comparison between the number of rows and the number of columns. http://trac.sagemath.org/sage_trac/attachment/ticket/11248/broken.png shows a plot of matrix sizes (number of rows on the horizontal, number of columns on vertical). This is on an OSX 10.5 machine and whereever there is a dot then the SVD seems to *always* produce a non-unitary V, and the absence of a dot indicates no failures were found. So maybe a workspace size could be the culprit? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's
I am working to make many of NumPy's matrix decomposition routines available in Sage. As part of testing a new routine, we have found some odd behavior with the singular value decomposition. On certain Mac's, the numpy built in Sage will return the second of the unitary matrices with a row of all zeros, so of course, it can't be unitary. For the configurations in question, this erroneous output happens only for certain sized matrices and for those sizes it always occurs. The smallest sizes are 3 x 4, 4 x 5, 5 x 6, 5 x 7, 6 x 7, 6 x 8, 6 x 9, 7 x 8, 7 x 9, 8 x 9. The fault is not in Sage code per se, as it can be reproduced by running Sage's python and using numpy directly. It could be possible Sage is not building numpy correctly, we have not tested a standalone version of numpy since this problem seems to be limited to very few configurations. The initial report, and a confirmation, are both on Macs where Sage is built using gcc 4.0.1 and gcc 4.2.1. The test that uncovered this situation was introduced two alpha releases back, and has not failed for testers on Linux or newer Macs. The svd routine itself has been in Sage for about three years without exhibiting any problems, but maybe the cases above were not tested. I do not own a Mac, so testing out scenarios involves sending suggestions to the two folks who have reported failures. Many more details and complete transcripts are at: http://trac.sagemath.org/sage_trac/ticket/11248 Any thoughts or advice to help us understand this would be greatly appreciated. Thanks in advance. Rob -- Robert A. Beezer Professor Department of Mathematics and Computer Science University of Puget Sound 1500 N Warner Tacoma, WA 98416-1043 bee...@ups.edu http://buzzard.ups.edu Voice: 253.879.3564 Fax: 253.879.3522 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Zero row in SVD's unitary matrix on some Mac's
Thanks for the reply, Pauli. I suspected this might be the case, but was hoping maybe this was something that had been seen before. I've included your suggestions on the bug report for Sage. Rob On 04/25/2011 10:57 AM, Pauli Virtanen wrote: The Numpy routine is a very thin wrapper of LAPACK's ZGESDD, and probably cannot have any bugs of this kind, so the problem is most likely with the LAPACK and BLAS libraries you use. You will probably be able to reproduce the problem also with an equivalent Fortran/C snippet calling LAPACK directly. Problems like this in BLAS/LAPACK are somewhat difficult to track. You could try switching to another BLAS library (or, if you use ATLAS, compile it differently) and checking if the problem disappears. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
