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.benjamin@gmail.com> wrote:

On Fri, 22 Dec 2023 at 13:25, <mhvk@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-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: dom.grigonis@gmail.com