This is getting into implementation details, but... > My suggestion of a nan-as-omit Array API compatible wrapper class would > need them, and so would extending nanfunctions to cover more cases. > Indeed, it would even help the keyword-argument case as it would provide > working implementations. > > Let me also mention again another option, of a wrapper data type which > translates floats with NaN to a floats with nan replaced by an > appropriate constant (identify from reductions by default). > > I think you can't determine an appropriate value without already doing the > nan-omitting calculation? E.g. what replacement value would > you use for `np.mean`?
You're right, this would work for ufuncs, where any custom dtype can register a custom loop or promotors -- which would then replace NaN with the ufunc identity -- but while that is good enough for np.sum, it is not for np.mean, since that also has to count the number of "good" elements to divide by. So, scratch that option! Aside: the example of np.mean is a better one than np.sum to show how "just adding a keyword argument" adds complexity: like above, in np.mean one would have to add the machinery to count the non-nan elements. To give a sense, currently _methods.mean has 30 lines, while nanmean uses 24. (I'm sure the combination would be fewer than 54, as there is room to factor things out, but the main point is not so much that it cannot be done -- though to me the mismash will be inelegant... -- but that the implementation work and maintenance costs are non-negligle and should be weighed against the benefits.) Anyway, will stop opiniating now! -- Marten _______________________________________________ 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]
