Open zimmermann6 opened 6 years ago
That's a symbolic function evaluation issue, not the fault of CIF.
As an explanation, the handling of inexact function arguments has several layers. The fallback layer (if the arg has no suitable member function and exact evaluation has no tricks) is to call the helper functions in libs/pynac/pynac.pyx
which use member functions of RR and CC. There is in most cases no automatic back-conversion to the argument type so, as fallback, you at least get Real/ComplexField
elements.
There is work ongoing in Pynac to use arb instead of RR
and CC
because of speed and ease of conversion to e.g. interval field elements. It's just that inverse hyperbolic functions are still waiting for it. Of course one could state it's the responsibility of CIF to implement inverse hyperbolic functions (and inverse trig functions, for that matter) but I'm not holding my breath. CIF is a math programming exercise, Pynac tries to solve real calculus problems, so we'll implement it in Pynac-0.7.14.
Description changed:
---
+++
@@ -6,3 +6,12 @@
0.881373587019543
The second command should return a (complex) interval.
+
+Also:
+
+ +sage: asin(CIF(0.6)) +... +TypeError: unable to convert '0.59999999999999998?' to a real number +
+
Dependencies: #24317
Changed dependencies from #24317 to #24318, pynac-0.7.14
New commits:
0dad6ad | 24299: Bugs with inverse trig and hyperbolic functions of CIF argument |
Author: Ralf Stephan
Changed dependencies from #24318, pynac-0.7.14 to #24318, #24329
I'd like to review this, but I see only non-regression tests in commit 0dad6ad, and no changes in the source code. How could the results change?
Replying to @zimmermann6:
I'd like to review this, but I see only non-regression tests in commit 0dad6ad, and no changes in the source code. How could the results change?
Functions can be either coded in Python (BuiltinFunction
) or C++ (GinacFunction
in Pynac). FP evaluation first looks if CIF has a member for asinh
and, as there isn't, the function's evalf
member is called. As trig and hyperbolic functions are GinacFunction
s the changes needed to be done in Pynac, and they became effect with #24329 which was introduced in beta0 I think. So, in order to see the doctests fail you need to go back to 8.1.
I'm not sure about this:
sage: acoth(CIF(0.6))
0.693147180559945?
since we get with CC:
sage: acoth(CC(0.6))
0.693147180559945 - 1.57079632679490*I
Reviewer: Paul Zimmermann
Agreed, still buggy.
I did a systematic search and found these additional issues:
sage: log_gamma(complex(1.7))
-0.09580769740706588
sage: psi(complex(1.7))
0.2085478748734939
Also dickman_rho
can't handle anything other than float.
The code I used will go into tests/symbolic-functions.py
.
Changed branch from u/rws/bugs_with_inverse_trig_and_hyperbolic_functions_of_cif_argument to u/rws/24299
Changed dependencies from #24318, #24329 to #24318, #24329, #24604
Replying to @zimmermann6:
I'm not sure about this:
sage: acoth(CIF(0.6)) 0.693147180559945?
This one is now fixed in Pynac-0.7.16.
Now with Pynac-0.7.16 still failing.
Update: the correct arccoth(RR(0.7))-->CC
, elliptic_eu(7,CC(1.7))
, jacobi_am(7,CC(1.7))
are flagged wrong. Still failing: dickman_rho(all types)
.
The second command should return a (complex) interval.
Also:
Depends on #24318 Depends on #24329 Depends on #24604
CC: @jdemeyer
Component: symbolics
Author: Ralf Stephan
Branch/Commit: u/rws/24299 @
0b52ecd
Reviewer: Paul Zimmermann
Issue created by migration from https://trac.sagemath.org/ticket/24299