> The costs I worry about are performance and increased maintenance burden for > the regular, no-nan case. For instance, the "obvious" way to implement a > nan-omitting sum would be to check inside a loop whether any given element > was nan, thus slowing down the regular case (e.g., by breaking > vectorization). To avoid this one has to be careful, thus making code harder > to write, more fragile, and more difficult to maintain (analogous to -- but > worse than -- tracking floating point errors).
I'm not sure I understand your objection here. Consider the way `nansum` is currently implemented: https://github.com/numpy/numpy/blob/76e91189b23d4e0afc34130e95f4f460a3d57d95/numpy/lib/_nanfunctions_impl.py#L725. > a, mask = _replace_nan(a, 0) > return np.sum(a, axis=axis, dtype=dtype, out=out, keepdims=keepdims, > initial=initial, where=where) The `ignore_nan` version would simply do the same thing, but inside the body of `numpy.sum`. Or it can call `np.sum` with `where=~np.isnan(a) if where is None else ~np.isnan(a) & where` (i.e., combining with any mask the user supplies). I object to the approach of complicating the array ontology, for the reasons described here: https://github.com/data-apis/array-api/issues/621#issuecomment-3433986363. _______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
