[Numpy-discussion] Change definition of complex sign (and use it in copysign)
Hi All, A long-standing, small wart in numpy has been that the definition of sign for complex numbers is really useless (`np.sign(z)` gives the sign of the real component, unless that is zero, in which case it gives the sign of the imaginary component, in both cases as a complex number with zero imaginary part). Useless enough, in fact, that in the Array API it is suggested [1] that sign should return `z / |z|` (a definition consistent with those of reals, giving the direction in the complex plane). The question then becomes what to do. My suggestion - see https://github.com/numpy/numpy/pull/25441 - is to adapt the Array API definition for numpy 2.0, with the logic that if we don't change it in 2.0, when will we? Implementing it, I found no real test failures except one for `np.geomspace`, where it turned out that to correct the failure, the new definition substantially simplified the implementation. Furthermore, with the redefinition, it has become possible to extend ``np.copysign(x1, x2)`` to complex numbers, since it can now generally return ``|x1| * sign(x2)`` with the sign as defined above (with no special treatment for zero). Anyway, to me the main question would be whether this would break any workflows (though it is hard to see how it could, given that the previous definition was really rather useless...). Thanks, https://github.com/data-apis/array-api/pull/556, Marten [1] https://data-apis.org/array-api/latest/API_specification/generated/array_api.sign.html (and https://github.com/data-apis/array-api/pull/556, which has links to previous discussion) ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: ENH: ignore_nan parameter in np.average
I think the logical choice would be to allow a weighted average in the nan-functions, not to change `np.average`. In particular, I think it is bad API to add options for such exclusions; we have another open issue about infinitiy in the data, which leads to nan even with weight 0 (because `0*inf = nan`; see https://github.com/numpy/numpy/issues/25362); should that gets its own option? It also seems a case that is *very* easily solved by the user with a wrapper, or, as noted in the issue, with creating a mask and using `np.ma.average`. Or, indeed, just calculating `np.nansum(data * weight, axis=...) / np.nansum(weight, axis=...)` Anyway, my 2ยข would be to think whether we actually need this addition, and, if we decide we do, to see how this would fit with the `nan*` functions. This might mean introducing `np.nanaverage` since the Array API is fairly clear that `mean()` should be unweighted. Indeed, if written such that the `NaN` skipping is done after data and weight are multiplied, that would solve https://github.com/numpy/numpy/issues/25362 too. -- Marten p.s. My other reason for hesitation is that generally when you get a NaN, something is actually wrong... > I would love some input on this issue, > https://github.com/numpy/numpy/issues/21375. > > I have created a draft PR which I believe resolves it, > https://github.com/numpy/numpy/pull/25474. Decided to go with adding > ignore_nan to np.average rather than adding weights to np.nanmean as it > seemed logical and was the path of least resistance. > Please let me know what you think! > -awestm ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: Bumping CPU baseline to x86-64-v2
Hi Sayed, I'm a bit confused: does your suggested change mean that prre-2009 processors won't work at all, or that no use will be made of the (little) acceleration that they provided? The latter seems fine, but not working at all seems rather bad. Though I'd think that for any old processors one can just fall back to the standard `libm` implementations. All the best, Marten ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com