Many unit test failures on OSX mountain lion (10.8) (Trac #1729) #2248
Labels
defect
A clear bug or issue that prevents SciPy from being installed or used as expected
Migrated from Trac
scipy.sparse.linalg
Comments
|
Attachment added by trac user breuderink on 2012-09-18: scipy-1729.zip |
|
@rgommers wrote on 2012-09-18 No good workaround, the final solution should be to simply not use the Accelerate Framework anymore, but standard ATLAS. All failures are for single-precision, so likely won't affect you. |
|
@rgommers wrote on 2012-09-22 Here's a summary of failures: |
|
We have to do something about this for the next release. Comment copied from gh-2547: I'm not sure about disabling Accelerate support - it will create a lot of build issues and a flood of ticket / complaints on the mailing list. Disabling this part of ARPACK functionality (everywhere or only on OS X?) is probably a better alternative. AFAIK it's only single precision that has a problem and that's not widely used. |
pv
added a commit
to pv/scipy-work
that referenced
this issue
Aug 12, 2013
BUG: Completion of g77 ABI wrappers for MacOSX The MacOSX Accelerate framework adheres to g77 ABI conventions. This implies that - every function returning a single precision floating point value (Fortran REAL) in fact returns a double precision value (Fortran DOUBLE PRECISION) - every function returning a complex number is in fact internally a subroutine with the result as the first argument, i.e. COMPLEX FUNCTION X(A, B, C) is in fact SUBROUTINE X(RESULT, A, B, C) Trying to link gfortran generated code with this different ABI results either in crashes (typically for complex) or wrong results (especially for REAL). Scipy already contained wrappers that solved these ABI issues for some BLAS/LAPACK routines (in particular C,ZDOTC, C,ZDOTU), but these ABI wrappers were rather incomplete. As a result, the scipy tests involving single precision failed often on OSX machines (see e.g. issue scipygh-2248). In this pull request: - the ABI wrappers for the basic lapack/blas wrappers in scipy.linalg and scipy.lib are completed - the ABI wrappers for the Fortran routines in scipy.sparse.linalg.isolve are completed - test cases for single precision for the iterative solvers are added (there were no before, so the failure of the iterative solvers on OSX was unnoticed) - the ABI wrappers for ARPACK are completed - single precision in ARPACK has been enabled again With these changes, all relevant tests pass again for my MacOSX 10.8 machine that showed many failures before these patches.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Original ticket http://projects.scipy.org/scipy/ticket/1729 on 2012-09-18 by trac user breuderink, assigned to unknown.
Dear developers,
I installed the development version (the latest would not compile due to VecLib) of SciPy from source:
$ git clone https://github.com/scipy/scipy.git
$ git show
commit 6981d8b
Merge: a4d9a6d cc900a5
Author: Warren Weckesser warren.weckesser@enthought.com
Date: Mon Sep 17 17:34:36 2012 -0700
$ python setup.py build
[see attachment]
$ python setup.py install
[see attachment]
So far, so good. But, when I tried to run the unit tests (I verified this is the only scipy installation on my computer), I get many unit test failures:
$ python -c "import scipy; scipy.test('full')"
[see attachment]
Most seem to be related to arpack. I am really uncomfortable using this scipy installation, and feel that if building succeeds, the unit tests should run without failures. Is there any remedy?
I have attached my environment (both homebrew installed packages and the build environment as well).
The text was updated successfully, but these errors were encountered: