jax.numpy.arcsin(2+0j) shows different value of numpy.arcsin(2+0j)

[sofomryu]

jax.numpy.arcsin(2+0j) = 1.57-1.31j
numpy.arcsin(2+0j)= 1.57+1.31j

The two library shows complex conjugate value for arcsin(2+0j).
This is big problem for my simulation.

In my simulation, the sequential computation of sin function and arcsin function is required.
For example, sin(arcsin(sin(arcsin(sin...arcsin(x)))).

If I do this for x=2+0j with jax.numpy, arcsin(2+0j)=1.57-1.31j, then sine of this is 2+0.00...0001j, then arcsin of this 1.57+1.31j.
So, the first arcsin's imaginary value(-1.31j) has opposite value of second arcsin(+1.31j)

If I do same thing with numpy, arcsin(2+0j)=1.57+1.31j, then sine of this is 2+0.0..001j, then arcsin of this is 1.57+1.31j.
Using numpy, first arcsin's imaginary value(+1.31j) has same value of the second arcsin(+1.31j)

If I do the same thing with Matlab, arcsin(2+0j)=1.57-1.31j, then sine of this is 2-0.0...0001j, then arcsin of this is 1.57-1.31j.
Using Matlab, the first arcsin's imaginary value(-1.31j) has same value of the second one(-1.31j)

My simulation result is very sensitive for this problem. For my simulation, the exact way is the way matlab does. Why are they different? and how can I implement the matlab way using jax.numpy?

[jakevdp]

Hi, thanks for the question! The arcsin function is multi-valued, and so any implementation must choose which branch it returns. In this case, numpy and jax.numpy are simply returning different (but both correct) answers for arcsin(x) at a particular point.

If your simulation is sensitive to which branch a particular arcsin implementation returns, then you might want to think about rewriting it to make the computation more robust.

[sofomryu]

Thank you for your reply, then can I choose the branch that I want for arcsin with jax.numpy? Also, I wonder if I can set sin(1.57+1.31j) as 2-0.00...001j not 2+0.00...1j?

[jakevdp]

No, JAX doesn't offer any fine-grained control over the branch that is used for particular inputs to jnp.arcsin. You could always define your own version of arcsin with a different branch convention, e.g.

def my_arcsin(z):
  result = jnp.arcsin(z)
  return jnp.where(jnp.imag(z) == 0, result.conj(), result)

But I would not recommend this as a fix. It would be fixing the symptom rather than fixing the root cause of the problem, which is that your simulation is too sensitive to particular branch cutoff conventions of complex functions.

[hawkinsp]

I will note that np.arcsin actually specifies where the branch cut is:

For complex-valued input, arcsin is a complex analytic function that has, by convention, the branch cuts [-inf, -1] and [1, inf] and is continuous from above on the former and from below on the latter.

Does the JAX implementation conform to that spec?

[sofomryu]

I will note that np.arcsin actually specifies where the branch cut is:

For complex-valued input, arcsin is a complex analytic function that has, by convention, the branch cuts [-inf, -1] and [1, inf] and is continuous from above on the former and from below on the latter.

Does the JAX implementation conform to that spec?

It doesn't seem so.
jnp.arcsin(2+0j)=1.57-1.31j , while jnp.arcsin(1.1+0j)=1.57-0.43j.
The real part of the value consist, but not the imaginary part.