MAINT: Merge together the unary and binary type resolvers #12928
Conversation
This merges `PyUFunc_SimpleUnaryOperationTypeResolver` and `PyUFunc_SimpleBinaryOperationTypeResolver` These are almost identical, save for using `ResultType` vs simply forcing a byte order. This comes at the cost of a handful of branches, which should be insignifcant compared to the rest of the ufunc overhead.
| return PyUFunc_DefaultTypeResolver(ufunc, casting, operands, | ||
| type_tup, out_dtypes); | ||
| } | ||
|
|
||
| if (type_tup == NULL) { | ||
| /* Input types are the result type */ | ||
| out_dtypes[0] = PyArray_ResultType(2, operands, 0, NULL); | ||
| /* PyArray_ResultType forgets to force a byte order when n == 1 */ |
There was a problem hiding this comment.
This has the worrying consequence that np.result_type(dt) and np.positive(np.empty((), dt)).dtype give different results - but not something this patch affects
There was a problem hiding this comment.
Ah, I guess the strange thing seems to me that np.result_type for a single item is no-op, while it is not for binary ones. Could consider changing that for result type, but not directly important here.
| return PyUFunc_DefaultTypeResolver(ufunc, casting, operands, | ||
| type_tup, out_dtypes); | ||
| } | ||
|
|
||
| if (type_tup == NULL) { | ||
| /* Input types are the result type */ | ||
| out_dtypes[0] = PyArray_ResultType(2, operands, 0, NULL); | ||
| /* PyArray_ResultType forgets to force a byte order when n == 1 */ |
There was a problem hiding this comment.
Ah, I guess the strange thing seems to me that np.result_type for a single item is no-op, while it is not for binary ones. Could consider changing that for result type, but not directly important here.
| @@ -12,6 +12,8 @@ | |||
| #define _MULTIARRAYMODULE | |||
| #define NPY_NO_DEPRECATED_API NPY_API_VERSION | |||
|
|
|||
| #include <stdbool.h> | |||
There was a problem hiding this comment.
Guess we can use that more now with C99.
|
OK, putting this in, thanks Eric! |
This merges
PyUFunc_SimpleUnaryOperationTypeResolverandPyUFunc_SimpleBinaryOperationTypeResolverThese are almost identical, save for using
ResultTypevs simply forcing a byte order.This comes at the cost of a handful of branches, which should be insignifcant compared to the rest of the ufunc overhead.
Spin off from #7876, where I was about to add
PyUFunc_SimpleTernaryOperationTypeResolverand thought better of it.