#16439: Allow inverse trig functions to all take complex input
-------------------------------------+-------------------------------------
Reporter: kcrisman | Owner:
Type: defect | Status: needs_review
Priority: minor | Milestone: sage-6.3
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/ppurka/allow_inverse_trig_functions_to_all_take_complex_input|
c4ba30d802f932b29205ec3f49f3eeeeb0942e76
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by kcrisman):
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
[http://git.sagemath.org/sage.git/tree/src/sage/symbolic/pynac.pyx#n1596
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
[http://www.ginac.de/reference/inifcns__trans_8cpp_source.html#l00642
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.
--
Ticket URL: <http://trac.sagemath.org/ticket/16439#comment:9>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
