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? <snip> Chuck
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
