[Numpy-discussion] Numpy 2.0 schedule

Mark Wiebe mwwiebe at gmail.com
Wed Jan 26 15:10:32 EST 2011


On Wed, Jan 26, 2011 at 2:23 AM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

> On Wed, Jan 26, 2011 at 12:28 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
>
>> On Tue, Jan 25, 2011 at 5:18 PM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>> On Tue, Jan 25, 2011 at 1:13 PM, Travis Oliphant <oliphant at enthought.com
>>> > wrote:
>>>
>>>>
>>>>  It may make sense for a NumPy 1.6 to come out in March / April in the
>>>> interim.
>>>>
>>>>
>>> Pulling out the changes to attain backward compatibility isn't getting
>>> any easier. I'd rather shoot for 2.0 in June. What can the rest of us do to
>>> help move things along?
>>>
>>
>>
> Focusing on 2.0 makes sense to me too. Besides that, March/April is bad
> timing for me so someone else should volunteer to be the release manager if
> we go for a 1.6.
>

I think sooner than March/April might be a possibility.  I've gotten the ABI
working so this succeeds on my machine:

* Build SciPy against NumPy 1.5.1
* Build NumPy trunk
* Run NumPy trunk with the 1.5.1-built SciPy - all tests pass except for one
(PIL image resize, which tests all float types and half lacks the precisions
necessary)

I took a shot at fixing the ABI compatibility, and if PyArray_ArrFunc was
>> the main issue, then that might be done.  An ABI compatible 1.6 with the
>> datetime and half types should be doable, just some extensions might get
>> confused if they encounter arrays made with the new data types.
>>
>> Even if you fixed the ABI incompatibility (I don't know enough about the
> issue to confirm that), I'm not sure how much value there is in a release
> with as main new feature two dtypes that are not going to work well with
> scipy/other binaries compiled against 1.5.
>

I've recently gotten the faster ufunc NEP implementation finished except for
generalized ufuncs, and most things work the same or faster with it. Below
are some timings of 1.5.1 vs the new_iterator branch.  In particular, the
overhead on small arrays hasn't gotten worse, but the output memory layout
speeds up some operations by a lot.

To exercise the iterator a bit, and try to come up with a better approach
than the generalized ufuncs, I came up with a new function, 'einsum' for the
Einstein summation convention.  I'll send another email about it, but it for
instance solves the problem discussed here:

http://mail.scipy.org/pipermail/numpy-discussion/2006-May/020506.html

as "c = np.einsum('rij,rjk->rik', a, b)"

-Mark

The timings:

In [1]: import numpy as np
In [2]: np.version.version
Out[2]: '1.5.1'
In [3]: a = np.arange(9.).reshape(3,3); b = a.copy()
In [4]: timeit a + b
100000 loops, best of 3: 3.48 us per loop
In [5]: timeit 2 * a
100000 loops, best of 3: 6.07 us per loop
In [6]: timeit np.sum(a)
100000 loops, best of 3: 7.19 us per loop
In [7]: a = np.arange(1000000).reshape(100,100,100); b = a.copy()
In [8]: timeit a + b
100 loops, best of 3: 17.1 ms per loop
In [9]: a = np.arange(1920*1080*3).reshape(1080,1920,3).swapaxes(0,1)
In [10]: timeit a * a
1 loops, best of 3: 794 ms per loop

In [1]: import numpy as np
In [2]: np.version.version
Out[2]: '2.0.0.dev-c97e9d5'
In [3]: a = np.arange(9.).reshape(3,3); b = a.copy()
In [4]: timeit a + b
100000 loops, best of 3: 3.24 us per loop
In [5]: timeit 2 * a
100000 loops, best of 3: 6.12 us per loop
In [6]: timeit np.sum(a)
100000 loops, best of 3: 6.6 us per loop
In [7]: a = np.arange(1000000).reshape(100,100,100); b = a.copy()
In [8]: timeit a + b
100 loops, best of 3: 17 ms per loop
In [9]: a = np.arange(1920*1080*3).reshape(1080,1920,3).swapaxes(0,1)
In [10]: timeit a * a
10 loops, best of 3: 116 ms per loop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110126/32c92500/attachment.html>


More information about the NumPy-Discussion mailing list