Re: [Numpy-discussion] __numpy_ufunc__

[Ralf Gommers]

On Mon, Nov 7, 2016 at 9:10 AM, Charles R Harris 
wrote:

>
>
> On Sun, Nov 6, 2016 at 11:44 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> For those interested in continuing the __numpy_ufunc__ saga, there is a pull
>> request enabling it . Likely
>> we will want to make some changes up front before merging that, so some
>> discussion is in order.
>>
>>
> As a first order of business, let's decide whether to remove the index and
> rename `__numpy_ufunc__`. The motivation for this is discussed in issue
> #5986. 
> If we decide positive on that (I'm in favor),
>

It seems like everyone on that issue is in favor or at least +0. So +1 from
me too.


> I would be happy with the proposed name `__array_ufunc__`, although
> something more descriptive like `__handle_ufunc__` might be better.
>



> This is a wonderful opportunity for bike shedding for those so inclined ;)
>

pass :)

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

Re: [Numpy-discussion] __numpy_ufunc__

[Ralf Gommers]

On Mon, Nov 7, 2016 at 9:21 AM, Nathan Goldbaum 
wrote:

> I'm interested in this, but was never able to dive in to the lengthy
> discussions on this. I'm curious if there is a summary of the current
> state of things somewhere that I could read to catch up.


Old proposal, original implementation:
https://github.com/numpy/numpy/blob/master/doc/neps/ufunc-overrides.rst

Main issue for discussion: https://github.com/numpy/numpy/issues/5844. That
really needs a summary, but I'm not sure there's an up-to-date one.

Ralf



> On Sunday, November 6, 2016, Charles R Harris 
> wrote:
>
>>
>>
>> On Sun, Nov 6, 2016 at 11:44 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> For those interested in continuing the __numpy_ufunc__ saga, there is a pull
>>> request enabling it . Likely
>>> we will want to make some changes up front before merging that, so some
>>> discussion is in order.
>>>
>>>
>> As a first order of business, let's decide whether to remove the index
>> and rename `__numpy_ufunc__`. The motivation for this is discussed in issue
>> #5986. 
>> If we decide positive on that (I'm in favor), I would be happy with the
>> proposed name `__array_ufunc__`, although something more descriptive like
>> `__handle_ufunc__` might be better. This is a wonderful opportunity for
>> bike shedding for those so inclined ;)
>>
>> Chuck
>>
>>
> ___
> 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] Numpy 1.12.x branched

[Matti Picus]

On 07/11/16 10:19, numpy-discussion-requ...@scipy.org wrote:

Date: Sun, 06 Nov 2016 17:56:12 +0100
From: Sebastian Berg
To:numpy-discussion@scipy.org
Subject: Re: [Numpy-discussion] Numpy 1.12.x branched
Message-ID:<1478451372.3875.5.ca...@sipsolutions.net>
Content-Type: text/plain; charset="utf-8"

On Sa, 2016-11-05 at 17:04 -0600, Charles R Harris wrote:

>Hi All,
>
>Numpy 1.12.x has been branched and the 1.13 development branch is
>open. It would be helpful if folks could review the release notes as
>it is likely I've missed something.? I'd like to make the first beta
>release in a couple of days.
>

Very cool, thanks for all the hard work!

- Sebastian



>Chuck
Thanks for managing this. I don't know where, but it would be nice if 
the release notes could mention the PyPy support - we are down to only a 
few failures on the test suite, the only real oustanding issue is nditer 
using UPDATEIFCOPY which depends on refcounting semantics to trigger the 
copy. Other than that PyPy + NumPy 1.12 is a working thing, we (PyPy 
devs) will soon try to make it work faster :).

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

Re: [Numpy-discussion] __numpy_ufunc__

[Charles R Harris]

On Mon, Nov 7, 2016 at 1:08 AM, Ralf Gommers  wrote:

