[Numpy-discussion] extracting a random subset of a vector

[Robert Kern]

Curzio Basso wrote:

> Robert Kern wrote:
> 
>  >>>> a question about the method: isn't a bit risky to use the clock() 
> for timing the performance? The usual argument is that CPU allocates 
> time for different processes, and the allocation could vary.
>  >>>
>  >>>
>  >>> that's why I use time.clock() rather than time.time().
>  >>
>  >>
>  >>   Perhaps clearing up a mutually divergent assumption:  time.clock() 
> measures CPU time on POSIX and wallclock time (with higher precision 
> than time.time()) on Win32.
>  >
>  >
>  > FWIW, the idiom recommended by Tim Peters is the following:
>  >
>  > import time
>  > import sys
>  >
>  > if sys.platform == 'win32':
>  >     now = time.clock
>  > else:
>  >     now = time.time
>  >
>  > and then using now() to get the current time.
> 
> 
> Ok, now I'm really confused...
> 
>  From the doc of the module 'time': the clock function "return the 
> current processor time as a floating point number expressed in seconds." 
> AFAIK, the processor time is not the time spent in the process calling 
> the function. Or is it? Anyway, "this is the function to use for 
> benchmarkingPython or timing algorithms.", that is, if processor time is 
> good enough, than use time.clock() and not time.time(), irregardless of 
> the system, right?

I think that the documentation is wrong.

C.f. 
http://groups.google.com/groups?selm=mailman.1475.1092179147.5135.python-list%40python.org

And the relevant snippet from timeit.py:

if sys.platform == "win32":
     # On Windows, the best timer is time.clock()
     default_timer = time.clock
else:
     # On most other platforms the best timer is time.time()
     default_timer = time.time

I will note from personal experience that on Macs, time.clock is 
especially bad for benchmarking.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter