-
-
Notifications
You must be signed in to change notification settings - Fork 13
BUG: Fixing reduction logical ufuncs #220
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
base: main
Are you sure you want to change the base?
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -200,7 +200,7 @@ create_quad_comparison_ufunc(PyObject *numpy, const char *ufunc_name) | |
| return -1; | ||
| } | ||
|
|
||
| PyObject *DTypes = PyTuple_Pack(3, &PyArrayDescr_Type, &PyArrayDescr_Type, &PyArray_BoolDType); | ||
| PyObject *DTypes = PyTuple_Pack(3, Py_None, Py_None, Py_None); | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @seberg this has performance implications, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It doesn't change things really. The problem with this (but also the old version) is mostly that it doesn't define an order... In general, I think it may be best to just not worry about performance at all, since we cache promotion results. The problem then being just that there isn't really a well defined order for multiple similar promoters (which is probably fine in practice, except that I think NumPy rejects it for now). (I.e. maybe for promoters it should be fine to say "yeah, just try it no matter what DTypes come in") There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @SwayamInSync ideally, you probably just register it twice, once with the first being quaddtype and once with the second. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
You mean registering promoter twice? I tried this regiserting the loop, it worked but undo because of code duplication. |
||
| if (DTypes == 0) { | ||
| Py_DECREF(promoter_capsule); | ||
| return -1; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really understand this comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should improve this comment, basically saying the runtime warnings we used to get often casting is the reason.
Casting from quad NaN or inf to double, etc Instead if we just catch and return for example in this case if we catch NaN and return NP_True then there will be no warnings otherwise that part will go through casting and leads to warnings.
I tested this but revert to original with just comment. Often different ops use casting in one way or another so when fixing that, knowing this information might be helpful