diff options
author | Sebastian Berg <sebastian@sipsolutions.net> | 2021-11-29 13:51:08 -0600 |
---|---|---|
committer | Sebastian Berg <sebastian@sipsolutions.net> | 2021-11-30 12:26:31 -0600 |
commit | 48d0677ed716d59e98e6b0e7a01b193cb9fc0a71 (patch) | |
tree | b8d7a089802b0d36c52ff186fd20c65bee5a2777 /numpy/array_api/_elementwise_functions.py | |
parent | 258ce2523ffad99be69afbd421d540086cb6bf61 (diff) | |
download | numpy-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