Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

2017-11-04 Thread Ben Rowland


> On 2 Nov 2017, at 22:39, Marten van Kerkwijk  
> wrote:
> 
> I guess my argument boils down to it being better to state that a
> function only accepts arrays and happily let it break on, e.g.,
> matrix, than use `asarray` to make a matrix into an array even though
> it really isn’t.

I would support this attitude, the user can always call `asarray` when passing 
their
data into the function if necessary, then they know upfront what the 
consequences
will be.

For my own ndarray subclass, I want it to behave exactly as a standard ndarray,
but in addition I add some metadata and some functions that act on that, for
example an affine transform and functions to convert between coordinate systems.
The current numpy system of overriding __array_wrap__, __array_finalize__ and
__new__ is great to allow the subclass and metadata to propagate through most
basic operations.

The problem is that many functions using `asarray` strip out all of this 
metadata
and return a bare ndarray. My current solution is to implement an `inherit` 
method
on my subclass which converts an ndarray and copies back all the metadata,
which often looks like this:
spec_data = data.inherit(np.fft.fft(data))

To use composition instead of inheritance would require me to forward every part
of the ndarray API as is, which would be a great deal of work which in nearly
every case would only achieve the same results as replacing `asarray` by
`asanyarray` in various library functions. I don’t want to change the behaviour 
of
the existing class, just to add some data and methods, and I can’t imagine I am
alone in that.

Ben

> 
> I do like the dtype ideas, but think I'd agree they're likely to come
> with their own problems. But just making new numerical types possible
> is interesting.
> 
> -- Marten
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

2017-11-04 Thread Marten van Kerkwijk
Hi Ben,

You just summarized excellently why I'm on a quest to change `asarray`
to `asanyarray` within numy (or at least add a `subok` keyword for
things like `broadcast_arrays`)! Obviously, this covers only ndarray
subclasses, not duck types, though I guess in principle one could use
the ABC registration mechanism mentioned above to let those types pass
through.

Returning to the original topic of the thread, with `__array_ufunc__`
it now is even easier to keep track of your meta data for ufuncs, and
has become possible to massage input data before the ufunc is called
(rather than just the output).

All the best,

Marten
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion