Fixing QuadPrecision scalar dtype exposure
#234
Conversation
|
@seberg also here, yesterday I saw the email of new protocol (and replied too but might be in moderation right now) |
| quad_ld = QuadPrecision("1e100", backend="longdouble") | ||
| quad_sleef = QuadPrecision("1e100", backend="sleef") | ||
| assert quad_ld.dtype == QuadPrecDType(backend='longdouble') | ||
| assert np.dtype(quad_ld) == QuadPrecDType(backend='longdouble') |
There was a problem hiding this comment.
Of course scalar.dtype should work and I guess since you are parametric you have to make it work.
Butt the protocol is the exact opposite of this assert. It specifically wants to disable this in the future because it makes no sense to say np.ones(..., dtype=scalar), the user should write dtype=scalar.dtype.
So in other words: The attribute is right, the __numpy_dtype__ protocol is just unrelated.
There was a problem hiding this comment.
oh I see, so we don't have to implement __numpy_dtype__
I misinterpret that, I thought in future had to expose both .dtype and __numpy_dtype__
In current scenarios atleast for testing, I just set np.longdouble = QuadPrecision #(scalar) as we have different names for scalar and dtype and this works correctly.
There was a problem hiding this comment.
What we could try to have is a function to map from the scalar type to the DType class cleanly, I guess (this exists in C, but not Python).
I used to want np.dtype[scalar_type] for this, but while what typing does is conceptually the same, it's not compatible :(.
There was a problem hiding this comment.
We can always add np.dtype.from_scalar.
|
This all seems correct to me as-is. I'd say merge this now and hold off on |
Just be overly clear onc emore: It isn't even correct to implement it! Scalars should not be convertible to dtypes via that mechanism. |
Thanks! I haven't been following closely. So this PR is fine as-is. |
|
Merging this in! |
3 participants
closes #233