[Numpy-discussion] replacing the mechanism for dispatching ufuncs

[Charles R Harris]

On Tue, Jun 21, 2011 at 12:46 PM, Darren Dale <dsdale24 at gmail.com> wrote:

> On Tue, Jun 21, 2011 at 2:28 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> >>
> >> On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris
> >> <charlesr.harris at gmail.com> wrote:
> >>>
> >>>
> >>> On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe <mwwiebe at 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?
>
> I contributed the __array_prepare__ method a while back so classes
> could raise errors before the array data is modified in place.
> Specifically, I was concerned about units support in my quantities
> package (http://pypi.python.org/pypi/quantities). But I agree that
> this approach is needs to be reconsidered. It would be nice for
> subclasses to have an opportunity to intercept and process the values
> passed to a ufunc on their way in. For example, it would be nice if
> when I did np.cos(1.5 degrees), my subclass could intercept the value
> and pass a new one on to the ufunc machinery that is expressed in
> radians. I thought PJ Eby's generic functions PEP would be a really
>

Link to PEP-3124 <http://tinyurl.com/3brnk6>.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110621/42e7c2aa/attachment.html>