-
-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Numerical evaluation should return a complex number if applicable #24428
Comments
This comment has been minimized.
This comment has been minimized.
comment:2
I'm not decided on which result is correct. But see also #15344. |
comment:3
This would mean either 1. changing general evaluation of I'm in favor of the latter. |
comment:4
Note that |
comment:5
Does an expression in |
comment:6
Symbolic function expressions have internal restrictions as to their arguments but there is no information associated regarding domains. The function code in |
comment:7
It might be important to note that this is a regression:
|
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. |
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. |
comment:10
For example
(EDITED) So one of |
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 |
This comment has been minimized.
This comment has been minimized.
comment:12
Adding an example:
|
This comment has been minimized.
This comment has been minimized.
comment:14
I don't care what you do with the function
must not change. |
comment:15
With pynac-0.7.17:
Replying to @videlec:
That is however the reason for
and all the others because here (1.1).acos() is called first. |
comment:16
Replying to @slel:
Note that this only works because RDF has no arccosh member function, so the computation is delegated to Pynac. |
comment:17
Replying to @rwst:
In this situation you could just fallback to
|
comment:18
Replying to @videlec:
Instead of special casing I'd rather change the name of the inverse hyperbolic functions away from all the wrong Moreover, if I get a review on the change to always delegate to |
This comment has been minimized.
This comment has been minimized.
comment:20
So why is this not a bug?!
|
comment:23
Replying to @rwst:
It is a bug. |
comment:24
Following your answer in Groups I think then, instead of calling |
Dependencies: #24832 |
Branch: u/rws/24428 |
Author: Ralf Stephan |
Commit: |
comment:27
This needs fixes from pynac-0.7.17. To fix New commits:
|
comment:28
Merge failed. |
This looks wrong:
Especially given all the following:
A complex number is more useful than a
NaN
so we shouldn't returnNaN
in the first example.The
Function
code first callsx.arccosh()
which returns theNaN
. The reason for only the RDF case working is that RDF does not have aarccosh
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
The text was updated successfully, but these errors were encountered: