<p dir="auto"><em>Original ticket <a href="http://projects.scipy.org/scipy/ticket/1321" rel="nofollow">http://projects.scipy.org/scipy/ticket/1321</a> on 2010-10-28 by trac user commandant2k, assigned to <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/wnbell/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/wnbell">@wnbell</a>.</em></p>
<p dir="auto">The FORTRAN reverse communication routines for iterative solution of linear systems in the scipy.sparse.linalg.isolve module each depend on the BLAS routines cdotc and zdotc to compute complex inner products in single and double precision, respectively. On Mac OS X installations that use the Accelerate or vecLib frameworks for BLAS and LAPACK, these routines are known to have issues when called from FORTRAN. The cause is an ABI mismatch between the functions compiled into the Mac OS X frameworks and the executable code produced by gfortran.</p>
<p dir="auto">This problem exists in other modules of scipy, especially ARPACK in scipy.sparse.linalg.eigen. A workaround was implemented that defines local wrapper functions to call cblas_cdotc_sub and cblas_zdotc_sub, which provide subroutine versions of the BLAS functions that avoid the ABI issue. However, this accommodation was not made in scipy.sparse.linalg.isolve.</p>
<p dir="auto">Attached is a patch to SVN revision 6856 that adds the wrapper functions to the isolve module in the same fashion as the wrappers from scipy.lib.blas and scipy.sparse.linalg.eigen. If neither the Accelerate nor vecLib frameworks are used, a dummy wrapper is in place to directly call the BLAS functions. The FORTRAN reverse communication routines have been modified to call the wrapper routine rather than the BLAS routines.</p>
<p dir="auto">The patch has been tested on scipy 0.8.0 and SVN <a class="commit-link" data-hovercard-type="commit" data-hovercard-url="https://github.com/scipy/scipy/commit/4104bf391491e03a4421ec9305c1c8aebc0b3083/hovercard" href="https://github.com/scipy/scipy/commit/4104bf391491e03a4421ec9305c1c8aebc0b3083"><tt>4104bf3</tt></a> on an Intel Macintosh. More testing should be done on PPC Macs and non-Macintosh systems to confirm that the dummy wrapper behaves as expected on other platforms.</p>
<p dir="auto">Observe that the issues with cdotc and zdotc are only observed when attempting to solve linear systems involving single- or double-precision complex unknowns; for real-valued systems, the module does not invoke the problematic routines.</p>
<p dir="auto">When I compile scipy 1.7.0, an error occured that says "ModuleNotFoundError: No module named 'pythran'". Then I execute <code class="notranslate">pip install pythran</code>, something confusing happened.</p>
<p dir="auto"><strong>17 packages been installed</strong>:</p>
<p dir="auto"><code class="notranslate">pythran decorator beniget ply networkx gast six numpy pandas scipy matplotlib python-dateutil pytz cycler kiwisolver pillow pyparsing</code></p>
<p dir="auto">Even the scipy is in the list, and other scientific packages include <code class="notranslate">numpy pandas matplotlib pillow</code>.</p>
<p dir="auto">First, is it a cyclic dependency for scipy?<br>
Second, pythran is just a compiler to efficiently compile scientific programs, why these packages are installed as its dependencies.<br>
Third, if it is possible to compile scipy without pythran.</p>
<p dir="auto">environment:<br>
Python: 3.9.2<br>
Pip: 21.1.3<br>
numpy: 1.20.1<br>
Cython: 0.29.21<br>
pybind11: 2.6.2</p>