Skip to content
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

ZeroDivisionError when propagating with time zero #50

Closed
astrojuanlu opened this issue Jun 22, 2015 · 3 comments
Closed

ZeroDivisionError when propagating with time zero #50

astrojuanlu opened this issue Jun 22, 2015 · 3 comments
Assignees
Labels
bug
Milestone

Comments

@astrojuanlu
Copy link
Member

@astrojuanlu astrojuanlu commented Jun 22, 2015

Actually if NUMBA_DISABLE_JIT is exported this appears as a maximum number of iterations error. Why does it change is a matter of study, but still the easiest way to fix it is to contemplate the special case of time = 0.0 at the very beginning of the _kepler function.

@astrojuanlu astrojuanlu added the bug label Jun 22, 2015
@astrojuanlu astrojuanlu added this to the 0.4 milestone Jun 22, 2015
@astrojuanlu
Copy link
Member Author

@astrojuanlu astrojuanlu commented Jun 23, 2015

The problem lies in the relative tolerance checking in the algorithm:

if abs((xi_new - xi) / xi_new) < rtol:

For values near zero (or equal to zero, as in this case) the check fails. An absolute tolerance check would be more appropriate in this case to make the algorithm more robust (see for example https://www.python.org/dev/peps/pep-0485/ for a well thought implementation coming in Python 3.5).

Therefore, there are two solutions for the problem:

  • Implement a more robust checking. This would involve adding an extra atol parameter, and would make the algorithm itself more robust.
  • Check in kepler if the time of flight is zero and in that case return straight away. The algorithm itself will still fail for time equal to zero though.

cc/ @AunSiro

@astrojuanlu
Copy link
Member Author

@astrojuanlu astrojuanlu commented Jun 23, 2015

Regarding the different behavior when numba jitting is enabled or not, I guess it has to do with that same check. Perhaps it treats division differently (i.e. not in "NumPy mode") and a ZeroDivisionError is raised right there, instead of np.nan.

>>> (0. - 0.) / 0.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: float division by zero
>>> (0. - 0.) / np.array(0.)
nan

Notice also that in original reports by @AunSiro (Python 3) the exact message was ZeroDivisionError: division by zero, which suggests an integer division:

$ python
Python 3.4.3 |Continuum Analytics, Inc.| (default, Jun  4 2015, 15:29:08)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1 / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
>>> 1 / 0.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: float division by zero

Further checking is needed.

@astrojuanlu
Copy link
Member Author

@astrojuanlu astrojuanlu commented Jun 23, 2015

Reported the numba problem: numba/numba#1256

astrojuanlu added a commit that referenced this issue Jun 23, 2015
Closes #50.
@astrojuanlu astrojuanlu self-assigned this Jun 23, 2015
astrojuanlu added a commit that referenced this issue Jun 30, 2015
astrojuanlu added a commit that referenced this issue Jun 30, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant