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=2&t=2402
W
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 any
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 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=2&t=2402
Thanks,
Jason
__
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 o
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 num
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:
>
> htt
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 causi
On Tue, Apr 26, 2011 at 6:36 PM, Jason Grout
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 one last time
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 follow
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
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
> actua
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 l
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/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
>> appreciate
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 LAPAC
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
>> a
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 LAP
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
19 matches
Mail list logo
