Opened 3 years ago
Last modified 5 months ago
#24428 needs_work defect
Numerical evaluation should return a complex number if applicable — at Version 13
Reported by: | jdemeyer | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-8.2 |
Component: | symbolics | Keywords: | |
Cc: | rws, slelievre | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
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.
Change History (13)
comment:1 Changed 3 years ago by
- Description modified (diff)
comment:2 Changed 3 years ago by
comment:3 Changed 3 years ago by
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.
comment:4 Changed 3 years ago by
Note that RBF(0.9).arccosh()
returns nan as well.
comment:5 Changed 3 years ago by
Does an expression in SR
(like acosh
) come with a notion of domain and codomain?
comment:6 Changed 3 years ago by
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.
comment:7 Changed 3 years ago by
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'
comment:8 Changed 3 years ago by
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 Changed 3 years ago by
That is no surprise as I changed FP evaluation in the commit https://github.com/pynac/pynac/commit/d0f66f94ab4564a9a43aaf5907f7ac2a90047890
It might not be a bug. Still, the necessity of being consistent demands some fix somewhere.
comment:10 Changed 3 years ago by
For example
sage: arccos(1.1) NaN sage: arccos(x).subs(x=1.1) NaN
(EDITED)
So one of arccos/arccosh
should be changed.
comment:11 Changed 3 years ago by
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 :-)
comment:12 Changed 3 years ago by
- Cc slelievre added
- Description modified (diff)
Adding an example:
sage: arccosh(RDF(0.9)) 0.45102681179626236*I
comment:13 Changed 3 years ago by
- Description modified (diff)
- Summary changed from Substitution should be the same as numerical evaluation to Numerical evaluation should return a complex number if applicable
I'm not decided on which result is correct. But see also #15344.