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
Juanlu001 opened this Issue Jun 22, 2015 · 3 comments

Comments

1 participant
@Juanlu001
Member

Juanlu001 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.

@Juanlu001 Juanlu001 added the bug label Jun 22, 2015

@Juanlu001 Juanlu001 added this to the 0.4 milestone Jun 22, 2015

@Juanlu001 Juanlu001 added the 1 - Ready label Jun 23, 2015

@Juanlu001

This comment has been minimized.

Member

Juanlu001 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

@Juanlu001

This comment has been minimized.

Member

Juanlu001 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.

@Juanlu001

This comment has been minimized.

Member

Juanlu001 commented Jun 23, 2015

Reported the numba problem: numba/numba#1256

Juanlu001 added a commit that referenced this issue Jun 23, 2015

@Juanlu001 Juanlu001 self-assigned this Jun 23, 2015

@Juanlu001 Juanlu001 added 2 - In Progress and removed 1 - Ready labels Jun 23, 2015

Juanlu001 added a commit that referenced this issue Jun 30, 2015

Juanlu001 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