[SciPy-dev] Ticket #709 (was: Re: Next scipy release 0.7)

[Nils Wagner]

On Tue, 30 Sep 2008 19:43:10 +0000 (UTC)
  Pauli Virtanen <pav@iki.fi> wrote:
> Tue, 30 Sep 2008 21:21:38 +0200, Nils Wagner wrote:
> 
>> On Tue, 30 Sep 2008 18:36:12 +0000 (UTC)
>>   Pauli Virtanen <pav@iki.fi> wrote:
>>> Tue, 30 Sep 2008 19:56:58 +0200, Nils Wagner wrote:
>>>> IMHO,
>>>> 
>>>> http://projects.scipy.org/scipy/scipy/ticket/709
>>>> 
>>>> should be resolved, too.
>>> 
>>> Short summary about this one: it's about a special
>>>matrix pair for which
>>> LAPACK's generalized eigenvalue problem solver DGGEV
>>>returns bogus
>>> output, losing one eigenvalue from a complex eigenpair.
>>>(The eigenvalue
>>> problem should nonetheless be well-defined, AFAIK, this
>>>looks like a bug
>>> in LAPACK.)
>> 
>> In that case the LAPACK developers should be informed as 
>>soon as
>> possible. Did you check a FORTRAN implementation of the 
>>test case ?
> 
> I didn't contact LAPACK devs yet. I'll try to see if I 
>can reduce this to 
> a simple Fortran testcase.
> 
> But to my understanding, LAPACK's DGEEV has also some 
>other known issues, 
> see eg. 
>http://icl.cs.utk.edu/lapack-forum/viewtopic.php?
> f=2&t=317&p=1060&hilit=dggev
> 
>> Can someone run the test (2dof.py) in Matlab, Octave, 
>>Scilab ?
> 
> I got similar suspect result from Octave's QZ when I 
>tried it (Octave 
> dropped one of the eigenvalues, too).
> 
> Matlab AFAIK does not use Lapack's DGGEV, so the 
>testcase probably will 
> not fail in the same way with it.
> 
>>> The question here is what we should/can do:
>>> 
>>> 1. Raise LinAlgError if we detect this condition.
>>> 
>>> 2. Try to repair the returned data by filling in the
>>>other eigenvalue of
>>>   the pair, as we know all complex eigenvalues come in
>>>pairs.
>> 
>> Well, this holds for real matrices but what could be 
>>done in case of
>> complex matrices ?
> 
>For complex matrices the eigenvectors are returned by 
>LAPACK as complex 
> data directly (and don't need to be separately 
>constructed from real 
> data, as in the real case), so they are simply passed 
>throught by Scipy. 
> If the results are wrong, we probably can't do anything 
>to fix or detect 
> this.
> 
> -- 
> Pauli Virtanen
> 
  
Hi Pauli,

Please find attached an u n t e s t e d FORTRAN 
implementation of 2dof.py.

Cheers,
          Nils
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_lapack.f
Type: text/x-fortran
Size: 2428 bytes
Desc: not available
Url : http://projects.scipy.org/pipermail/scipy-dev/attachments/20080930/d68955fc/attachment.bin