rate_function.py can cause ZeroDivisionError

[pataphor]

In file ../site-packages/visual_common/rate_function.py:
Line 196:
dt = calledTime - self.lastEndRate # time spent in user code
But sometimes this results in dt becoming equal to zero.
Then, in line 199:
self.userTime = dt # the first time we have a user code time is self.count == 2
Now self.userTime is zero too.
But in line 152:
U = self.userTime
and later, in the same function, we have at line 163:
M = int(USER_FRACTION/U)
Which then will cause a ZeroDivision Error traceback

Proposed fix:

Add at line 13:
SMALLEST_FLOAT = sys.float_info.min
and at line 201:
if self.userTime == 0:
self.userTime = SMALLEST_FLOAT

[pataphor]

This went well for some time, until M (== self.rateCalls) becomes too large:
"/usr/local/lib/python2.7/dist-packages/VPython-6.10-py2.7-linux-x86_64.egg/visual_common/rate_function.py", line 139, in distributeRenders
for i in range(M):
OverflowError: range() result has too many items

Maybe set a maximum value for rateCalls too? Switch to a lookuptable? It seems I don't know enough about the code to suggest fixes after all.

[BruceSherwood]

Thanks much for digging out this problem. I'm puzzled that I've not seen the divide by zero issue. Do you have a test program that triggers the bug?

[pataphor]

I didn't manage to get it down to a few lines yet. It only works on one of my two machines. It crashes the interpreter reliably after only a few interactions, especially if I maximize the window. One would have to find some code that on a specific machine causes "calledTime" to be equal to "self.lastEndRate".
Here's the script that I used:
https://possiblywrong.wordpress.com/2011/01/15/yet-another-rubiks-cube/

After provisionally applying both my ideas to rate_function.py: setting a minimum value for self.userTime and capping M at 10000 (a reasonable maximum range), there where no more tracebacks.