[Scipy-tickets] [SciPy] #709: ValueError: array dimensions are not compatible for copy

SciPy Trac scipy-tickets@scipy....
Thu Apr 22 14:45:22 CDT 2010

#709: ValueError: array dimensions are not compatible for copy
 Reporter:  nils          |       Owner:  somebody      
     Type:  defect        |      Status:  needs_decision
 Priority:  high          |   Milestone:  0.8.0         
Component:  scipy.linalg  |     Version:  devel         
 Keywords:                |  

Comment(by mike3050):

 Replying to [comment:3 pv]:
 > For which value of *p* (in the loop of 2dof.py) your original 2dof.py
 fails? Or does it fail at all? This seems like a rounding issue, so the
 [http://zolpo.com/auto-insurance/ auto insurance quotes] exact value of
 *p* may well vary from one LAPACK installation to another.
 > Which Lapack are you using? I'm using the Netlib one (3.1.1-0.4ubuntu1)
 as shipped by Ubuntu, with Netlib blas, also as shipped by Ubuntu.
 > But this seems like a LAPACK issue to me: the ALPHAI vector returned
 from LAPACK is already bogus. One of the two eigenvalues in the latter
 complex pair is missing, and LAPACK fails to notice this. The problem is
 apparently somehow ill-conditioned.
 > I'm not sure what we should do:
 >   1. Bailing out with LinAlgError is one possibility:
 >      I think we can detect this particular error by looking for
 ALPHAI(i+1) < 0 preceded by
 >      ALPHAI(i) <= 0 in the vector of eigenvalues.
 >   2. Or maybe we should attempt to fix bogus zero ALPHAIs by setting
 zeros following positives
 >      and zeros preceding negatives manually.
 >   3. Or just accept that LAPACK is flawed and return as much as we can
 without trying to correct
 >      its errors.
 > A patch ("ugly-hack.patch") doing 3) is attached: it deobfuscates the
 _make_complex_eigvecs routine and makes it to work also in cases where the
 eigenvalue vector is malformed. It won't rescue clobbered eigenvalues, but
 will handle cases where one of the two entries in the eigenvalue vector is
 malformed. The vector corresponding to the "NaN" eigenvalue will be
 garbage, though.
 > I'm not sure how well Scipy is covered by unit tests, so I'm a bit
 afraid committing this before it's been better tested... And we'll pick
 one of the three options.
 > If someone manages to reduce this to a simple Fortran test case, maybe
 also upstream LAPACK might be interested in fixing this? It doesn't seem
 like this is the intended behaviour.
 Thanks you.You helped me a lot .

Ticket URL: <http://projects.scipy.org/scipy/ticket/709#comment:12>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.

More information about the Scipy-tickets mailing list