asin(2.0) should not return NaN

[sagetrac-davidamadore]

Currently, asin(2.0) returns NaN, whereas asin(CC(2.0)) returns the more expected value of 1.57079632679490 - 1.31695789692482*I (that's π/2 − acosh(2)·I).

I can understand the logic of not wanting to return a complex value for a real argument, but since sqrt(-1.0) already returns 1.0*I, there are already parts of Sage which break that logic.

Conversely, this convention of returning NaN causes many difficulties when plotting functions. For example, plot(imag(asin(x)),(x,0,3)) does not at all return what is expected. And, of course, plot(imag(asin(CC(x))),(x,0,3)) does not work, so one has to write plot(lambda t: imag(asin(CC(t))),(0,3)), which, in this simple example, might be a very minor inconvenience, but can become a great annoyance when dealing with more complicated situations.

The fact that Sage sometimes considers values as reals even though they were obtained by complex computations adds insult to injury:

sage: N(asin((1+I)*(1-I)))
NaN
sage: asin((1.+1.*I)*(1.-1.*I))
1.57079632679490 - 1.31695789692482*I

(if asin(2) persists in returning NaN, then at least (1+I)*(1-I) should refrain from looking too much like an integer until it is explicitly coerced as such).

Component: symbolics

Keywords: functions

Issue created by migration from https://trac.sagemath.org/ticket/15344

[rwst]

comment:5

This touches several issues. Maybe we should agree for now to get different results with a float and a complex/CC type. The same difference exists with real/complex ball arguments. It's not good that there is no easy way to specify argument type when plotting, a better workaround however IMHO is to add epsilon*I, e.g. plot(imag(asin(x+I*1e-10)),(x,0,3)). This should be addressed (complex() symbolic function?) but not here.

There are already other parts where complex is returned on float input, right. However changing the output of asin(2.0) and asin(RBF(2.0)) would mean changing the interface to the mpfr and arb packages that are used here. This is possible.

Now (1+I)*(1-I) and (1.+1.*I)*(1.-1.*I) are completely differently handled than the above because they are symbolic expressions. There were recent changes in Pynac that made asin((1.+1.*I)*(1.-1.*I)) return NaN as well. Adapting this to the above numeric changes would be easy. I think asin(2) should then also return 1/2*pi - I*arccosh(2) instead of arcsin(2).

[videlec]

comment:6

Replying to @rwst:

Maybe we should agree for now to get different results with a float and a complex/CC type. The same difference exists with real/complex ball arguments.

Indeed, asin: RR -> RR (inverse of sin) is different from asin: CC -> CC (a principal value). In the same veine, the real logarithm is not defined for negative inputs

sage: import math, cmath
sage: math.log(-1r)
Traceback (most recent call last):
...
ValueError: math domain error
sage: cmath.log(-1r)
3.141592653589793j

To my mind, Sage is doing wrong here

sage: RR(-1).log()
3.14159265358979*I
sage: RDF(-1).log()
3.141592653589793*I

It's not good that there is no easy way to specify argument type when plotting, [...]

I do not think that this is the real problem. As explained before, acosh, log, etc mean different things (with various domains and ranges). This information should be known by the function (aka it should be a polymorphic function). It should also be possible to bind a well defined mathematical function from the polymorphic one such as

sage: log.bind(domain=RR, range=RR)
The real logarithm on Real Field with 53 bits of precision
sage: log.bind(domain=CC, range=CC)
The principal value of logarithm on Complex Field with 53 bits of precision

The above binded functions should know about there domain, range, singularities, etc.