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 a
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 wh
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
executio
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
