np.matrix() + np.matrix([[1, 2], [3, 4]])works, which is not good
1x1 + 2x2is one issue with that. The way numpy handles
1D @ 2Dis another (which is solved by np.matrix).
xnd.matrixwith a constructor that only allows construction of values that match this pattern.
[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.
absmethod - only the function version
df.strwhich hold functions for datetime and string operations respectively
cls=type(args)by default, this would ensure that the method-call versions returned the type of the instance
xnd.array.ufuncis a bit of a mouthful ¯_(ツ)_/¯
[Hameer Abbasi] Then
xnd.array is a valid subclass of
xnd.xnd, but this doesn’t hold for
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.