Re: [Numpy-discussion] Multi-distribution Linux wheels - please test

[Daπid]

On 8 February 2016 at 20:25, Matthew Brett  wrote:

>
> I used the latest release, v0.2.15:
>
> https://github.com/matthew-brett/manylinux-builds/blob/master/build_openblas.sh#L5
>
> Is there a later version that we should try?
>
> Cheers,
>

That is the one in the Fedora repos that is working for me. How are you
compiling it?

Mine is compiled with GCC 5 with the options seen in the source rpm:
http://koji.fedoraproject.org/koji/packageinfo?packageID=15277
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] resizeable arrays using shared memory?

[Feng Yu]

Hi,

If the base address and size of the anonymous memory map are 'shared',
then one can protect them with a lock, grow the memmap with remap (or
unmap and map, or other tricks), and release the lock. During the
'resize' call, any reference to the array from Python in other
processes could just spin on the lock.

This is probably more defined than using signals. but I am not sure
about how to enforce the spinning when an object is referenced.

A possibility is that one can insist that a 'resizable' mmap must be
accessed via a context manager, e.g.

growable = shm.growable(initsize)

rank = do the magic to fork processes

if rank == 0:
growable.grow(fill=0, size=10)
else:
with growable as a:
   a += 10


Yu

On Sun, Feb 7, 2016 at 3:11 PM, Elliot Hallmark  wrote:
> That makes sense.  I could either send a signal to the child process letting
> it know to re-instantiate the numpy array using the same (but now resized)
> buffer, or I could have it check to see if the buffer has been resized when
> it might need it and re-instantiate then.  That's actually not too bad.  It
> would be nice if the array could be resized, but it's probably unstable to
> do so and there isn't much demand for it.
>
> Thanks,
>   Elliot
>
> On Sat, Feb 6, 2016 at 8:01 PM, Sebastian Berg 
> wrote:
>>
>> On Sa, 2016-02-06 at 16:56 -0600, Elliot Hallmark wrote:
>> > Hi all,
>> >
>> > I have a program that uses resize-able arrays.  I already over
>> > -provision the arrays and use slices, but every now and then the data
>> > outgrows that array and it needs to be resized.
>> >
>> > Now, I would like to have these arrays shared between processes
>> > spawned via multiprocessing (for fast interprocess communication
>> > purposes, not for parallelizing work on an array).  I don't care
>> > about mapping to a file on disk, and I don't want disk I/O happening.
>> >   I don't care (really) about data being copied in memory on resize.
>> > I *do* want the array to be resized "in place", so that the child
>> > processes can still access the arrays from the object they were
>> > initialized with.
>> >
>> >
>> > I can share arrays easily using arrays that are backed by memmap.
>> > Ie:
>> >
>> > ```
>> > #Source: http://github.com/rainwoodman/sharedmem
>> >
>> >
>> > class anonymousmemmap(numpy.memmap):
>> > def __new__(subtype, shape, dtype=numpy.uint8, order='C'):
>> >
>> > descr = numpy.dtype(dtype)
>> > _dbytes = descr.itemsize
>> >
>> > shape = numpy.atleast_1d(shape)
>> > size = 1
>> > for k in shape:
>> > size *= k
>> >
>> > bytes = int(size*_dbytes)
>> >
>> > if bytes > 0:
>> > mm = mmap.mmap(-1,bytes)
>> > else:
>> > mm = numpy.empty(0, dtype=descr)
>> > self = numpy.ndarray.__new__(subtype, shape, dtype=descr,
>> > buffer=mm, order=order)
>> > self._mmap = mm
>> > return self
>> >
>> > def __array_wrap__(self, outarr, context=None):
>> > return
>> > numpy.ndarray.__array_wrap__(self.view(numpy.ndarray), outarr,
>> > context)
>> > ```
>> >
>> > This cannot be resized because it does not own it's own data
>> > (ValueError: cannot resize this array: it does not own its data).
>> > (numpy.memmap has this same issue [0], even if I set refcheck to
>> > False and even though the docs say otherwise [1]).
>> >
>> > arr._mmap.resize(x) fails because it is annonymous (error: [Errno 9]
>> > Bad file descriptor).  If I create a file and use that fileno to
>> > create the memmap, then I can resize `arr._mmap` but the array itself
>> > is not resized.
>> >
>> > Is there a way to accomplish what I want?  Or, do I just need to
>> > figure out a way to communicate new arrays to the child processes?
>> >
>>
>> I guess the answer is no, but the first question should be whether you
>> can create a new array viewing the same data that is just larger? Since
>> you have the mmap, that would be creating a new view into it.
>>
>> I.e. your "array" would be the memmap, and to use it, you always rewrap
>> it into a new numpy array.
>>
>> Other then that, you would have to mess with the internal ndarray
>> structure, since these kind of operations appear rather unsafe.
>>
>> - Sebastian
>>
>>
>> > Thanks,
>> >   Elliot
>> >
>> > [0] https://github.com/numpy/numpy/issues/4198.
>> >
>> > [1] http://docs.scipy.org/doc/numpy/reference/generated/numpy.memmap.
>> > resize.html
>> >
>> >
>> > ___
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion@scipy.org
>> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussio

Re: [Numpy-discussion] resizeable arrays using shared memory?

[Daπid]

On 6 February 2016 at 23:56, Elliot Hallmark  wrote:
> Now, I would like to have these arrays shared between processes spawned via 
> multiprocessing (for fast interprocess communication purposes, not for 
> parallelizing work on an array).  I don't care about mapping to a file on 
> disk, and I don't want disk I/O happening.  I don't care (really) about data 
> being copied in memory on resize.  I *do* want the array to be resized "in 
> place", so that the child processes can still access the arrays from the 
> object they were initialized with.

If you are only reading in parallel, and you can afford the extra
dependency, one alternative way to do this would be to use an
expandable array from HDF5:

http://www.pytables.org/usersguide/libref/homogenous_storage.html#earrayclassdescr

