[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