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]
