To me this sounds like a reasonable change. It does seem like there is a return value which is more sensible than alternatives.
And the fact that sympy is already doing that indicates that same conclusion was reached more than once. I am not dealing much with complex numbers at the moment, but I see this being of non-trivial convenience when I need to. Regards, DG > On 22 Dec 2023, at 15:48, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > > On Fri, 22 Dec 2023 at 13:25, <m...@astro.utoronto.ca> 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: dom.grigo...@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
