Tim Peters added the comment:
Hmm. One obvious difference on my box:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit
(Intel)] on win32
>>> time.get_clock_info('monotonic')
namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True,
resolution=0.015625)
So the "resolution" here is exactly 1/64. If that's truly the resolution, then
all the results I'll see are exactly representable as Python floats.
The "resolution" you see (0.015600099999999999) looks bizarre. Not because of
the trailing nines, but because 0.0156001 doesn't appear to have any natural
hardware or software meaning in decimal or binary.
That said, I see we get the resolution from GetSystemTimeAdjustment. I don't
understand the Windows time functions, but also don't see anything in the MSDN
docs to suggest that the results from GetSystemTimeAdjustment "should have"
anything to do with the resolution of GetTickCount64. But maybe they do - LOL
;-)
One other point: we have lots of code of the form:
info->resolution = timeIncrement * 1e-7;
That is, we multiply some integer type by a double _negative_ power of 10. All
such code is needlessly inaccurate: no negative power of 10 is exactly
representable as a double, so we suffer a rounding error in representing 1e-7,
and then another rounding error from the multiplication. It's trivial to
reduce the grand total to one rounding error instead, by rewriting as:
info->resolution = timeIncrement / 1e7;
But these rounding errors are too tiny to account for the difference between,
e.g., 0.4990000000107102 and 0.5.
I don't conclude that we don't know what we're doing, but I bet we don't really
understand what Windows is doing ;-)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
