[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: Change definition of complex sign (and use it in copysign)
In my opinion, with the caveat that anyone that asks for the sign of a complex number gets what they deserve, this seems about as useful a definition as any. On Fri, Dec 22, 2023 at 8:23 AM wrote: > 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: ndbeck...@gmail.com > -- *Those who don't understand recursion are doomed to repeat it* ___ 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: Change definition of complex sign (and use it in copysign)
On Fri, 22 Dec 2023 at 13:25, wrote: > > 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...). SymPy already defines sign(z) as z/abs(z) (with sign(0) = 0) as proposed here. Checking this I see that the current mismatch causes a bug when SymPy's lambdify function is used to evaluate the sign function with NumPy: In [12]: sign(z).subs(z, 1+1j) Out[12]: 0.707106781186548 + 0.707106781186548⋅ⅈ In [13]: lambdify(z, sign(z))(1+1j) # uses numpy Out[13]: (1+0j) The proposed change to NumPy's sign function would fix this bug. -- Oscar ___ 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] updated 2.0-dev nightlies, including macOS Accelerate wheels
Hi all, We had some issues with nightlies, the macOS, Linux aarch64 and PyPy ones were about a month out of date. That is fixed now, new nightlies for all supported platforms are up on https://anaconda.org/scientific-python-nightly-wheels/numpy. Note that a lot changed in `main` over the last month, so if you see lots of failures in pre-release CI jobs of downstream packages, getting all of those changes at the same time will be why. The 2.0 migration guide should be mostly up to date, and covers the most important changes: https://numpy.org/devdocs/numpy_2_0_migration_guide.html. In addition, we have new wheels for arm64 macOS >=14.0 which use the new Apple Accelerate rather than OpenBLAS. They're ~3x smaller and linalg operations are significantly faster as a result. Cheers, Ralf ___ 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] Fixing definition of reduceat for Numpy 2.0?
Hi folks, I don't follow numpy development in much detail these days but I see that there is a 2.0 release planned soon. Would this be an opportunity to change the behaviour of 'reduceat'? This issue has been open in some form since 2006! https://github.com/numpy/numpy/issues/834 The current behaviour was originally inherited from Numeric, and makes reduceat often unusable in practice, even where it should be the perfect, concise, efficient solution. But it has been impossible to change it without breaking compatibіlity with existing code. As a result, horrible hacks are needed instead, e.g. my answer here: https://stackoverflow.com/questions/57694003 Is this something that could finally be fixed in 2.0? Martin ___ 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: Fixing definition of reduceat for Numpy 2.0?
On Fri, Dec 22, 2023 at 12:34 PM Martin Ling wrote: > Hi folks, > > I don't follow numpy development in much detail these days but I see > that there is a 2.0 release planned soon. > > Would this be an opportunity to change the behaviour of 'reduceat'? > > This issue has been open in some form since 2006! > https://github.com/numpy/numpy/issues/834 > > The current behaviour was originally inherited from Numeric, and makes > reduceat often unusable in practice, even where it should be the > perfect, concise, efficient solution. But it has been impossible to > change it without breaking compatibіlity with existing code. > > As a result, horrible hacks are needed instead, e.g. my answer here: > https://stackoverflow.com/questions/57694003 > > Is this something that could finally be fixed in 2.0? The reduceat API is certainly problematic, but I don't think fixing it is really a NumPy 2.0 thing. As discussed in that issue, the right way to fix that is to add a new API with the correct behavior, and then we can think about deprecating (and maybe eventually removing) the current reduceat method. If the new reducebins() method were available, I would say removing reduceat() would be appropriate to consider for NumPy 2, but we don't have the new method with fixed behavior yet, which is the bigger blocker. > > > Martin > ___ > 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: sho...@gmail.com > ___ 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: Fixing definition of reduceat for Numpy 2.0?
Hi Martin, I agree it is a long-standing issue, and I was reminded of it by your comment. I have a draft PR at https://github.com/numpy/numpy/pull/25476 that does not change the old behaviour, but allows you to pass in a start-stop array which behaves more sensibly (exact API TBD). Please have a look! Marten Martin Ling writes: > Hi folks, > > I don't follow numpy development in much detail these days but I see > that there is a 2.0 release planned soon. > > Would this be an opportunity to change the behaviour of 'reduceat'? > > This issue has been open in some form since 2006! > https://github.com/numpy/numpy/issues/834 > > The current behaviour was originally inherited from Numeric, and makes > reduceat often unusable in practice, even where it should be the > perfect, concise, efficient solution. But it has been impossible to > change it without breaking compatibіlity with existing code. > > As a result, horrible hacks are needed instead, e.g. my answer here: > https://stackoverflow.com/questions/57694003 > > Is this something that could finally be fixed in 2.0? > > > Martin > ___ > 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: m...@astro.utoronto.ca ___ 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
