Hi, I am creating a custom array type (distributed memory arrays - DistArray) and I am using the __array__ and __array_wrap__ methods and __array_priority__ attribute to get these arrays to work with numpy's ufuncs. Things are working fine when I call a ufunc like this: # This works fine (c comes back as an DistArray) a = DistArray(10) b = DistArray(10) c = np.add(a, b) But, when you pass in an ndarray as the return array, the __array_wrap__ doesn't get called: # Passing in an ndarray as the return array causes __array_wrap__ to not # be called. Thus, you get back an ndarray. d = np.empty_like(a.array) d = np.add(a, b, d) But, the most problematic case is when you try to pass in a DistArray as the return type: # This fails saying that the return array must be an ArrayType d = DistArray(10) d = np.add(a, b, d) The documentation for __array__ and __array_wrap__ describe a very different behavior: 1) The result of the ufunc is assigned to the aray returned by the __array__ method of the return array. 2) The resulting object is then passed to the __array_wrap__ method of that array to be properly wrapped. But, it seems that numpy's ufuncs are not even allowing anything but a full blown ndarray as the return type. Is this a bug (I will then file a bug report)? Has the behavior changed (documentation probably needs to be updated)? I am attaching some sample code that demonstrates the issue for a simple class. Thanks Brian
Brian Granger wrote:
Hi,
I am creating a custom array type (distributed memory arrays - DistArray) and I am using the __array__ and __array_wrap__ methods and __array_priority__ attribute to get these arrays to work with numpy's ufuncs. Things are working fine when I call a ufunc like this:
# This works fine (c comes back as an DistArray) a = DistArray(10) b = DistArray(10) c = np.add(a, b)
But, when you pass in an ndarray as the return array, the __array_wrap__ doesn't get called:
That is true. Currently, the output argument must be an ndarray, because the idea is to save memory. If you have an object that uses __array_wrap__ to channel the output back into your object's memory, then there is no benefit to the output value. It could be possible to allow additional output arguments that are not ndarrays to be syntactic sugar for __array_wrap__, but this has not been done and if the documentation led you to believe that it was possible, then the docs need to be updated. Best regards, -Travis O.
Travis, Thanks. Here is the text from the numpybook that was confusing me:
From section 9.1.2 on ufuncs:
The ufuncs can also all take output arguments. The output will be cast if necessary to the provided output array. If a class with an array method is used for the output, results will be written to the ob ject returned by array . Then, if the class also has an array wrap method, the returned ndarray result will be passed to that method just before passing control back to the caller. I can easily work around this for now though, so it is not a problem. Cheers, Brian On Wed, Apr 2, 2008 at 10:20 AM, Travis E. Oliphant <oliphant@enthought.com> wrote:
Brian Granger wrote:
Hi,
I am creating a custom array type (distributed memory arrays - DistArray) and I am using the __array__ and __array_wrap__ methods and __array_priority__ attribute to get these arrays to work with numpy's ufuncs. Things are working fine when I call a ufunc like this:
# This works fine (c comes back as an DistArray) a = DistArray(10) b = DistArray(10) c = np.add(a, b)
But, when you pass in an ndarray as the return array, the __array_wrap__ doesn't get called:
That is true. Currently, the output argument must be an ndarray, because the idea is to save memory.
If you have an object that uses __array_wrap__ to channel the output back into your object's memory, then there is no benefit to the output value.
It could be possible to allow additional output arguments that are not ndarrays to be syntactic sugar for __array_wrap__, but this has not been done and if the documentation led you to believe that it was possible, then the docs need to be updated.
Best regards,
-Travis O.
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (2)
-
Brian Granger -
Travis E. Oliphant