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

SciPy scipy-tickets@scipy....
Mon Sep 8 17:35:35 CDT 2008

#709: ValueError: array dimensions are not compatible for copy
 Reporter:  nils          |        Owner:  somebody
     Type:  defect        |       Status:  new     
 Priority:  high          |    Milestone:  0.7.0   
Component:  scipy.linalg  |      Version:  devel   
 Severity:  blocker       |   Resolution:          
 Keywords:                |  
Comment (by 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
 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.

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

More information about the Scipy-tickets mailing list