-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Diff low precision ints #45609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Diff low precision ints #45609
Conversation
@lukemanley can you add a whatsnew note in 1.5 cc @jbrockmendel @rhshadrach any objections? |
im ambivalent. being consistent with shift would be nice, but a) i dont like the extra copy this makes and b) users using small-itemsize dtypes probably want small-itemsize results |
Everything being equal, I'd rather see shift support lower precision dtypes, but perhaps that isn't currently feasible? I haven't looked. |
Agreed, the extra copy is unfortunate.
I think there are a number of examples beyond
|
can you merge master here |
Merged main, errors look unrelated |
I think the consensus is that we'd like to see better support for lower precision ops. We aren't going to get there all at once, so there will be inconsistencies in support for quite some time. And we certainly aren't going to get there by taking ops that do support lower precision and removing that support for the purpose of consistency. For that reason, I'm -1 here. |
so generally I agree with you. but this little inconsistency is troubling. wouldn't it be better to make a systematic change to support this rather than doing it piecemeal? |
If this were possible to do all in one go, I'm all for it. But I don't think that is likely - there are a ton of ops, including indexing, that need changed. |
I'm happy to close this one if the preference is to keep the current behavior. If the current behavior is preferred,
|
ok i guess let's close this and work on making more functions preserve dtypes. |
Submitting this PR as a potential option. This changes the diff method to upcast int8/int16 to float64 similar to shift and other methods. It avoids the int8/int16 > float64 cython issue referenced in the code by doing an initial cast from int8/int16 > int32. Note the tests were updated to now expect float64 in a few cases.
If the existing behavior is preferred, I'm happy to close this. I thought the consistency and fewer special cases elsewhere might be worth the change here.