Allow inverse trig functions to all take complex input

[kcrisman]

Where by complex I mean complex Python type.

sage: arccos(1+2*i)
arccos(2*I + 1)
sage: arccos(CC(1,2))
1.14371774040242 - 1.52857091948100*I
sage: arccos(CDF(1,2))
1.1437177404 - 1.52857091948*I
sage: arccos(complex(1,2))
<snip>
TypeError: Unable to convert x (='(1+2j)') to real number.

Presumably there are others of this type. Related:

sage: arcsec(-0.992725195401)
NaN
sage: arcsec(float(-0.992725195401))
<snip>
    732         if parent is float:
    733             return math.acos(1/x)
--> 734         return (1/x).arccos()
    735 
    736     def _eval_numpy_(self, x):

AttributeError: 'complex' object has no attribute 'arccos'

but this may or may not be dealt with at #13246.

CC: @burcin

Component: symbolics

Author: Punarbasu Purkayastha

Branch/Commit: 7c4c725

Reviewer: Karl-Dieter Crisman, Ralf Stephan

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

[ppurka]

comment:1

Why don't complex numbers have these attributes? This should be possible - for example wolfram alpha gives a value for acos(-0.9+i).

I think the computations should be performed using CDF and then coerced back to complex. Complex output from these functions should be handled by the plot function separately.

[kcrisman]

comment:2

Why don't complex numbers have these attributes? This should be possible - for example wolfram alpha gives a value for acos(-0.9+i).

Complex number do have these attributes, just not the minimalist complex Python data type.

sage: a = complex(1,1)
sage: a.[tab]
a.conjugate  a.imag       a.real       
sage: a._[tab]
a.__abs__           a.__hash__          a.__rdivmod__
a.__add__           a.__init__          a.__reduce__
a.__class__         a.__int__           a.__reduce_ex__
a.__coerce__        a.__le__            a.__repr__
a.__delattr__       a.__long__          a.__rfloordiv__
a.__div__           a.__lt__            a.__rmod__
a.__divmod__        a.__mod__           a.__rmul__
a.__doc__           a.__mul__           a.__rpow__
a.__eq__            a.__ne__            a.__rsub__
a.__float__         a.__neg__           a.__rtruediv__
a.__floordiv__      a.__new__           a.__setattr__
a.__format__        a.__nonzero__       a.__sizeof__
a.__ge__            a.__pos__           a.__str__
a.__getattribute__  a.__pow__           a.__sub__
a.__getnewargs__    a.__radd__          a.__subclasshook__
a.__gt__            a.__rdiv__          a.__truediv__

And the built-in math module doesn't do arcsec

sage: math.a[tab]
math.acos   math.asin   math.atan   math.atanh  
math.acosh  math.asinh  math.atan2  

and even then only takes ones with real output

sage: math.acos(1)
0.0
sage: math.acos(2)
ValueError: math domain error
sage: math.acos(a)
TypeError: can't convert complex to float

I think the computations should be performed using CDF and then coerced back to complex. Complex output from these functions should be handled by the plot function separately.

Maybe. Is CDF basically the same as complex? Is there precedent for this?

[ppurka]

comment:3

Replying to @kcrisman:

I think the computations should be performed using CDF and then coerced back to complex. Complex output from these functions should be handled by the plot function separately.

Maybe. Is CDF basically the same as complex? Is there precedent for this?

I do not know a precedent, but we will not be losing anything from doing this. The Python complex number comprises of two floating point numbers which are implemented as double in C - see this documentation. The CDF in Sage also use double precision floating point numbers.

sage: CDF.precision()
53

# Following the documentation at
# https://docs.python.org/2/library/sys.html#sys.float_info
sage: import sys
sage: sys.float_info.mant_dig
53

[ppurka]

Branch: u/ppurka/allow_inverse_trig_functions_to_all_take_complex_input

[ppurka]

Commit: c4ba30d

[ppurka]

comment:5

The following functions are not fixed: atan, acos, asin because I am not very sure how they get evaluated. I have fixed the other functions to take complex type as input.

Now, on to the plot ticket to check the output *phew*

---

New commits:

b34ee39	allow some trigonometric functions to take complex as input
c4ba30d	add couple of doctests for complex input

[kcrisman]

comment:6

The following functions are not fixed: atan, acos, asin because I am not very sure how they get evaluated. I have fixed the other functions to take complex type as input.

You'll notice that here

arctan = atan = Function_arctan()

so atan is exactly the same as arctan - one fix works for both!

[kcrisman]

comment:7

so atan is exactly the same as arctan - one fix works for both!

(Though I haven't actually tried the branch.)

---

I understand and approve of the changes for trig.py, pending verification and messing around. But I don't quite get the changes in function.pyx. In particular, it seems like there is too much stuff. If org_parent is float then return org_parent(RDF(res)) does nothing (or at least nothing that wouldn't have happened with float, I hope). Why would that be better than just converting to float? I'd go straight to trying the CDF piece. Is there some specific case I'm not considering that would make me think that?

[kcrisman]

comment:8

The following functions are not fixed: atan, acos, asin because I am not very sure how they get evaluated. I have fixed the other functions to take complex type as input.

I see what you mean now, you also mean arctan, arccos, and arcsin. Sorry for my confusion. I expect they are evaluated in Ginac. I will investigate that a bit. But at least those guys plot fine.

[kcrisman]

comment:9

Got it!

When GinacFunction goes up to BuiltinFunction it first tries doing it in Function. That coerces your complex to SR. (Incorrectly, perhaps, because

sage: SR(float(1))
1.0
sage: SR(complex(1,1))
(1+1j)

and I'm not sure what's up with the parentheses, but I don't really know much about coercion in Sage.)

Anyway, then it goes to the arcsin() method in sage.symbolic.expression.Expression (!) because now we have a symbolic expression for the previously complex input. And I'm pretty sure that this is where things go wrong, because here it looks like it tries to coerce our now-symbolic thing to RR, which of course we can't do.

Now you'll notice that in e.g. py_tan in the same file it then would go on to try coercing to CC, but it doesn't here. In fact, in a whole bunch of places this happens, and

sage: sinh(complex(1,1))
<snip>
TypeError: Unable to convert x (='(1+1j)') to real number.

so I am pretty sure this is where things end.

The reason your fix for the other arc trig functions works is because they are not defined in Ginac/Pynac. But these functions don't work with complex input, presumably because here it doesn't handle complex stuff, or maybe because when we replaced Ginac's internal numbers with Sage ones something happened.

I'm cc:ing Burcin, who will probably have a suggestion as to the best place to fix this. But my druthers would be to just copycat what happens in sage/symbolic/pynac.pyx for other complex input, like py_exp or py_acosh.

Though as you say if we can't get it done quickly enough here, we can do this stuff and open a new ticket for it. But I really don't like that coercion to SR of complexes.