x = np.asarray(x)
. subclasses gone
numbers
heirarchy is a bit misguided IMO)
np.matrix([1]) + np.matrix([[1, 2], [3, 4]])
works, which is not good
1x1 + 2x2
is one issue with that. The way numpy handles 1D @ 2D
is another (which is solved by np.matrix).
array
[Stefan Krah] We could be fancy and check for the narrowest type among the input arguments and return that, but this sort of thing slows down small array operations.
I'm pretty interested in keeping the overhead as minimal as possible so if that means having to specify the type (cls
) then so be it however perhaps we can get the best of both worlds by skipping the type guessing heuristics in the case that cls is not None
?
[Pearu Peterson] Similarly for multiple argument cases, the first argument type defines the type of the output objects (default behavior).
I'd be fine with this choice - so long as it's consistent it can be accomodated. I guess the other option would be return the type of the first common base but I assume that would have a much larger performance impact.
abs
method - only the function version
df.dt
, df.str
which hold functions for datetime and string operations respectively
cls=type(args[0])
by default, this would ensure that the method-call versions returned the type of the instance
xnd.array.ufunc
is a bit of a mouthful ¯_(ツ)_/¯
[Hameer Abbasi] Then xnd.array
is a valid subclass of xnd.xnd
, but this doesn’t hold for MaskedArray
s or matrix
objects.
astropy.Quantity
is valid sometimes and sometimes errors, assuming consistency of units and no conversion. If inconsistent units are supplied, it violates Liskov in this form.
If we have a much more relaxed definition, such that the dtype
and the shape
have to be consistent (type
in xnd-speak), and errors are allowed, then MaskedArray and unit become valid.