Mailman 3 March 2017 - NumPy-Discussion

Why do mgrid and meshgrid not return broadcast arrays?
by Juan Nunez-Iglesias March 9, 2017

March 9, 2017

I was a bit surprised to discover that both meshgrid nor mgrid return fully instantiated arrays, when simple broadcasting (ie with stride=0 for other axes) is functionally identical and happens much, much faster. I wrote my own function to do this: def broadcast_mgrid(arrays): shape = tuple(map(len, arrays)) ndim = len(shape) result = [] for i, arr in enumerate(arrays, start=1): reshaped = np.broadcast_to(arr[[...] + [np.newaxis] * (ndim - i)], shape) result.append(reshaped) return result For even a modest-sized 512 x 512 grid, this version is close to 100x faster: In [154]: %timeit th.broadcast_mgrid((np.arange(512), np.arange(512))) 10000 loops, best of 3: 25.9 µs per loop In [156]: %timeit np.meshgrid(np.arange(512), np.arange(512)) 100 loops, best of 3: 2.02 ms per loop In [157]: %timeit np.mgrid[:512, :512] 100 loops, best of 3: 4.84 ms per loop Is there a conscious design decision as to why this isn’t what meshgrid/mgrid do already? Or would a PR be welcome to do this? Thanks, Juan.

3 5

NumPy pre-release 1.12.1rc1
by Charles R Harris March 7, 2017

March 7, 2017

Hi All, I'm pleased to announce the release of NumPy 1.12.1rc1. NumPy 1.12.1rc1 supports Python 2.7 and 3.4 - 3.6 and fixes bugs and regressions found in NumPy 1.12.0. In particular, the regression in f2py constant parsing is fixed. Wheels for Linux, Windows, and OSX can be found on pypi. Archives can be downloaded from github <https://github.com/numpy/numpy/releases/tag/v1.12.1rc1>. *Contributors* A total of 10 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Charles Harris * Eric Wieser * Greg Young * Joerg Behrmann + * John Kirkham * Julian Taylor * Marten van Kerkwijk * Matthew Brett * Shota Kawabuchi * Jean Utke + *Fixes Backported* * #8483: BUG: Fix wrong future nat warning and equiv type logic error... * #8489: BUG: Fix wrong masked median for some special cases * #8490: DOC: Place np.average in inline code * #8491: TST: Work around isfinite inconsistency on i386 * #8494: BUG: Guard against replacing constants without `'_'` spec in f2py. * #8524: BUG: Fix mean for float 16 non-array inputs for 1.12 * #8571: BUG: Fix calling python api with error set and minor leaks for... * #8602: BUG: Make iscomplexobj compatible with custom dtypes again * #8618: BUG: Fix undefined behaviour induced by bad `__array_wrap__` * #8648: BUG: Fix `MaskedArray.__setitem__` * #8659: BUG: PPC64el machines are POWER for Fortran in f2py * #8665: BUG: Look up methods on MaskedArray in `_frommethod` * #8674: BUG: Remove extra digit in `binary_repr` at limit * #8704: BUG: Fix deepcopy regression for empty arrays. * #8707: BUG: Fix ma.median for empty ndarrays Cheers, Chuck

1 0

vectorization vs. numpy.linalg (shape (3, 3, 777) vs shape (777, 3, 3))
by Nico Schlömer March 5, 2017

March 5, 2017

Hi everyone, When trying to speed up my code, I noticed that simply by reordering my data I could get more than twice as fast for the simplest operations: ``` import numpy a = numpy.random.rand(50, 50, 50) %timeit a[0] + a[1] 1000000 loops, best of 3: 1.7 µs per loop %timeit a[:, 0] + a[:, 1] 100000 loops, best of 3: 4.42 µs per loop %timeit a[..., 0] + a[..., 1] 100000 loops, best of 3: 5.99 µs per loop ``` This makes sense considering the fact that, by default, NumPy features C-style memory allocation: the last index runs fastest. The blocks that are added with `a[0] + a[1]` are contiguous in memory, so cache is nicely made use of. As opposed to that, the blocks that are added with `a[:, 0] + a[:, 1]` are not contiguous, even more so with `a[..., 0] + a[..., 1]`; hence the slowdown. Would that be the correct explanation? If yes, I'm wondering why most numpy.linalg methods, when vectorized, put the vector index up front. E.g., to mass-compute determinants, one has to do ``` a = numpy.random.rand(777, 3, 3) numpy.linalg.det(a) ``` This way, all 3x3 matrices form a memory block, so if you do `det` block by block, that'll be fine. However, vectorized operations (like `+` above) will be slower than necessary. Any background on this? (I came across this when having to rearrange my data (swapaxes, rollaxis) from shape (3, 3, 777) (which allows for fast vectorized operations in the rest of the code) to (777, 3, 3) for using numpy's svd.) Cheers, Nico

3 4

Numpy Overhead
by Sebastian K March 1, 2017

March 1, 2017

Hello everyone, I'm interested in the numpy project and tried a lot with the numpy array. I'm wondering what is actually done that there is so much overhead when I call a function in Numpy. What is the reason? Thanks in advance. Regards Sebastian Kaster

5 10