To avoid I/O, your file can live in RAM.

http://www.pytables.org/cookbook/inmemory_hdf5_files.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Linking other libm-Implementation

[Nils Becker]

2016-02-08 18:54 GMT+01:00 Julian Taylor :
> which version of glibm was used here? There are significant difference
> in performance between versions.
> Also the input ranges are very important for these functions, depending
> on input the speed of these functions can vary by factors of 1000.
>
> glibm now includes vectorized versions of most math functions, does
> openlibm have vectorized math?
> Thats where most speed can be gained, a lot more than 25%.

glibc 2.22 was used running on archlinux. As far as I know openlibm does
not include special vectorized functions. (for reference vectorized
operations in glibc: https://sourceware.org/glibc/wiki/libmvec).

2016-02-08 23:32 GMT+01:00 Gregor Thalhammer :

> Years ago I made the vectorized math functions from Intels Vector Math
> Library (VML), part of MKL, available for numpy, see
> https://github.com/geggo/uvml
> Not particularly difficult, you not even have to change numpy. For some
> cases (e.g., exp) I have seen speedups up to 5x-10x. Unfortunately MKL is
> not free, and free vector math libraries like yeppp implement much fewer
> functions or do not support the required strided memory layout. But to
> improve performance, numexpr, numba or theano are much better.
>
> Gregor
>
>
Thank you very much for the link! I did not know about
numpy.set_numeric_ops.
You are right, vectorized operations can push down calculation time per
element by factors. The benchmarks done for the yeppp-project also indicate
that (however far you would trust them:
http://www.yeppp.info/benchmarks.html). But I would agree that this domain
should be left to specialized tools like numexpr as fully exploiting the
speedup depends on the expression, that should be calculated. It is not
suitable as a standard for numpy.

Still, I think it would be good to give the possibility to choose the libm
numpy links against. And be it simply to allow to choose or guarantee a
specific accuracy/performance on different platforms and systems.
Maybe maintaining a de-facto libm in npy_math could be replaced with a
dependency on e.g. openlibm. But such a decision would require a thorough
benchmark/testing of the available solutions. Especially with respect to
the accuracy-performance-tradeoff that was mentioned.

Cheers
Nils
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Evgeni Burovski]

>>> ==
>>> ERROR: test_multiarray.TestNewBufferProtocol.test_relaxed_strides
>>> --
>>> Traceback (most recent call last):
>>>   File 
>>> "/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/case.py",
>>> line 197, in runTest
>>> self.test(*self.arg)
>>>   File 
>>> "/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py",
>>> line 5366, in test_relaxed_strides
>>> fd.write(c.data)
>>> TypeError: 'buffer' does not have the buffer interface
>>>
>>> --
>>>
>>>
>>> * Scipy tests pass with one error in TestNanFuncs, but the interpreter
>>> crashes immediately afterwards.
>>>
>>>
>>> Same machine, python 3.5: both numpy and scipy tests pass.
>>
>> Ouch - great that you found these, I'll take a look,
>
> I think these are problems with numpy and Python 2.7.3 - because I got
> the same "TypeError: 'buffer' does not have the buffer interface" on
> numpy with OS X with Python.org python 2.7.3, installing from a wheel,
> or installing from source.


Indeed --- updated to python 2.7.11 (Thanks Felix Krull!) and the
failure is gone, `numpy.test()` passes. However:


>>> numpy.test("full")
Running unit tests for numpy
NumPy version 1.10.4
NumPy relaxed strides checking option: False
NumPy is installed in
/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy
Python version 2.7.11 (default, Dec 14 2015, 22:56:59) [GCC 4.6.3]
nose version 1.3.7



==
ERROR: test_kind.TestKind.test_all
--
Traceback (most recent call last):
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/case.py",
line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/util.py",
line 471, in try_run
return func()
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 367, in setUp
module_name=self.module_name)
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 79, in wrapper
memo[key] = func(*a, **kw)
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 150, in build_module
__import__(module_name)
ImportError: 
/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/core/../.libs/libgfortran.so.3:
version `GFORTRAN_1.4' not found (required by
/tmp/tmpPVjYDE/_test_ext_module_5405.so)

==
ERROR: test_mixed.TestMixed.test_all
--
Traceback (most recent call last):
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/case.py",
line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/util.py",
line 471, in try_run
return func()
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 367, in setUp
module_name=self.module_name)
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 79, in wrapper
memo[key] = func(*a, **kw)
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 150, in build_module
__import__(module_name)
ImportError: 
/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/core/../.libs/libgfortran.so.3:
version `GFORTRAN_1.4' not found (required by
/tmp/tmpPVjYDE/_test_ext_module_5405.so)

==
ERROR: test_mixed.TestMixed.test_docstring
--
Traceback (most recent call last):
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/case.py",
line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/util.py",
line 471, in try_run
return func()
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 367, in setUp
module_name=self.module_name)
  File 
