1x1 + 2x2 is one issue with that. The way numpy handles 1D @ 2D is another (which is solved by np.matrix).
array
xnd.matrix with 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.
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 MaskedArrays 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.
[Sameer Deshmukh] @ralf.gommers I think this message states that the latest ndtypes does not need refcounting. Let me try updating this on the ruby side and then I can update you on what is going on as of now.
An update on reference counted types and the history:
The Numba team was concerned about having reference counted types in libndtypes. However, the more I looked at it, I can't see any harm. For example, ...
t = ndt_string(ctx);
ndt_del(t).... is now just:
t = ndt_string(ctx);
ndt_decref(t);So refcounting is all internal to libndtypes and has nothing to do with Python refcounting.
It is all implemented in the latest libndtypes.
One implementation detail: An ndt_t * is now always const except for the refcnt field. ndt_decref(const ndt_t *) follows the convention in the Linux kernel, where kfree() takes a const void *.
The convention in the Linux kernel has been the source of some controversy. I understand some of the counter arguments, but on the whole I think it's a good idea. More here:
const *, which has Linus' endorsement but might lead to raised eyebrows elsewhere.
[Stefan Krah] I've implemented flexible ND arrays, which are more versatile than the offset-based var dimensions.
These are needed for quirky formats like GeoSON.
The trade-off is that they are not in a single memory block.
You can now assign subarrays of different sizes:
>>>
>>> x = xnd([[0], [1, 2]], type="array of array of int64")
>>> x
xnd([[0], [1, 2]], type='array of array of int64')
>>> x[0] = [1000, 2000, 3000]
>>> x
xnd([[1000, 2000, 3000], [1, 2]], type='array of array of int64')
>>>