unutbu [EMAIL PROTECTED] added the comment:
Georg, please forgive me. I thought a sample size of 3 was much too small to
make a claim about the typical case, but it appears after doing a computer
experiment that I was wrong:
#!/usr/bin/env python
from __future__ import division
import timeit
unutbu [EMAIL PROTECTED] added the comment:
Let B = the set of all possible times on a particular machine (the machine on
which the timeit script is run).
Let x = the minimum of B.
Then the lowest value is an upper bound for x.
This is correct, accurate, not an oxymoron.
The above does not
Georg Brandl [EMAIL PROTECTED] added the comment:
Sadly, this is not mathematics. Else, I'd concur that the designation
lower bound should be accurate with respect to a certain set.
I fail to see what is missing in the explanation the lowest value is a
lower bound *in a typical case*. It allows
unutbu [EMAIL PROTECTED] added the comment:
Dear Georg,
Would you please reconsider this issue (http://bugs.python.org/issue3318)
for a moment?
The term lower bound as it is used in the timeit documentation is either
misleading or mathematically incorrect. A lower bound is a number which
Georg Brandl [EMAIL PROTECTED] added the comment:
I disagree. An ideal machine is not useful in practice, so any assertion
about it isn't helpful.
In that light, the snippet is correct in saying that if execution of a
snippet is done enough times, the lowest value is a lower bound for
execution
New submission from unutbu [EMAIL PROTECTED]:
Re: http://docs.python.org/lib/module-timeit.html
Where the documentation says In a typical case, the lowest value gives
a lower bound for how fast your machine can run the given code snippet,
it should read instead,
In a typical case, the lowest
