Lambert W function in Scipy 0.16.0 on Linux returns NaN
bryanwweber opened this issue · 14 comments
The lambertw function in Scipy 0.16.0 for Python 3.4.3 returns NaN, no matter the input value. This only happens for Linux (I tested on Ubuntu 14.04), no problems on Windows. Furthermore, building numpy and scipy myself resolves the issue. The lambertw tests in scipy also fail. See also: http://stackoverflow.com/questions/30792319/anaconda3-scipy-special-lambertw-function-return-nan
$ conda info
Current conda install:
platform : linux-64
conda version : 3.16.0
conda-build version : 1.17.0
python version : 3.4.3.final.0
$ ipython
In [1]: import scipy
In [2]: scipy.__version__
Out[2]: '0.16.0'
In [3]: import numpy
In [4]: numpy.__version__
Out[4]: '1.9.2'
In [5]: from scipy.special import lambertw
In [6]: lambertw(1.0)
Out[6]: (nan+0j)
This issue is still occurring on Linux. Is there any progress or update to fixing it?
@bryanwweber I don't think this is specific to the anaconda distribution, so I don't know if you're going to find help here. see scipy/scipy#4443. I got here after googling and hoping that maybe somebody got around to fixing it.
@wholmgren I do think this is Anaconda-specific. With some output simplified:
$ conda create -n scipypiptest python=3.5
$ . activate scipypiptest
$ pip install numpy
Collecting numpy
Successfully built numpy
Installing collected packages: numpy
Successfully installed numpy-1.10.0.post2
$ pip install scipy
Collecting scipy
Building wheels for collected packages: scipy
Successfully built scipy
Installing collected packages: scipy
Successfully installed scipy-0.16.0
$ python -c "from scipy.special import lambertw; print(lambertw(1))"
(0.56714329041+0j)
$ conda list
# packages in environment at /home/bryan/software/anaconda3/envs/scipypiptest:
#
libgfortran 1.0 0
numpy 1.10.0.post2 <pip>
openblas 0.2.14 3
openssl 1.0.1k 1
pip 7.1.2 py35_0
python 3.5.0 0
readline 6.2 2
scipy 0.16.0 <pip>
setuptools 18.3.2 py35_0
sqlite 3.8.4.1 1
tk 8.5.18 0
wheel 0.26.0 py35_1
xz 5.0.5 0
zlib 1.2.8 0
$ conda create -n scipynopiptest python=3.5 scipy
$ . activate scipynopiptest
$ python -c "from scipy.special import lambertw; print(lambertw(1))"
(nan+0j)
Tested on Ubuntu 14.04 with Conda 3.18.1.
Well, I just verified that the problem remains when I install numpy and scipy using pip. My $conda list gives the exact same results as yours. I am using CentOS 6.7. I tried digging into the cython to isolate the problem but I don't have much experience with it and I keep running into road blocks.
Interesting... conda install gcc and then installing numpy/scipy with pip solves the problem for me.
The conda gcc is 4.8.5 and my system gcc is 4.4.7. I should also note that the conda gcc package brings along some additional stuff.
@wholmgren My system GCC is 4.8.4. Perhaps the version of GCC Continuum use to compile SciPy is out of date?
Seems likely. I found some other potentially related gcc 4.4.7 problems on the scipy issues board: scipy/scipy#3794 scipy/scipy#3568.
I'm also guessing that nobody at continuum is going to see this. Maybe try posting to their google groups page with a link to this issue?
https://groups.google.com/a/continuum.io/forum/#!forum/anaconda
@bryanwweber I didn't want to hijack your issue but I figured that I'd go ahead and post it:
https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/oQmTd3gpyfE
Hi, just a reassuring note that people at Continuum have seen this, and
that this Github issues tracker is the right place to post this kind of
problem. We will try to address this ASAP. We build with old compilers
for the sake of backwards compatibility as much as possible, but this may
force an update, or maintenance of more versions.
Thanks for your help in identifying the issue to a compiler version
problem. I think we have to figure out a fix.
On Tue, Oct 13, 2015 at 5:38 PM Will Holmgren notifications@github.com
wrote:
@bryanwweber https://github.com/bryanwweber I didn't want to hijack
your issue but I figured that I'd go ahead and post it:https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/oQmTd3gpyfE
—
Reply to this email directly or view it on GitHub
#425 (comment)
.
@wholmgren @msarahan Thanks for responding and following up on this!
This issue should be fixed in the next SciPy release.
As a workaround for the current SciPy versions in Anaconda, optimizations based on strict aliasing rules should be disabled for the scipy.special._ufuncs extension module.
This can be done by adding the gcc compiler option -fno-strict-aliasing to the build config of the _ufuncs extension in scipy/special/setup.py. The following is a diff against the current SciPy release (0.17.0) which does this.
diff --git a/scipy/special/setup.py b/scipy/special/setup.py
index e5efb2e..e7f9c7a 100755
--- a/scipy/special/setup.py
+++ b/scipy/special/setup.py
@@ -78,10 +78,11 @@ def configuration(parent_package='',top_path=None):
cfg = dict(get_system_info('lapack_opt'))
cfg.setdefault('include_dirs', []).extend([curdir] + inc_dirs + [numpy.get_include()])
cfg.setdefault('libraries', []).extend(['sc_amos','sc_c_misc','sc_cephes','sc_mach',
'sc_cdf', 'sc_specfun'])
cfg.setdefault('define_macros', []).extend(define_macros)
+ cfg.setdefault('extra_compile_args', []).extend(['-fno-strict-aliasing'])
config.add_extension('_ufuncs',
depends=ufuncs_dep,
sources=ufuncs_src,
extra_info=get_info("npymath"),
**cfg)It would be nice if you could rebuild the Anaconda scipy packages with this patch.
this looks to be fixed already?
This should have been fixed by scipy/scipy#6074, +1 for closing