summaryrefslogtreecommitdiff
path: root/numpy/array_api/_elementwise_functions.py
diff options
context:
space:
mode:
authorSebastian Berg <sebastian@sipsolutions.net>2021-11-29 13:51:08 -0600
committerSebastian Berg <sebastian@sipsolutions.net>2021-11-30 12:26:31 -0600
commit48d0677ed716d59e98e6b0e7a01b193cb9fc0a71 (patch)
treeb8d7a089802b0d36c52ff186fd20c65bee5a2777 /numpy/array_api/_elementwise_functions.py
parent258ce2523ffad99be69afbd421d540086cb6bf61 (diff)
downloadnumpy-48d0677ed716d59e98e6b0e7a01b193cb9fc0a71.tar.gz
BUG: Fix reduce promotion with out argument
This fixes promotion for reductions if `out=` is passed. The Outputs dtype should take part in promotion here. Due to value-based casting/promotion it does not work to pass on `out` to the legacy-promoter, because `out` may be scalar and the legacy type resolver would (de-facto) ignore its precision. So in that case, we keep using the old logic of making `out=` equivalent to an implicit `dtype=out.dtype`. This is not quite correct in theory, because :: arr = np.full(5, 2**25-1, dtype=np.int64) np.multiply.preduce(arr, out=np.zeros((), dtype=float32)) Should naturally use float64 (as the promotion result for int64 and float32), which gives slightly different results. This may be up for debate, but in general `out=` has normally no influence on the result of ufuncs/functions. Reduce-like operations do feel somewhat special in this regard, but it is unclear to me that they should be. This ensures the operation is compatible with the output argument (i.e. minimal precision), which was intermittendly broken for the "legacy" dtype-resolution paths. Note that we ignore the multiple/add special "upcast" paths here and that it may make sense to override this in the future if `initial=` is passed (normally `out=` should have no direct influence on the operation precision). Closes gh-20455
Diffstat (limited to 'numpy/array_api/_elementwise_functions.py')
0 files changed, 0 insertions, 0 deletions