sign(z) = z/|z| is a fairly standard definition. See https://oeis.org/wiki/Sign_function and https://en.wikipedia.org/wiki/Sign_function. It's also implemented this way in MATLAB and Mathematica (see https://www.mathworks.com/help/symbolic/sign.html and https://reference.wolfram.com/language/ref/Sign.html). The function z/|z| is useful because it represents a normalization of z as a vector in the complex plane onto the unit circle.
With that being said, I'm not so sure about the suggestion about extending copysign(x1, x2) as |x1|*sign(x2). I generally think of copysign as a function to manipulate the floating-point representation of a number. It literally copies the sign *bit* from x2 into x1. It's useful because of things like -0.0, which is otherwise difficult to work with since it compares equal to 0.0. I would find it surprising for copysign to do a numeric calculation on complex numbers. Also, your suggested definition would be wrong for 0.0 and -0.0, since sign(0) is 0, and this is precisely where copysign matters. I suppose one could make sense of copysign(x1, x2) where x1 is complex and x2 is float, by copying the sign of x2 into both components of x1. Although I would suggest only adding such a thing if there's an actual need for it. I imagine presently if anyone does need this they just use copysign(x1.view(float64), x2).view(complex128). Aaron Meurer On Sat, Dec 23, 2023 at 8:36 AM Dom Grigonis <dom.grigo...@gmail.com> wrote: > > 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: asmeu...@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