"/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/f2py/tests/util.py",
line 85, in wrapper
raise ret
ImportError: 
/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/core/../.libs/libgfortran.so.3:
version `GFORTRAN_1.4' not found (required by
/tmp/tmpPVjYDE/_test_ext_module_5405.so)

==

Re: [Numpy-discussion] Multi-distribution Linux wheels - please test

[Nadav Horesh]

Do not know what happened --- all test passed, even when removed openblas 
(Nathaniel was right).

Manylinux config:

python -c 'import numpy; print(numpy.__config__.show())'
blas_opt_info:
define_macros = [('HAVE_CBLAS', None)]
libraries = ['openblas']
language = c
library_dirs = ['/usr/local/lib']
lapack_opt_info:
define_macros = [('HAVE_CBLAS', None)]
libraries = ['openblas']
language = c
library_dirs = ['/usr/local/lib']
blas_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
define_macros = [('HAVE_CBLAS', None)]
libraries = ['openblas']
language = c
library_dirs = ['/usr/local/lib']
openblas_info:
define_macros = [('HAVE_CBLAS', None)]
libraries = ['openblas']
language = c
library_dirs = ['/usr/local/lib']
None


Source installtion:

python -c 'import numpy; print(numpy.__config__.show())'
openblas_info:
library_dirs = ['/usr/local/lib']
libraries = ['openblas', 'openblas']
language = c
runtime_library_dirs = ['/usr/local/lib']
define_macros = [('HAVE_CBLAS', None)]
openblas_lapack_info:
library_dirs = ['/usr/local/lib']
libraries = ['openblas', 'openblas']
language = c
runtime_library_dirs = ['/usr/local/lib']
define_macros = [('HAVE_CBLAS', None)]
lapack_opt_info:
extra_compile_args = ['-g -ftree-vectorize -mtune=native -march=native -O3']
runtime_library_dirs = ['/usr/local/lib']
define_macros = [('HAVE_CBLAS', None)]
libraries = ['openblas', 'openblas', 'atlas', 'f77blas', 'cblas', 'blas']
language = c
library_dirs = ['/usr/local/lib', '/usr/lib']
blas_mkl_info:
  NOT AVAILABLE
blas_opt_info:
extra_compile_args = ['-g -ftree-vectorize -mtune=native -march=native -O3']
runtime_library_dirs = ['/usr/local/lib']
define_macros = [('HAVE_CBLAS', None)]
libraries = ['openblas', 'openblas', 'atlas', 'f77blas', 'cblas', 'blas']
language = c
library_dirs = ['/usr/local/lib', '/usr/lib']
None


From: NumPy-Discussion  on behalf of 
Matthew Brett 
Sent: 08 February 2016 09:48
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Multi-distribution Linux wheels - please test

Hi Nadav,

On Sun, Feb 7, 2016 at 11:13 PM, Nathaniel Smith  wrote:
> (This is not relevant to the main topic of the thread, but FYI I think the
> recarray issues are fixed in 1.10.4.)
>
> On Feb 7, 2016 11:10 PM, "Nadav Horesh"  wrote:
>>
>> I have atlas-lapack-base installed via pacman (required by sagemath).
>> Since the numpy installation insisted on openblas on /usr/local, I got the
>> openblas source-code and installed  it on /usr/local.
>> BTW, I use 1.11b rather then 1.10.x since the 1.10 is very slow in
>> handling recarrays. For the tests I am erasing the 1.11 installation, and
>> installing the 1.10.4 wheel. I do verify that I have the right version
>> before running the tests, but I am not sure if there no unnoticed side
>> effects.
>>
>> Would it help if I put a side the openblas installation and rerun the
>> test?

Would you mind doing something like this, and posting the output?:

virtualenv test-manylinux
source test-manylinux/bin/activate
pip install -f https://nipy.bic.berkeley.edu/manylinux numpy==1.10.4 nose
python -c 'import numpy; numpy.test()'
python -c 'import numpy; print(numpy.__config__.show())'
deactivate

virtualenv test-from-source
source test-from-source/bin/activate
pip install numpy==1.10.4 nose
python -c 'import numpy; numpy.test()'
python -c 'import numpy; print(numpy.__config__.show())'
deactivate

I'm puzzled that the wheel gives a test error when the source install
does not, and my best guess was an openblas problem, but this just to
make sure we have the output from the exact same numpy version, at
least.

Thanks again,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Linking other libm-Implementation

[Daπid]

On 8 February 2016 at 18:36, Nathaniel Smith  wrote:
> I would be highly suspicious that this speed comes at the expense of
> accuracy... My impression is that there's a lot of room to make
> speed/accuracy tradeoffs in these functions, and modern glibc's libm has
> seen a fair amount of scrutiny by people who have access to the same code
> that openlibm is based off of. But then again, maybe not :-).


I did some digging, and I found this:

http://julia-programming-language.2336112.n4.nabble.com/Is-the-accuracy-of-Julia-s-elementary-functions-exp-sin-known-td32736.html

In short: according to their devs, most openlibm functions are
accurate to less than 1ulp, while GNU libm is rounded to closest
float.


/David.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Linking other libm-Implementation

[Gregor Thalhammer]

> Am 09.02.2016 um 11:21 schrieb Nils Becker :
> 
> 2016-02-08 18:54 GMT+01:00 Julian Taylor  >:
> > which version of glibm was used here? There are significant difference
> > in performance between versions.
> > Also the input ranges are very important for these functions, depending
> > on input the speed of these functions can vary by factors of 1000.
> >
> > glibm now includes vectorized versions of most math functions, does
> > openlibm have vectorized math?
> > Thats where most speed can be gained, a lot more than 25%.
> 
> glibc 2.22 was used running on archlinux. As far as I know openlibm does not 
> include special vectorized functions. (for reference vectorized operations in 
> glibc: https://sourceware.org/glibc/wiki/libmvec 
> ).
> 
> 2016-02-08 23:32 GMT+01:00 Gregor Thalhammer  >:
> Years ago I made the vectorized math functions from Intels Vector Math 
> Library (VML), part of MKL, available for numpy, see 
> https://github.com/geggo/uvml 
> Not particularly difficult, you not even have to change numpy. For some cases 
> (e.g., exp) I have seen speedups up to 5x-10x. Unfortunately MKL is not free, 
> and free vector math libraries like yeppp implement much fewer functions or 
> do not support the required strided memory layout. But to improve 
> performance, numexpr, numba or theano are much better.
> 
> Gregor
> 
> 
> Thank you very much for the link! I did not know about numpy.set_numeric_ops.
> You are right, vectorized operations can push down calculation time per 
> element by factors. The benchmarks done for the yeppp-project also indicate 
> that (however far you would trust them: http://www.yeppp.info/benchmarks.html 
> ). But I would agree that this domain 
> should be left to specialized tools like numexpr as fully exploiting the 
> speedup depends on the expression, that should be calculated. It is not 
> suitable as a standard for bumpy.

Why should numpy not provide fast transcendental math functions? For linear 
algebra it supports fast implementations, even non-free (MKL). Wouldn’t it be 
nice if numpy outperforms C?

> 
> Still, I think it would be good to give the possibility to choose the libm 
> numpy links against. And be it simply to allow to choose or guarantee a 
> specific accuracy/performance on different platforms and systems.
> Maybe maintaining a de-facto libm in npy_math could be replaced with a 
> dependency on e.g. openlibm. But such a decision would require a thorough 
> benchmark/testing of the available solutions. Especially with respect to the 
> accuracy-performance-tradeoff that was mentioned.
> 

Intel publishes accuracy/performance charts for VML/MKL:
https://software.intel.com/sites/products/documentation/doclib/mkl/vm/functions/_accuracyall.html
 


For GNU libc it is more difficult to find similarly precise data, I only could 
find:
http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html 


Gregor


> Cheers
> Nils
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Linking other libm-Implementation

[Matthew Brett]

On Tue, Feb 9, 2016 at 7:06 AM, Daπid  wrote:
> On 8 February 2016 at 18:36, Nathaniel Smith  wrote:
>> I would be highly suspicious that this speed comes at the expense of
>> accuracy... My impression is that there's a lot of room to make
>> speed/accuracy tradeoffs in these functions, and modern glibc's libm has
>> seen a fair amount of scrutiny by people who have access to the same code
>> that openlibm is based off of. But then again, maybe not :-).
>
>
> I did some digging, and I found this:
>
> http://julia-programming-language.2336112.n4.nabble.com/Is-the-accuracy-of-Julia-s-elementary-functions-exp-sin-known-td32736.html
>
> In short: according to their devs, most openlibm functions are
> accurate to less than 1ulp, while GNU libm is rounded to closest
> float.

So GNU libm has max error <= 0.5 ULP, openlibm has <= 1 ULP, and OSX
is (almost always) somewhere in-between.

So, is <= 1 ULP good enough?

Cheers,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Julian Taylor]

On 09.02.2016 04:59, Nathaniel Smith wrote:
> On Mon, Feb 8, 2016 at 6:07 PM, Nathaniel Smith  wrote:
>> On Mon, Feb 8, 2016 at 6:04 PM, Matthew Brett  
>> wrote:
>>> On Mon, Feb 8, 2016 at 5:26 PM, Nathaniel Smith  wrote:
 On Mon, Feb 8, 2016 at 4:37 PM, Matthew Brett  
 wrote:
 [...]
> I can't replicate the segfault with manylinux wheels and scipy.  On
> the other hand, I get a new test error for numpy from manylinux, scipy
> from manylinux, like this:
>
> $ python -c 'import scipy.linalg; scipy.linalg.test()'
>
> ==
> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 
> 4))
> --
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line
> 197, in runTest
> self.test(*self.arg)
>   File 
> "/usr/local/lib/python2.7/dist-packages/scipy/linalg/tests/test_decomp.py",
> line 658, in eigenhproblem_general
> assert_array_almost_equal(diag2_, ones(diag2_.shape[0]), 
> DIGITS[dtype])
>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
> line 892, in assert_array_almost_equal
> precision=decimal)
>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
> line 713, in assert_array_compare
> raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 4 decimals
>
> (mismatch 100.0%)
>  x: array([ 0.,  0.,  0.], dtype=float32)
>  y: array([ 1.,  1.,  1.])
>
> --
> Ran 1507 tests in 14.928s
>
> FAILED (KNOWNFAIL=4, SKIP=1, failures=1)
>
> This is a very odd error, which we don't get when running over a numpy
> installed from source, linked to ATLAS, and doesn't happen when
> running the tests via:
>
> nosetests /usr/local/lib/python2.7/dist-packages/scipy/linalg
>
> So, something about the copy of numpy (linked to openblas) is
> affecting the results of scipy (also linked to openblas), and only
> with a particular environment / test order.
>
> If you'd like to try and see whether y'all can do a better job of
> debugging than me:
>
> # Run this script inside a docker container started with this incantation:
> # docker run -ti --rm ubuntu:12.04 /bin/bash
> apt-get update
> apt-get install -y python curl
> apt-get install libpython2.7  # this won't be necessary with next
> iteration of manylinux wheel builds
> curl -LO https://bootstrap.pypa.io/get-pip.py
> python get-pip.py
> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy nose
> python -c 'import scipy.linalg; scipy.linalg.test()'

 I just tried this and on my laptop it completed without error.

 Best guess is that we're dealing with some memory corruption bug
 inside openblas, so it's getting perturbed by things like exactly what
 other calls to openblas have happened (which is different depending on
 whether numpy is linked to openblas), and which core type openblas has
 detected.

 On my laptop, which *doesn't* show the problem, running with
 OPENBLAS_VERBOSE=2 says "Core: Haswell".

 Guess the next step is checking what core type the failing machines
 use, and running valgrind... anyone have a good valgrind suppressions
 file?
>>>
>>> My machine (which does give the failure) gives
>>>
>>> Core: Core2
>>>
>>> with OPENBLAS_VERBOSE=2
>>
>> Yep, that allows me to reproduce it:
>>
>> root@f7153f0cc841:/# OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=Core2 python
>> -c 'import scipy.linalg; scipy.linalg.test()'
>> Core: Core2
>> [...]
>> ==
>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 4))
>> --
>> [...]
>>
>> So this is indeed sounding like an OpenBLAS issue... next stop
>> valgrind, I guess :-/
> 
> Here's the valgrind output:
>   https://gist.github.com/njsmith/577d028e79f0a80d2797
> 
> There's a lot of it, but no smoking guns have jumped out at me :-/
> 
> -n
> 

plenty of smoking guns, e.g.:

.==3695== Invalid read of size 8
3417==3695==at 0x7AAA9C0: daxpy_k_CORE2 (in
/usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
3418==3695==by 0x76BEEFC: ger_kernel (in
/usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
3419==3695==by 0x788F618: exec_blas (in
/usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
3420==3695==by 0x76BF099: dger_thread (in
/usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
3421==3695==by 0x767DC37: dger_ (in
/u

Re: [Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Matthew Brett]

On Tue, Feb 9, 2016 at 11:37 AM, Julian Taylor
 wrote:
> On 09.02.2016 04:59, Nathaniel Smith wrote:
>> On Mon, Feb 8, 2016 at 6:07 PM, Nathaniel Smith  wrote:
>>> On Mon, Feb 8, 2016 at 6:04 PM, Matthew Brett  
>>> wrote:
 On Mon, Feb 8, 2016 at 5:26 PM, Nathaniel Smith  wrote:
> On Mon, Feb 8, 2016 at 4:37 PM, Matthew Brett  
> wrote:
> [...]
>> I can't replicate the segfault with manylinux wheels and scipy.  On
>> the other hand, I get a new test error for numpy from manylinux, scipy
>> from manylinux, like this:
>>
>> $ python -c 'import scipy.linalg; scipy.linalg.test()'
>>
>> ==
>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 
>> 4))
>> --
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line
>> 197, in runTest
>> self.test(*self.arg)
>>   File 
>> "/usr/local/lib/python2.7/dist-packages/scipy/linalg/tests/test_decomp.py",
>> line 658, in eigenhproblem_general
>> assert_array_almost_equal(diag2_, ones(diag2_.shape[0]), 
>> DIGITS[dtype])
>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>> line 892, in assert_array_almost_equal
>> precision=decimal)
>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>> line 713, in assert_array_compare
>> raise AssertionError(msg)
>> AssertionError:
>> Arrays are not almost equal to 4 decimals
>>
>> (mismatch 100.0%)
>>  x: array([ 0.,  0.,  0.], dtype=float32)
>>  y: array([ 1.,  1.,  1.])
>>
>> --
>> Ran 1507 tests in 14.928s
>>
>> FAILED (KNOWNFAIL=4, SKIP=1, failures=1)
>>
>> This is a very odd error, which we don't get when running over a numpy
>> installed from source, linked to ATLAS, and doesn't happen when
>> running the tests via:
>>
>> nosetests /usr/local/lib/python2.7/dist-packages/scipy/linalg
>>
>> So, something about the copy of numpy (linked to openblas) is
>> affecting the results of scipy (also linked to openblas), and only
>> with a particular environment / test order.
>>
>> If you'd like to try and see whether y'all can do a better job of
>> debugging than me:
>>
>> # Run this script inside a docker container started with this 
>> incantation:
>> # docker run -ti --rm ubuntu:12.04 /bin/bash
>> apt-get update
>> apt-get install -y python curl
>> apt-get install libpython2.7  # this won't be necessary with next
>> iteration of manylinux wheel builds
>> curl -LO https://bootstrap.pypa.io/get-pip.py
>> python get-pip.py
>> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy nose
>> python -c 'import scipy.linalg; scipy.linalg.test()'
>
> I just tried this and on my laptop it completed without error.
>
> Best guess is that we're dealing with some memory corruption bug
> inside openblas, so it's getting perturbed by things like exactly what
> other calls to openblas have happened (which is different depending on
> whether numpy is linked to openblas), and which core type openblas has
> detected.
>
> On my laptop, which *doesn't* show the problem, running with
> OPENBLAS_VERBOSE=2 says "Core: Haswell".
>
> Guess the next step is checking what core type the failing machines
> use, and running valgrind... anyone have a good valgrind suppressions
> file?

 My machine (which does give the failure) gives

 Core: Core2

 with OPENBLAS_VERBOSE=2
>>>
>>> Yep, that allows me to reproduce it:
>>>
>>> root@f7153f0cc841:/# OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=Core2 python
>>> -c 'import scipy.linalg; scipy.linalg.test()'
>>> Core: Core2
>>> [...]
>>> ==
>>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 4))
>>> --
>>> [...]
>>>
>>> So this is indeed sounding like an OpenBLAS issue... next stop
>>> valgrind, I guess :-/
>>
>> Here's the valgrind output:
>>   https://gist.github.com/njsmith/577d028e79f0a80d2797
>>
>> There's a lot of it, but no smoking guns have jumped out at me :-/
>>
>> -n
>>
>
> plenty of smoking guns, e.g.:
>
> .==3695== Invalid read of size 8
> 3417==3695==at 0x7AAA9C0: daxpy_k_CORE2 (in
> /usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
> 3418==3695==by 0x76BEEFC: ger_kernel (in
> /usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
> 3419==3695==by 0x788F618: exec_blas (in
> /usr/local/lib/python2.7/dist-packages/numpy/

Re: [Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Matthew Brett]

On Mon, Feb 8, 2016 at 7:59 PM, Nathaniel Smith  wrote:
> On Mon, Feb 8, 2016 at 6:07 PM, Nathaniel Smith  wrote:
>> On Mon, Feb 8, 2016 at 6:04 PM, Matthew Brett  
>> wrote:
>>> On Mon, Feb 8, 2016 at 5:26 PM, Nathaniel Smith  wrote:
 On Mon, Feb 8, 2016 at 4:37 PM, Matthew Brett  
 wrote:
 [...]
> I can't replicate the segfault with manylinux wheels and scipy.  On
> the other hand, I get a new test error for numpy from manylinux, scipy
> from manylinux, like this:
>
> $ python -c 'import scipy.linalg; scipy.linalg.test()'
>
> ==
> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 
> 4))
> --
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line
> 197, in runTest
> self.test(*self.arg)
>   File 
> "/usr/local/lib/python2.7/dist-packages/scipy/linalg/tests/test_decomp.py",
> line 658, in eigenhproblem_general
> assert_array_almost_equal(diag2_, ones(diag2_.shape[0]), 
> DIGITS[dtype])
>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
> line 892, in assert_array_almost_equal
> precision=decimal)
>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
> line 713, in assert_array_compare
> raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal to 4 decimals
>
> (mismatch 100.0%)
>  x: array([ 0.,  0.,  0.], dtype=float32)
>  y: array([ 1.,  1.,  1.])
>
> --
> Ran 1507 tests in 14.928s
>
> FAILED (KNOWNFAIL=4, SKIP=1, failures=1)
>
> This is a very odd error, which we don't get when running over a numpy
> installed from source, linked to ATLAS, and doesn't happen when
> running the tests via:
>
> nosetests /usr/local/lib/python2.7/dist-packages/scipy/linalg
>
> So, something about the copy of numpy (linked to openblas) is
> affecting the results of scipy (also linked to openblas), and only
> with a particular environment / test order.
>
> If you'd like to try and see whether y'all can do a better job of
> debugging than me:
>
> # Run this script inside a docker container started with this incantation:
> # docker run -ti --rm ubuntu:12.04 /bin/bash
> apt-get update
> apt-get install -y python curl
> apt-get install libpython2.7  # this won't be necessary with next
> iteration of manylinux wheel builds
> curl -LO https://bootstrap.pypa.io/get-pip.py
> python get-pip.py
> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy nose
> python -c 'import scipy.linalg; scipy.linalg.test()'

 I just tried this and on my laptop it completed without error.

 Best guess is that we're dealing with some memory corruption bug
 inside openblas, so it's getting perturbed by things like exactly what
 other calls to openblas have happened (which is different depending on
 whether numpy is linked to openblas), and which core type openblas has
 detected.

 On my laptop, which *doesn't* show the problem, running with
 OPENBLAS_VERBOSE=2 says "Core: Haswell".

 Guess the next step is checking what core type the failing machines
 use, and running valgrind... anyone have a good valgrind suppressions
 file?
>>>
>>> My machine (which does give the failure) gives
>>>
>>> Core: Core2
>>>
>>> with OPENBLAS_VERBOSE=2
>>
>> Yep, that allows me to reproduce it:
>>
>> root@f7153f0cc841:/# OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=Core2 python
>> -c 'import scipy.linalg; scipy.linalg.test()'
>> Core: Core2
>> [...]
>> ==
>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 4))
>> --
>> [...]
>>
>> So this is indeed sounding like an OpenBLAS issue... next stop
>> valgrind, I guess :-/
>
> Here's the valgrind output:
>   https://gist.github.com/njsmith/577d028e79f0a80d2797
>
> There's a lot of it, but no smoking guns have jumped out at me :-/

Could you send me instructions on replicating the valgrind run, I'll
run on on the actual Core2 machine...

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Julian Taylor]

On 09.02.2016 20:52, Matthew Brett wrote:
> On Mon, Feb 8, 2016 at 7:59 PM, Nathaniel Smith  wrote:
>> On Mon, Feb 8, 2016 at 6:07 PM, Nathaniel Smith  wrote:
>>> On Mon, Feb 8, 2016 at 6:04 PM, Matthew Brett  
>>> wrote:
 On Mon, Feb 8, 2016 at 5:26 PM, Nathaniel Smith  wrote:
> On Mon, Feb 8, 2016 at 4:37 PM, Matthew Brett  
> wrote:
> [...]
>> I can't replicate the segfault with manylinux wheels and scipy.  On
>> the other hand, I get a new test error for numpy from manylinux, scipy
>> from manylinux, like this:
>>
>> $ python -c 'import scipy.linalg; scipy.linalg.test()'
>>
>> ==
>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 
>> 4))
>> --
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line
>> 197, in runTest
>> self.test(*self.arg)
>>   File 
>> "/usr/local/lib/python2.7/dist-packages/scipy/linalg/tests/test_decomp.py",
>> line 658, in eigenhproblem_general
>> assert_array_almost_equal(diag2_, ones(diag2_.shape[0]), 
>> DIGITS[dtype])
>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>> line 892, in assert_array_almost_equal
>> precision=decimal)
>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>> line 713, in assert_array_compare
>> raise AssertionError(msg)
>> AssertionError:
>> Arrays are not almost equal to 4 decimals
>>
>> (mismatch 100.0%)
>>  x: array([ 0.,  0.,  0.], dtype=float32)
>>  y: array([ 1.,  1.,  1.])
>>
>> --
>> Ran 1507 tests in 14.928s
>>
>> FAILED (KNOWNFAIL=4, SKIP=1, failures=1)
>>
>> This is a very odd error, which we don't get when running over a numpy
>> installed from source, linked to ATLAS, and doesn't happen when
>> running the tests via:
>>
>> nosetests /usr/local/lib/python2.7/dist-packages/scipy/linalg
>>
>> So, something about the copy of numpy (linked to openblas) is
>> affecting the results of scipy (also linked to openblas), and only
>> with a particular environment / test order.
>>
>> If you'd like to try and see whether y'all can do a better job of
>> debugging than me:
>>
>> # Run this script inside a docker container started with this 
>> incantation:
>> # docker run -ti --rm ubuntu:12.04 /bin/bash
>> apt-get update
>> apt-get install -y python curl
>> apt-get install libpython2.7  # this won't be necessary with next
>> iteration of manylinux wheel builds
>> curl -LO https://bootstrap.pypa.io/get-pip.py
>> python get-pip.py
>> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy nose
>> python -c 'import scipy.linalg; scipy.linalg.test()'
>
> I just tried this and on my laptop it completed without error.
>
> Best guess is that we're dealing with some memory corruption bug
> inside openblas, so it's getting perturbed by things like exactly what
> other calls to openblas have happened (which is different depending on
> whether numpy is linked to openblas), and which core type openblas has
> detected.
>
> On my laptop, which *doesn't* show the problem, running with
> OPENBLAS_VERBOSE=2 says "Core: Haswell".
>
> Guess the next step is checking what core type the failing machines
> use, and running valgrind... anyone have a good valgrind suppressions
> file?

 My machine (which does give the failure) gives

 Core: Core2

 with OPENBLAS_VERBOSE=2
>>>
>>> Yep, that allows me to reproduce it:
>>>
>>> root@f7153f0cc841:/# OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=Core2 python
>>> -c 'import scipy.linalg; scipy.linalg.test()'
>>> Core: Core2
>>> [...]
>>> ==
>>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 4))
>>> --
>>> [...]
>>>
>>> So this is indeed sounding like an OpenBLAS issue... next stop
>>> valgrind, I guess :-/
>>
>> Here's the valgrind output:
>>   https://gist.github.com/njsmith/577d028e79f0a80d2797
>>
>> There's a lot of it, but no smoking guns have jumped out at me :-/
> 
> Could you send me instructions on replicating the valgrind run, I'll
> run on on the actual Core2 machine...
> 
> Matthew


please also use this suppression file, should reduce the python noise
significantly but it might be a bit out of date. Used to work fine on an
ubuntu built python.
#
# This is a valgrind suppression file that should be used when using valgrind.
#
#  Here's an example of running valgrind:
#
#   cd python/di

[Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Freddy Rietdijk]

On Nix we also had trouble with OpenBLAS 0.2.15. Version 0.2.14 did not
cause any segmentation faults so we reverted to that version.
https://github.com/scipy/scipy/issues/5620

(hopefully this time the e-mail gets through)

On Tue, Feb 9, 2016 at 10:21 AM, Daπid  wrote:

> On 8 February 2016 at 20:25, Matthew Brett 
> wrote:
>
>>
>> I used the latest release, v0.2.15:
>>
>> https://github.com/matthew-brett/manylinux-builds/blob/master/build_openblas.sh#L5
>>
>> Is there a later version that we should try?
>>
>> Cheers,
>>
>
> That is the one in the Fedora repos that is working for me. How are you
> compiling it?
>
> Mine is compiled with GCC 5 with the options seen in the source rpm:
> http://koji.fedoraproject.org/koji/packageinfo?packageID=15277
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Nathaniel Smith]

On Tue, Feb 9, 2016 at 11:37 AM, Julian Taylor
 wrote:
> On 09.02.2016 04:59, Nathaniel Smith wrote:
>> On Mon, Feb 8, 2016 at 6:07 PM, Nathaniel Smith  wrote:
>>> On Mon, Feb 8, 2016 at 6:04 PM, Matthew Brett  
>>> wrote:
 On Mon, Feb 8, 2016 at 5:26 PM, Nathaniel Smith  wrote:
> On Mon, Feb 8, 2016 at 4:37 PM, Matthew Brett  
> wrote:
> [...]
>> I can't replicate the segfault with manylinux wheels and scipy.  On
>> the other hand, I get a new test error for numpy from manylinux, scipy
>> from manylinux, like this:
>>
>> $ python -c 'import scipy.linalg; scipy.linalg.test()'
>>
>> ==
>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 
>> 4))
>> --
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line
>> 197, in runTest
>> self.test(*self.arg)
>>   File 
>> "/usr/local/lib/python2.7/dist-packages/scipy/linalg/tests/test_decomp.py",
>> line 658, in eigenhproblem_general
>> assert_array_almost_equal(diag2_, ones(diag2_.shape[0]), 
>> DIGITS[dtype])
>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>> line 892, in assert_array_almost_equal
>> precision=decimal)
>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>> line 713, in assert_array_compare
>> raise AssertionError(msg)
>> AssertionError:
>> Arrays are not almost equal to 4 decimals
>>
>> (mismatch 100.0%)
>>  x: array([ 0.,  0.,  0.], dtype=float32)
>>  y: array([ 1.,  1.,  1.])
>>
>> --
>> Ran 1507 tests in 14.928s
>>
>> FAILED (KNOWNFAIL=4, SKIP=1, failures=1)
>>
>> This is a very odd error, which we don't get when running over a numpy
>> installed from source, linked to ATLAS, and doesn't happen when
>> running the tests via:
>>
>> nosetests /usr/local/lib/python2.7/dist-packages/scipy/linalg
>>
>> So, something about the copy of numpy (linked to openblas) is
>> affecting the results of scipy (also linked to openblas), and only
>> with a particular environment / test order.
>>
>> If you'd like to try and see whether y'all can do a better job of
>> debugging than me:
>>
>> # Run this script inside a docker container started with this 
>> incantation:
>> # docker run -ti --rm ubuntu:12.04 /bin/bash
>> apt-get update
>> apt-get install -y python curl
>> apt-get install libpython2.7  # this won't be necessary with next
>> iteration of manylinux wheel builds
>> curl -LO https://bootstrap.pypa.io/get-pip.py
>> python get-pip.py
>> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy nose
>> python -c 'import scipy.linalg; scipy.linalg.test()'
>
> I just tried this and on my laptop it completed without error.
>
> Best guess is that we're dealing with some memory corruption bug
> inside openblas, so it's getting perturbed by things like exactly what
> other calls to openblas have happened (which is different depending on
> whether numpy is linked to openblas), and which core type openblas has
> detected.
>
> On my laptop, which *doesn't* show the problem, running with
> OPENBLAS_VERBOSE=2 says "Core: Haswell".
>
> Guess the next step is checking what core type the failing machines
> use, and running valgrind... anyone have a good valgrind suppressions
> file?

 My machine (which does give the failure) gives

 Core: Core2

 with OPENBLAS_VERBOSE=2
>>>
>>> Yep, that allows me to reproduce it:
>>>
>>> root@f7153f0cc841:/# OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=Core2 python
>>> -c 'import scipy.linalg; scipy.linalg.test()'
>>> Core: Core2
>>> [...]
>>> ==
>>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 4))
>>> --
>>> [...]
>>>
>>> So this is indeed sounding like an OpenBLAS issue... next stop
>>> valgrind, I guess :-/
>>
>> Here's the valgrind output:
>>   https://gist.github.com/njsmith/577d028e79f0a80d2797
>>
>> There's a lot of it, but no smoking guns have jumped out at me :-/
>>
>> -n
>>
>
> plenty of smoking guns, e.g.:
>
> .==3695== Invalid read of size 8
> 3417==3695==at 0x7AAA9C0: daxpy_k_CORE2 (in
> /usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
> 3418==3695==by 0x76BEEFC: ger_kernel (in
> /usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
> 3419==3695==by 0x788F618: exec_blas (in
> /usr/local/lib/python2.7/dist-packages/numpy/

Re: [Numpy-discussion] Fwd: Multi-distribution Linux wheels - please test

[Julian Taylor]

On 09.02.2016 21:01, Nathaniel Smith wrote:
> On Tue, Feb 9, 2016 at 11:37 AM, Julian Taylor
>  wrote:
>> On 09.02.2016 04:59, Nathaniel Smith wrote:
>>> On Mon, Feb 8, 2016 at 6:07 PM, Nathaniel Smith  wrote:
 On Mon, Feb 8, 2016 at 6:04 PM, Matthew Brett  
 wrote:
> On Mon, Feb 8, 2016 at 5:26 PM, Nathaniel Smith  wrote:
>> On Mon, Feb 8, 2016 at 4:37 PM, Matthew Brett  
>> wrote:
>> [...]
>>> I can't replicate the segfault with manylinux wheels and scipy.  On
>>> the other hand, I get a new test error for numpy from manylinux, scipy
>>> from manylinux, like this:
>>>
>>> $ python -c 'import scipy.linalg; scipy.linalg.test()'
>>>
>>> ==
>>> FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 
>>> 4))
>>> --
>>> Traceback (most recent call last):
>>>   File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line
>>> 197, in runTest
>>> self.test(*self.arg)
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/scipy/linalg/tests/test_decomp.py",
>>> line 658, in eigenhproblem_general
>>> assert_array_almost_equal(diag2_, ones(diag2_.shape[0]), 
>>> DIGITS[dtype])
>>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>>> line 892, in assert_array_almost_equal
>>> precision=decimal)
>>>   File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py",
>>> line 713, in assert_array_compare
>>> raise AssertionError(msg)
>>> AssertionError:
>>> Arrays are not almost equal to 4 decimals
>>>
>>> (mismatch 100.0%)
>>>  x: array([ 0.,  0.,  0.], dtype=float32)
>>>  y: array([ 1.,  1.,  1.])
>>>
>>> --
>>> Ran 1507 tests in 14.928s
>>>
>>> FAILED (KNOWNFAIL=4, SKIP=1, failures=1)
>>>
>>> This is a very odd error, which we don't get when running over a numpy
>>> installed from source, linked to ATLAS, and doesn't happen when
>>> running the tests via:
>>>
>>> nosetests /usr/local/lib/python2.7/dist-packages/scipy/linalg
>>>
>>> So, something about the copy of numpy (linked to openblas) is
>>> affecting the results of scipy (also linked to openblas), and only
>>> with a particular environment / test order.
>>>
>>> If you'd like to try and see whether y'all can do a better job of
>>> debugging than me:
>>>
>>> # Run this script inside a docker container started with this 
>>> incantation:
>>> # docker run -ti --rm ubuntu:12.04 /bin/bash
>>> apt-get update
>>> apt-get install -y python curl
>>> apt-get install libpython2.7  # this won't be necessary with next
>>> iteration of manylinux wheel builds
>>> curl -LO https://bootstrap.pypa.io/get-pip.py
>>> python get-pip.py
>>> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy nose
>>> python -c 'import scipy.linalg; scipy.linalg.test()'
>>
>> I just tried this and on my laptop it completed without error.
>>
>> Best guess is that we're dealing with some memory corruption bug
>> inside openblas, so it's getting perturbed by things like exactly what
>> other calls to openblas have happened (which is different depending on
>> whether numpy is linked to openblas), and which core type openblas has
>> detected.
>>
>> On my laptop, which *doesn't* show the problem, running with
>> OPENBLAS_VERBOSE=2 says "Core: Haswell".
>>
>> Guess the next step is checking what core type the failing machines
>> use, and running valgrind... anyone have a good valgrind suppressions
>> file?
>
> My machine (which does give the failure) gives
>
> Core: Core2
>
> with OPENBLAS_VERBOSE=2

 Yep, that allows me to reproduce it:

 root@f7153f0cc841:/# OPENBLAS_VERBOSE=2 OPENBLAS_CORETYPE=Core2 python
 -c 'import scipy.linalg; scipy.linalg.test()'
 Core: Core2
 [...]
 ==
 FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 4))
 --
 [...]

 So this is indeed sounding like an OpenBLAS issue... next stop
 valgrind, I guess :-/
>>>
>>> Here's the valgrind output:
>>>   https://gist.github.com/njsmith/577d028e79f0a80d2797
>>>
>>> There's a lot of it, but no smoking guns have jumped out at me :-/
>>>
>>> -n
>>>
>>
>> plenty of smoking guns, e.g.:
>>
>> .==3695== Invalid read of size 8
>> 3417==3695==at 0x7AAA9C0: daxpy_k_CORE2 (in
>> /usr/local/lib/python2.7/dist-packages/numpy/.libs/libopenblas.so.0)
>> 3418==3695==by 0x76BEEFC: ger_kernel (in
>

[Numpy-discussion] NumPy 1.11.0b3 released.

[Charles R Harris]

Hi All,

I'm pleased to announce the release of NumPy 1.11.0b3. This beta contains
additional bug fixes as well as limiting the number of FutureWarnings
raised by assignment to masked array slices. One issue that remains to be
decided is whether or not to postpone raising an error for floats used as
indexes. Sources may be found on Sourceforge
 and both
sources and OS X wheels are availble on pypi. Please test, hopefully this
will be that last beta needed.

As a note on problems encountered, twine uploads continue to fail for me,
but there are still variations to try. The wheeluploader downloaded wheels
as it should, but could not upload them, giving the error message
"HTTPError: 413 Client Error: Request Entity Too Large for url:
https://www.python.org/pypi";. Firefox also complains that
http://wheels.scipy.org is incorrectly configured with an invalid
certificate.

Enjoy,

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion