Thanks! That gets me exactly what I wanted. I don't think I would
have been able to locate that code myself.
Based on this code and some quick math it confirms that not only will
the rollover be a looong way out, but that there will not be any loss
in precision until ~ 30 years down the road. Checking my math:
(float(10**16 + 1) - float(10**16)) == 0
(float(10**15 + 1) - float(10**15)) == 1
ie: our double precision float can resolve unity differences out to
at least 10**15
Assuming 1 us/count we have 10**15 us / (3.15E13 us/year) = 31.7 yrs
Past this we won't roll over since the long keeps counting for a long
time, but some precision will be lost.
For those interested, the relevant win32 time code is below. Thanks
again!
time_clock(PyObject *self, PyObject *args)
{
static LARGE_INTEGER ctrStart;
static double divisor = 0.0;
LARGE_INTEGER now;
double diff;
if (!PyArg_ParseTuple(args, ":clock"))
return NULL;
if (divisor == 0.0) {
LARGE_INTEGER freq;
QueryPerformanceCounter(&ctrStart);
if (!QueryPerformanceFrequency(&freq) || freq.QuadPart == 0) {
/* Unlikely to happen - this works on all intel
machines at least! Revert to clock() */
return PyFloat_FromDouble(clock());
}
divisor = (double)freq.QuadPart;
}
QueryPerformanceCounter(&now);
diff = (double)(now.QuadPart - ctrStart.QuadPart);
return PyFloat_FromDouble(diff / divisor);
}
--
http://mail.python.org/mailman/listinfo/python-list
