On 4/26/11 3:18 PM, Jason Grout wrote:
On 4/26/11 11:49 AM, Pauli Virtanen wrote:
But apparently either there's a bug, or the LAPACK man page needs to
be understood as you say.
I've posted a question to the Lapack forum:
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2t=2402
We've got
On 4/25/11 12:57 PM, Pauli Virtanen wrote:
On Mon, 25 Apr 2011 10:16:13 -0700, Rob Beezer wrote:
[clip]
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.
The
On 4/25/11 12:57 PM, Pauli Virtanen wrote:
The Numpy routine is a very thin wrapper of LAPACK's ZGESDD, and probably
cannot have any bugs of this kind,
As noted in my other message, I've been digging through the ZGESDD docs
to understand it better. Here is the doc string for what becomes the
On 4/26/11 11:07 AM, Jason Grout wrote:
And indeed, I get a 0 row as the last row of the V**H matrix
I just double-checked things one last time and saw that I actually
hadn't changed the first argument of zgesdd to A in the program that I
actually ran. So with this change, I get a nonzero
On 4/26/11 11:12 AM, Jason Grout wrote:
On 4/26/11 11:07 AM, Jason Grout wrote:
And indeed, I get a 0 row as the last row of the V**H matrix
I just double-checked things one last time and saw that I actually
hadn't changed the first argument of zgesdd to A in the program that I
actually ran.
On 4/26/11 11:22 AM, Jason Grout wrote:
On 4/26/11 11:12 AM, Jason Grout wrote:
On 4/26/11 11:07 AM, Jason Grout wrote:
And indeed, I get a 0 row as the last row of the V**H matrix
I just double-checked things one last time and saw that I actually
hadn't changed the first argument of zgesdd
Tue, 26 Apr 2011 11:36:19 -0500, Jason Grout wrote:
[clip]
Okay, just one more data point. Our people that are seeing the problem
with numpy returning a non-unitary V also see a non-unitary V being
returned by the test C call to zgesdd. In other words, it really
appears that zgesdd follows
On Tue, Apr 26, 2011 at 6:36 PM, Jason Grout
jason-s...@creativetrax.com wrote:
On 4/26/11 11:22 AM, Jason Grout wrote:
On 4/26/11 11:12 AM, Jason Grout wrote:
On 4/26/11 11:07 AM, Jason Grout wrote:
And indeed, I get a 0 row as the last row of the V**H matrix
I just double-checked things
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
On Tue, 26 Apr 2011 10:33:07 -0500, Jason Grout wrote:
[clip]
I was just looking up the documentation for ZGESDD and noticed that the
value we have for rwork in the numpy call [1] does not match the Lapack
docs. This was changed in Lapack 3.2.2 [2]. I've submitted a pull
request:
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
On 4/26/11 11:49 AM, Pauli Virtanen wrote:
Tue, 26 Apr 2011 11:36:19 -0500, Jason Grout wrote:
[clip]
Okay, just one more data point. Our people that are seeing the problem
with numpy returning a non-unitary V also see a non-unitary V being
returned by the test C call to zgesdd. In other
On 4/26/11 11:49 AM, Pauli Virtanen wrote:
But apparently either there's a bug, or the LAPACK man page needs to
be understood as you say.
I've posted a question to the Lapack forum:
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2t=2402
Thanks,
Jason
On Tue, 26 Apr 2011 14:52:52 -0500, Jason Grout wrote:
[clip]
The updated rwork calculation makes no difference with a 3x4 matrix
(both the old calculation and the new calculation give 66 in the 3x4
case), so I don't think that is affecting anything.
Actually, there *is* a difference for the
On 4/26/11 3:29 PM, Pauli Virtanen wrote:
On Tue, 26 Apr 2011 14:52:52 -0500, Jason Grout wrote:
[clip]
The updated rwork calculation makes no difference with a 3x4 matrix
(both the old calculation and the new calculation give 66 in the 3x4
case), so I don't think that is affecting anything.
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
On Mon, 25 Apr 2011 10:16:13 -0700, Rob Beezer wrote:
[clip]
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.
The Numpy routine is a very thin wrapper of
On 25. apr. 2011, at 19.57, Pauli Virtanen wrote:
On Mon, 25 Apr 2011 10:16:13 -0700, Rob Beezer wrote:
[clip]
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 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
19 matches
Mail list logo