>
>
> On Mon, Nov 7, 2016 at 9:10 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Sun, Nov 6, 2016 at 11:44 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> For those interested in continuing the __numpy_ufunc__ saga, there is a pull
>>> request enabling it . Likely
>>> we will want to make some changes up front before merging that, so some
>>> discussion is in order.
>>>
>>>
>> As a first order of business, let's decide whether to remove the index
>> and rename `__numpy_ufunc__`. The motivation for this is discussed in issue
>> #5986. 
>> If we decide positive on that (I'm in favor),
>>
>
> It seems like everyone on that issue is in favor or at least +0. So +1
> from me too.
>
>
>> I would be happy with the proposed name `__array_ufunc__`, although
>> something more descriptive like `__handle_ufunc__` might be better.
>>
>
>
>
>> This is a wonderful opportunity for bike shedding for those so inclined ;)
>>
>
Let me try to break things down an bit.


*Uncontroversial*


   - Rename __numpy_ufunc__ to __array_ufunc__
   - Remove index
   - Out is always a tuple


I think this much is useful even if nothing else is done.

*Goals*


   - Deprecate __array_priority__
   - Ufuncs should succeed or error, never return NotImplemented
   - Add __array_ufunc__ stub to ndarray.


I don't think these are controversial either, but they are longer term
except possibly the last. Note that never returning NotImplemented
disentangles ufuncs from ndarray binops, which I think is a good thing.

*Binops*


Here we come to the crux of the last arguments. The functions used for
binops can currently be set dynamically, the method that is currently used
to set them when the ufunc module is loaded. I think we want to do away
with that at some point and fix a set of ufuncs with which they are
implemented. This allows folks to overide the binop behavior using
__array_ufunc__. I think that is mostly of interest to people who are
subclassing ndarray and with that restriction doesn't bother me except that
it entangles ufuncs with binops. However, what I'd like to see as well is
an opt out for objects that don't care about ufuncs, but want to override
the python numeric operators, something simple like `__me_me_me__`, or,
more seriously, `__array_opt_out__`  that will only come into play if the
defining object is on the right hand side of an instance of ndarray. In
that case the binop would return NotImplemented so as to defer to the
Python machinery.  Note that  __array_priority__ is currently (ab)used for
this.

*Numpy scalars*

Numpy scalars default to the corresponding PyArray_Type or
PyGenericArrType_Type unless both arguments can be converted to the same c
type as the calling scalar, so I don't think there is a problem there. Note
that they do check _array_priority_ before trying to convert unknown
objects to array scalars in a fallback case.

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

Re: [Numpy-discussion] Numpy 1.12.x branched

[Charles R Harris]

On Mon, Nov 7, 2016 at 11:32 AM, Matti Picus  wrote:

> On 07/11/16 10:19, numpy-discussion-requ...@scipy.org wrote:
>
>> Date: Sun, 06 Nov 2016 17:56:12 +0100
>> From: Sebastian Berg
>> To:numpy-discussion@scipy.org
>> Subject: Re: [Numpy-discussion] Numpy 1.12.x branched
>> Message-ID:<1478451372.3875.5.ca...@sipsolutions.net>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Sa, 2016-11-05 at 17:04 -0600, Charles R Harris wrote:
>>
>>> >Hi All,
>>> >
>>> >Numpy 1.12.x has been branched and the 1.13 development branch is
>>> >open. It would be helpful if folks could review the release notes as
>>> >it is likely I've missed something.? I'd like to make the first beta
>>> >release in a couple of days.
>>> >
>>>
>> Very cool, thanks for all the hard work!
>>
>> - Sebastian
>>
>>
>> >Chuck
>>>
>> Thanks for managing this. I don't know where, but it would be nice if the
> release notes could mention the PyPy support - we are down to only a few
> failures on the test suite, the only real oustanding issue is nditer using
> UPDATEIFCOPY which depends on refcounting semantics to trigger the copy.
> Other than that PyPy + NumPy 1.12 is a working thing, we (PyPy devs) will
> soon try to make it work faster :).
>

A PR updating the release notes would be welcome. This might be one of the
highlights for those interested in PyPy.

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