diff options
author | Sebastian Berg <sebastian@sipsolutions.net> | 2021-05-03 13:07:39 -0500 |
---|---|---|
committer | Sebastian Berg <sebastian@sipsolutions.net> | 2021-05-03 13:07:39 -0500 |
commit | 8d4828f8da96187a9263fd1573ee74ced6a3eedb (patch) | |
tree | 4994c8a6f8fab16a6c0aa62b5c098fda8f8bd907 /numpy/array_api | |
parent | 006c199d2ac924ab1d35074d63b47aea1420cd90 (diff) | |
download | numpy-8d4828f8da96187a9263fd1573ee74ced6a3eedb.tar.gz |
Undo resolver changes and instead fall back to "old logic"
If only output dtypes are provided, we add the additional step
in the ufunc type resolver of converting a signature of the format::
(None,) * nin + (DType,) * nout
into::
(DType,) * (nin + nout)
And try searching for a matching loop again. The advantage of this
is that IF the ufunc has mixed-type inputs, we have a fighting
chance of finding a good loop for `dtype=DType`.
Further, future `promoters` could refine such logic, while at the
same time, we do not need to use completely different code paths
for `signature=...` and `dtype=...`.
The rare downside is that we might pick a `dd->d` loop when a
`dl->d` loop would do (SciPy has such ufuncs).
The up-side is, that before, using `dtype=...` was not even possible
for functions with non-homogenous loops like `np.ldexp`.
The future will hopefully see more precise promotion logic, and some
of the more surprising paths simply deprecated...
Diffstat (limited to 'numpy/array_api')
0 files changed, 0 insertions, 0 deletions