Symbolic asin/acos do not return symbolic NaN

[rws]

sage: acos(SR(2.))
NaN
sage: type(acos(SR(2.)))
<type 'sage.symbolic.expression.Expression'>
sage: type(acos(SR(2.)).pyobject())
<type 'sage.rings.real_mpfr.RealNumber'>

Expected would be:

sage: type(acos(SR(2.)))
<type 'sage.symbolic.expression.Expression'>
sage: type(acos(SR(2.)).pyobject())
<class 'sage.symbolic.constants.NotANumber'>

Same applies to asin. Compare with:

sage: type(asec(0))
<type 'sage.symbolic.expression.Expression'>
sage: type(asec(0).pyobject())
<class 'sage.symbolic.constants.NotANumber'>

[mforets]

with a custom function this happens:

sage: f = piecewise([((-1,0), 1), ([0,1], -1)], var=x)
sage: f(2)
...
ValueError: point 2 is not in the domain

to say that the result here is more informative than NaN, although i suppose that the notion of domain is a feature not implemented for symbolic functions?..

[rws]

New commits:

​c13d90e	22823: Symbolic asin/acos do not return NaN where possible
​7ccd5ab	22823: fix doctests

[rws]

Replying to mforets:

ValueError: point 2 is not in the domain

to say that the result here is more informative than NaN, although i suppose that the notion of domain is a feature not implemented for symbolic functions?..

We're far away from that unfortunately.

[kcrisman]

Whoah. Are you then saying we also shouldn't allow log(-1)? After all:

sage: acos(CC(2))
1.31695789692482*I

I'm not cool with all of a sudden assuming symbolic things couldn't be complex, unless we are very consistent about this everywhere, and I suspect this would break a lot of stuff. Your example with arc secant is a red herring, because

sage: asec(CC(0))
NaN

At the very least this sort of thing should be discussed on sage-devel, in my view.

[rws]

Well then, scratch the acos(2) part, the acos(SR(2.1)) part certainly needs fixing. Thanks for the review.

[kcrisman]

Well then, scratch the acos(2) part, the acos(SR(2.1)) part certainly needs fixing. Thanks for the review.

I'm not saying we couldn't do that, but we would definitely need discussion on it and you are right that things should be consistent. My guess is that making things consistent with your idea might lead to a lot of work being needed as well as other stuff breaking, but I am not an expert in numerics either.

---

New commits:

​e802bf8

22823: Symbolic asin/acos do not return symbolic NaN

[tscrim]

@kcrisman, are you okay with the current branch getting a positive review and then pushing the other issues to another ticket? The other thing we could do is move the doctests into another ticket.

[kcrisman]

@kcrisman, are you okay with the current branch getting a positive review and then pushing the other issues to another ticket? The other thing we could do is move the doctests into another ticket.

Sure, that is no problem at all, assuming all is working fine.

[tscrim]

Thanks.

[rws]

Reverted in pynac-0.7.17. Reason would be consistency with #24428.