<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Replying to myself again here, as nobody else said anything:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 16, 2017 at 5:42 PM, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_-3389390805994229347gmail-h5"><div><font face="arial, helvetica, sans-serif"><br></font></div></div></div><div><font face="arial, helvetica, sans-serif">​Indeed. And some more on where the precision loss comes from:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">When you measure time starting from one point, like 1970, the timer reaches large numbers today, like 10**9 seconds. Tiny fractions of a second are especially tiny when compared to a number like that.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">You then need log2(10**9) ~ 30 bits of precision just to get a one-second resolution in your timer. A double-precision (64bit) floating point number has 53 bits of precision in the mantissa, so you end up with 23 bits of precision left for fractions of a second, which means you get a resolution of 1 / 2**23 seconds, which is about 100 ns, which is well in line with the data that Victor provided (~100 ns + overhead = ~200 ns).</font></div><span class="m_-3389390805994229347gmail-HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">​My calculation is indeed *approximately* correct, but ​the problem is that I made a bunch of decimal rounding errors while doing it, which was not really desirable here. The exact expression for the resolution of time.time() today is:</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default"><font face="monospace, monospace">>>> 1 / 2**(53 - math.ceil(math.log2(time.time(<wbr>))))</font><br></div><div class="gmail_default" style="font-family:monospace,monospace">​2.384185791015625e-07 </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">So this is in fact a little over 238 ns. Victor got 239 ns experimentally. So actually the resolution is coarse enough to completely drown the the effects of overhead in Victor's tests, and now that the theory is done correctly, it is completely in line with practice.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div>-- <br><div class="m_-3389390805994229347gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>