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 <[email protected]> wrote: > > On Fri, 22 Dec 2023 at 13:25, <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: [email protected] _______________________________________________ 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]
