[Numpy-discussion] replacing the mechanism for dispatching ufuncs

Charles R Harris charlesr.harris@gmail....
Tue Jun 21 13:28:11 CDT 2011

On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe <mwwiebe@gmail.com> wrote:

> On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris <
> charlesr.harris@gmail.com> wrote:
>> On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe <mwwiebe@gmail.com> wrote:
>>> NumPy has a mechanism built in to allow subclasses to adjust or override
>>> aspects of the ufunc behavior. While this goal is important, this mechanism
>>> only allows for very limited customization, making for instance the masked
>>> arrays unable to work with the native ufuncs in a full and proper way. I
>>> would like to deprecate the current mechanism, in particular
>>> __array_prepare__ and __array_wrap__, and introduce a new method I will
>>> describe below. If you've ever used these mechanisms, please review this
>>> design to see if it meets your needs.
>> The current approach is at a dead end, so something better needs to be
>> done.
>>> Any class type which would like to override its behavior in ufuncs would
>>> define a method called _numpy_ufunc_, and optionally an attribute
>>> __array_priority__ as can already be done. The class which wins the priority
>>> battle gets its _numpy_ufunc_ function called as follows:
>>> return arr._numpy_ufunc_(current_ufunc, *args, **kwargs)
>>> To support this overloading, the ufunc would get a new support method,
>>> result_type, and there would be a new global function, broadcast_empty_like.
>>> The function ufunc.empty_like behaves like the global np.result_type, but
>>> produces the output type or a tuple of output types specific to the ufunc,
>>> which may follow a different convention than regular arithmetic type
>>> promotion. This allows for a class to create an output array of the correct
>>> type to pass to the ufunc if it needs to be different than the default.
>>> The function broadcast_empty_like is just like empty_like, but takes a
>>> list or tuple of arrays which are to be broadcast together for producing the
>>> output, instead of just one.
>> How does the ufunc get called so it doesn't get caught in an endless loop?
>> I like the proposed method if it can also be used for classes that don't
>> subclass ndarray. Masked array, for instance, should probably not subclass
>> ndarray.
> The function being called needs to ensure this, either by extracting a raw
> ndarray from instances of its class, or adding a 'subok = False' parameter
> to the kwargs. Supporting objects that aren't ndarray subclasses is one of
> the purposes for this approach, and neither of my two example cases
> subclassed ndarray.
Sounds good. Many of the current uses of __array_wrap__ that I am aware of
are in the wrappers in the linalg module and don't go through the ufunc
machinery. How would that be handled?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110621/19e2f1d8/attachment.html 

More information about the NumPy-Discussion mailing list