summaryrefslogtreecommitdiff
path: root/numpy/lib/nanfunctions.py
diff options
context:
space:
mode:
authorSebastian Berg <sebastian@sipsolutions.net>2021-05-03 13:07:39 -0500
committerSebastian Berg <sebastian@sipsolutions.net>2021-05-03 13:07:39 -0500
commit8d4828f8da96187a9263fd1573ee74ced6a3eedb (patch)
tree4994c8a6f8fab16a6c0aa62b5c098fda8f8bd907 /numpy/lib/nanfunctions.py
parent006c199d2ac924ab1d35074d63b47aea1420cd90 (diff)
downloadnumpy-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/lib/nanfunctions.py')
0 files changed, 0 insertions, 0 deletions