Opened 6 years ago
Closed 6 years ago
#21614 closed defect (fixed)
Doctest fix for: Make atan2(0,0) return NaN
Reported by:  Ralf Stephan  Owned by:  

Priority:  minor  Milestone:  sage7.4 
Component:  symbolics  Keywords:  
Cc:  Merged in:  
Authors:  Ralf Stephan  Reviewers:  Jeroen Demeyer 
Report Upstream:  N/A  Work issues:  
Branch:  fda5183 (Commits, GitHub, GitLab)  Commit:  fda5183e4f4cbf498d23744924694756ec5e9a51 
Dependencies:  #21623  Stopgaps: 
Description (last modified by )
Same with tan
and imag
:
sage: real(sqrt(sin(x))) sqrt(abs(sin(x)))*cos(1/2*arctan2(cos(real_part(x))*sinh(imag_part(x)), cosh(imag_part(x))*sin(real_part(x)))) sage: _.subs(x==0) ... RuntimeError: arctan2_eval(): arctan2(0,0) encountered
SymPy expands similarly but gives NaN on substitution instead of an exception.
This all would not be of concern if not 3d plotting would likely need real/imag parts of a function, their workaround real(...,hold=True)
works perfectly but this is not the general solution that is needed.
One solution would be to return NaN
instead of throwing up.
Change History (10)
comment:1 Changed 6 years ago by
Dependencies:  → pynac0.6.91 

Description:  modified (diff) 
comment:3 followup: 6 Changed 6 years ago by
Then make it known in that documentation that I just decided that symbolic NaN is to be returned whenever the result is not defined, not even complex infinity. That pertains to expressions, not relations. It could also be returned with 0/0
.
I think the SymPy folks have thought more about their ad hoc solution, and if I copy it it's not ad hoc, either.
Not a Number. This serves as a place holder for numeric values that are indeterminate. Most operations on NaN, produce another NaN. Most indeterminate forms, such as ``0/0`` or ``oo  oo` produce NaN. Two exceptions are ``0**0`` and ``oo**0``, which all produce ``1`` (this is consistent with Python's float). NaN is loosely related to floating point nan, which is defined in the IEEE 754 floating point standard, and corresponds to the Python ``float('nan')``. Differences are noted below. NaN is mathematically not equal to anything else, even NaN itself. This explains the initially counterintuitive results with ``Eq`` and ``==`` in the examples below. NaN is not comparable so inequalities raise a TypeError. This is in constrast with floating point nan where all inequalities are false.
comment:4 Changed 6 years ago by
Branch:  → u/rws/make_atan2_0_0__return_nan 

comment:5 Changed 6 years ago by
Commit:  → fda5183e4f4cbf498d23744924694756ec5e9a51 

Dependencies:  pynac0.6.91 → #21623 
New commits:
fda5183  21614: fix some real/imag part expansions

comment:6 Changed 6 years ago by
Replying to rws:
Then make it known in that documentation that I just decided that symbolic NaN is to be returned whenever the result is not defined, not even complex infinity. That pertains to expressions, not relations. It could also be returned with
0/0
.
Sorry if my comment came off as a criticism, that was not the intent. What I'm trying to say is that I find this kind of tickets hard to review, because I'm unable to tell if the change is actually an improvement (because it fixes a perceived issue) or a regression (typically because it introduces an inconsistency across different parts of Sage).
comment:7 Changed 6 years ago by
It is very hard to keep an overview of all details that can appear in "symbolics" (minus algebra). There are some bright people leading the SymPy effort. I think it's a good start to follow them.
comment:8 Changed 6 years ago by
Authors:  → Ralf Stephan 

Status:  new → needs_review 
Summary:  Make atan2(0,0) return NaN → Doctest fix for: Make atan2(0,0) return NaN 
comment:9 Changed 6 years ago by
Reviewers:  → Jeroen Demeyer 

Status:  needs_review → positive_review 
comment:10 Changed 6 years ago by
Branch:  u/rws/make_atan2_0_0__return_nan → fda5183e4f4cbf498d23744924694756ec5e9a51 

Resolution:  → fixed 
Status:  positive_review → closed 
I'm a bit uncomfortable with the idea of returning NaN for exact (as opposed to floatingpoint) input... But more importantly, my feeling is that we need to decide and document once and for all how symbolic functions should behave depending on the type, parent and value of their argument(s), based on the many examples you collected, instead of coming up with ad hoc solutions every time.