On Tue, Jun 21, 2011 at 12:46 PM, Darren Dale <[email protected]> wrote:
> On Tue, Jun 21, 2011 at 2:28 PM, Charles R Harris > <[email protected]> wrote: > > > > > > On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe <[email protected]> wrote: > >> > >> On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris > >> <[email protected]> wrote: > >>> > >>> > >>> On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe <[email protected]> > 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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
