Numerical evaluation should return a complex number if applicable

[jdemeyer]

This looks wrong:

sage: arccosh(0.9)
NaN

Especially given all the following:

sage: arccosh(RDF(0.9))
0.45102681179626236*I

sage: arccosh(x).subs(x=0.9)
0.451026811796262*I

sage: sqrt(-2.0)
1.41421356237310*I

A complex number is more useful than a NaN so we shouldn't return NaN in the first example.

The Function code first calls x.arccosh() which returns the NaN. The reason for only the RDF case working is that RDF does not have a arccosh member function so the computation is delegated to Pynac where the complex value is returned.

Depends on #24832

Dependencies: #24832, pynac-0.7.17

CC: @rwst @slel

Component: symbolics

Author: Ralf Stephan

Branch/Commit: u/rws/24428 @ aa041a9

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

[jdemeyer]

Description changed:

--- 
+++ 
@@ -10,3 +10,5 @@
 sage: arccosh(x).subs(x=0.9)
 0.451026811796262*I
 ```
+
+The second result is more useful, so the first should probably return a complex number too.

[rwst]

comment:2

I'm not decided on which result is correct. But see also #15344.

[rwst]

comment:3

so the first should probably return a complex number too

This would mean either 1. changing general evaluation of f(arg) to not try arg.f() first or, 2. changing the interface to mpfr_acosh() (which is responsible for the NaN), i.e. RR.arccosh(), and some others too.

I'm in favor of the latter.

[rwst]

comment:4

Note that RBF(0.9).arccosh() returns nan as well.

[mantepse]

comment:5

Does an expression in SR (like acosh) come with a notion of domain and codomain?

[rwst]

comment:6

Symbolic function expressions have internal restrictions as to their arguments but there is no information associated regarding domains. The function code in sage/functions and in Pynac raises stock Python exceptions and runtime errors if nonsensical arguments are encountered, but just yesterday I wished I could catch them specifically, e.g. by inheriting from domain error---it would enable much better random testing.

[mantepse]

comment:7

It might be important to note that this is a regression:

sage: arccosh(0.9)
NaN
sage: arccosh(x).subs(x=0.9)
NaN
sage: version()
'SageMath version 8.1.beta5, Release Date: 2017-09-11'

[mantepse]

comment:8

in fact, the change must have been introduced in 8.2.beta1, because in 8.2.beta0 it still gives the expected result.

[rwst]

comment:9

That is no surprise as I changed FP evaluation in the commit pynac/pynac@d0f66f9

It might not be a bug. Still, the necessity of being consistent demands some fix somewhere.

[rwst]

comment:10

For example

sage: arccos(1.1)
NaN
sage: arccos(x).subs(x=1.1)
NaN

(EDITED)

So one of arccos/arccosh should be changed.

[mantepse]

comment:11

Changes in symbolics code are quite likely to produce doctest differences in the fricas interface, so it might make sense to make sure that these doctests are run.

In the case at hand, I guess it would be very important to specify domain and codomain of expressions which can be evaluated numerically, otherwise it will never be clear whether something is a bug or a feature.

Besides, I think that arccosh is terrible language :-)