dtypes and array scalars #13
Conversation
Try to duck-type NumPy, only without array scalars, so that
* dtype('float32').type --> np.float32
and
* np.float32(3) --> array(3.0, dtype='float32)
IOW, the attempt is to only have zero-dim arrays (we have them anyway)
and have them everywhere where NumPy creates a scalar.
|
I guess there's a lot of other methods on numpy dtypes that people might care about (although none of them are guaranteed by the array API FWIW). There's also the extensive |
There was a problem hiding this comment.
This looks like a good approach overall. I think it will work well enough. It would be useful to add the main properties that are supported in a docstring (probably generic, because that's where the functionality is).
There's also the extensive
__eq__that is defined on numpy dtypes (see also data-apis/array-api#582).
__eq__ would indeed be good to support as much as possible.
NumPy also has the distinction between dtype classes and instances (e.g.,
np.float64vs.np.dtype('float64'), which I personally find annoying and I don't know if it needs to exist here.
Agreed it's annoying, but it's probably easier to keep that here. The correspondence in this PR isn't perfect (see example below), but close enough.
>>> type(tnp.dtype('float64'))
<class 'torch_np._dtypes.dtype'>
>>> type(np.dtype('float64'))
<class 'numpy.dtype[float64]'>| arg1 = dtype(arg1).type | ||
| if not issubclass_(arg2, _scalar_types.generic): | ||
| arg2 = dtype(arg2).type | ||
| return issubclass(arg1, arg2) |
There was a problem hiding this comment.
This seems to not yet be complete I think? At least from a quick test:
In [25]: tnp.issubdtype(tnp.float32, tnp.inexact)
Out[25]: False
In [26]: np.issubdtype(np.float32, np.inexact)
Out[26]: True| @@ -183,6 +181,23 @@ def is_integer(dtyp): | |||
| return dtyp.typecode in typecodes['AllInteger'] | |||
|
|
|||
|
|
|||
|
|
|||
| def issubclass_(arg, klass): | |||
There was a problem hiding this comment.
This goes on my list of functions to deprecate and remove in NumPy 2.0 ...
There was a problem hiding this comment.
This one is easy enough so may as well leave it here now. I'd say let's not bother with issubsctype, obj2sctype, etc., those definitely all need to go from NumPy.
|
Apparently merging a PR and deleting the PR branch closes the PR to this branch. Which is not unreasonable, now that I think about it. Let's continue in gh-12, which is the same PR against main. |
identical to gh-12, only sent to the reductions branch, as per #12 (comment)