石盼 wrote:
> The problem like this:
> t = time.clock()
> AttributeError: module 'time' has no attribute 'clock'
Quoting
https://docs.python.org/3/whatsnew/3.8.html#api-and-feature-removals
"""
The function time.clock() has been removed, after h
On 03/02/2020 08:04, 石盼 wrote:
Hello !
The problem like this:
RESTART: Shell
>>> import time
>>> t = time.clock()
Traceback (most recent call last):
F
Hello !
The problem like this:
RESTART: Shell
>>> import time
>>> t = time.clock()
Traceback (most recent call last):
File "", line 1, in
The carbonbased lifeform Tim Roberts inspired comp.lang.python with:
> Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>>
>>Hmmm, 10,000,000 cycles (40 ms @2.5GHz) is nowhere near the ~90,000
>>second jump in time.clock() output reported by the OP. I wonder if
>>
Don't forget that timeit module uses time.clock on windows as well:
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
http://svn.
Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>
>Hmmm, 10,000,000 cycles (40 ms @2.5GHz) is nowhere near the ~90,000
>second jump in time.clock() output reported by the OP. I wonder if
>there could be a different cause?
Just wild theorizing, but it's possible that they
;> Sample 24, at 152.0 seconds from start; Output power is: 8.936 dBm
> > [snip]
> >> But look at the timestamps of samples 21, 22 and 43.
> >> What is causing this?
> >> I've replaced the time.clock() with time.time(), and that seems to
> >> solv
Tim Roberts <[EMAIL PROTECTED]> wrote:
> Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
> >
> >time.clock() uses QueryPerformanceCounter under windows. There are
> >some known problems with that (eg with Dual core AMD processors).
> >
> >See http://m
Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>
>time.clock() uses QueryPerformanceCounter under windows. There are
>some known problems with that (eg with Dual core AMD processors).
>
>See http://msdn.microsoft.com/en-us/library/ms644904.aspx
>
>And in particular
>
>
estamps of samples 21, 22 and 43.
>> What is causing this?
>> I've replaced the time.clock() with time.time(), and that seems to
>> solve the problem, but I would like to know if it's something I
>> misunderstand or if it's a problem with the platform (Window
: 9.245 dBm
> Sample 24, at 152.0 seconds from start; Output power is: 8.936 dBm
[snip]
> But look at the timestamps of samples 21, 22 and 43.
> What is causing this?
> I've replaced the time.clock() with time.time(), and that seems to
> solve the problem, but I would
wer is: 8.964 dBm
Sample 44, at 284.4 seconds from start; Output power is: 9.276 dBm
Sample 45, at 291.0 seconds from start; Output power is: 8.932 dBm
Sample 46, at 297.6 seconds from start; Output power is: 9.158 dBm
But look at the timestamps of samples 21, 22 and 43.
What is causing this?
I'
On Mar 22, 10:03 pm, Tim Roberts <[EMAIL PROTECTED]> wrote:
> Godzilla <[EMAIL PROTECTED]> wrote:
>
> >Just found out that win32api.GetTickCount() returns a tick count in
> >milli-second since XP started. Not sure whether that is reliable.
> >Anyone uses that for calculating elapsed time?
>
> What
Godzilla <[EMAIL PROTECTED]> wrote:
>
>Just found out that win32api.GetTickCount() returns a tick count in
>milli-second since XP started. Not sure whether that is reliable.
>Anyone uses that for calculating elapsed time?
What do you mean by "reliable"? The tick count is updated as part of
schedu
cause it's easy to call. Note
that it returns a value in ms but the *precision* may be not so high.
Anyway I think your problem is in the code, not on time.clock()
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
; them gets called approximately the same time. Below is the updated
> code:
You still have race conditions:
> def setTime(self, state):
> if state == 1:
> self.checkTimeFlag = True
> self.timeStamp = time.clock()
> else:
> self.checkTimeFl
Just found out that win32api.GetTickCount() returns a tick count in
milli-second since XP started. Not sure whether that is reliable.
Anyone uses that for calculating elapsed time?
--
http://mail.python.org/mailman/listinfo/python-list
state == 1:
self.checkTimeFlag = True
self.timeStamp = time.clock()
else:
self.checkTimeFlag = False
def elapsedTime(self):
prevTime = time.clock()
while True:
curTime = time.clock()
timeDiff = (curTime - prevTime)
if time
On Mar 19, 11:17 pm, Godzilla <[EMAIL PROTECTED]> wrote:
> Hi John,
>
> I am using time.clock to calculate the elapsed time. Below is an
> example of what I was trying to do:
>
> import time
> import thread
Silly me, not being able to infer that from your initia
Godzilla <[EMAIL PROTECTED]> wrote:
>But the time.clock() sometimes return a value of between -3.5 to -4.5
>seconds backward.
There are race conditions in your code. In between the time you execute
"curTime = time.clock()" and calculate "curTime - self.timeStamp"
Hi John,
I am using time.clock to calculate the elapsed time. Below is an
example of what I was trying to do:
import time
import thread
class elapseTime:
def __init__(self, name=''):
self.name = name
self.timeStamp = None
self.checkTimeFl
On Mar 18, 9:43 pm, Godzilla <[EMAIL PROTECTED]> wrote:
> Thanks Roel. If there is a way to pass in the PRESERVE_PRECISION
> constant in the python time.clock library, that would be great
Re-read Roel's message. Something like PRESERVE_PRECISION is to be
passed to whatever is s
Thanks Roel. If there is a way to pass in the PRESERVE_PRECISION
constant in the python time.clock library, that would be great. But
I'm afraid it's not possible. I think I will change away from using
time.clock() from now on... seems too edgy to me.
Thank you for sharing your experien
Godzilla schreef:
> Hello,
>
> I have been reading a thread about time.clock() going backward, which
> is exactly what I am seeing... the thread generally leaning toward the
> problem is caused by multi-processor machines. But I am seeing it at a
> single CPU computer, and ru
Hello,
I have been reading a thread about time.clock() going backward, which
is exactly what I am seeing... the thread generally leaning toward the
problem is caused by multi-processor machines. But I am seeing it at a
single CPU computer, and running XP.
The error I am seeing between two very
On Jan 15, 4:50 am, [EMAIL PROTECTED] wrote:
> """
>
> time.clock() isn't high enough resolution for Ubuntu, and time.time()
> isn't
> high enough resolution on windows.
>
> Take a look at datetime. It is good to the micro-second on Linux an
[EMAIL PROTECTED] wrote:
> """
>
> time.clock() isn't high enough resolution for Ubuntu, and time.time()
> isn't > high enough resolution on windows.
>
> Take a look at datetime. It is good to the micro-second on Linux and
> milli-second o
"""
time.clock() isn't high enough resolution for Ubuntu, and time.time()
isn't
high enough resolution on windows.
Take a look at datetime. It is good to the micro-second on Linux and
milli-second on Windows.
"""
import datetime
begin_time=datetime.dat
Fredrik Lundh wrote:
> John Machin wrote:
>
>> AFAICT that was enough indication for most people to use time.clock on
>> all platforms ...
>
> which was unfortunate, given that time.clock() isn't even a proper clock
> on most Unix systems; it's a l
John Machin wrote:
> On Jan 14, 7:05 am, Ron Adam <[EMAIL PROTECTED]> wrote:
>> I'm having some cross platform issues with timing loops. It seems
>> time.time is better for some computers/platforms and time.clock others, but
>
> Care to explain why it seems
John Machin wrote:
> AFAICT that was enough indication for most people to use time.clock on
> all platforms ...
which was unfortunate, given that time.clock() isn't even a proper clock
on most Unix systems; it's a low-resolution sample counter that can
happily assign all time t
On Jan 14, 7:05 am, Ron Adam <[EMAIL PROTECTED]> wrote:
> I'm having some cross platform issues with timing loops. It seems
> time.time is better for some computers/platforms and time.clock others, but
Care to explain why it seems so?
> it's not always clear whi
I'm having some cross platform issues with timing loops. It seems
time.time is better for some computers/platforms and time.clock others, but
it's not always clear which, so I came up with the following to try to
determine which.
import time
# Determine if time.time is b
aFile, timeTaken" or "print >>dataFile,str(
> timeTaken)", but gives me 0.0.
> Please tell me what am I missing?
>
>
> t1 = time.clock()
> os.system(cmd)
>
> outputFile = str(i) + ".png"
>
> t2 = time.clo
On Mon, 22 Jan 2007 15:32:58 -0800, samuel.y.l.cheung wrote:
> File "/usr/lib/python2.4/timeit.py", line 188, in repeat
> t = self.timeit(number)
> File "/usr/lib/python2.4/timeit.py", line 161, in timeit
> timing = self.inner(it, self.timer)
> File "", line 6, in inner
> NameError:
Genellina wrote:
> At Monday 22/1/2007 19:05, [EMAIL PROTECTED] wrote:
>
> >I am following this python example trying to time how long does an
> >operation takes, like this:
> >
> >My question is why the content of the file (dataFile) is just '0.0'?
>
int >>dataFile, timeTaken" or "print >>dataFile,str(
> timeTaken)", but gives me 0.0.
> Please tell me what am I missing?
>
>
> t1 = time.clock()
> os.system(cmd)
>
> outputFile = str(i) + ".png"
&g
print >>dataFile,str(
timeTaken)", but gives me 0.0.
Please tell me what am I missing?
t1 = time.clock()
os.system(cmd)
outputFile = str(i) + ".png"
t2 = time.clock()
timeTaken = t2 - t1
allTimeTaken += timeTaken
pri
but gives me 0.0.
Please tell me what am I missing?
t1 = time.clock()
os.system(cmd)
outputFile = str(i) + ".png"
t2 = time.clock()
timeTaken = t2 - t1
allTimeTaken += timeTaken
print >>dataFile, timeTaken
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-08-29, Ralf Muschall <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>
>> This is a _Microsoft_Product_. There doesn't have to be a
>> reason for something to be done in a half-assed manner.
>
> No, it is a quantum effect. If the energy of a clock has a
> lower bound, there must be a no
Grant Edwards wrote:
> This is a _Microsoft_Product_. There doesn't have to be a
> reason for something to be done in a half-assed manner.
No, it is a quantum effect. If the energy of a clock has a
lower bound, there must be a nonzero probability for it to
run backwards.
See <[EMAIL PROTECTED]
"Grant Edwards" <[EMAIL PROTECTED]> Wrote:
| On 2006-08-28, Grant Edwards <[EMAIL PROTECTED]> wrote:
|
| >>> For processors that run at (say) 2GHz, several million (say 10
| >>> million) represents a difference of 10e6/2e9 = 0.005 seconds
| >>> between when the processors were sufficiently power
On 2006-08-28, Grant Edwards <[EMAIL PROTECTED]> wrote:
>>> For processors that run at (say) 2GHz, several million (say 10
>>> million) represents a difference of 10e6/2e9 = 0.005 seconds
>>> between when the processors were sufficiently powered up to
>>> start counting cycles.
>
>> If it were so,
> so if you really want to know, you may have to ask microsoft.
footnote: judging from
http://support.microsoft.com/?id=896256
this might be related to advanced power management features in XP. that
note also mentions a hotfix for this.
--
http://mail.python.org/mailman/listinfo/pytho
Claudio Grondi wrote:
> If it were so, than why can't the delta of time between the processors
> be set to exact zero?
someone just wrote:
This was a change from previous systems. On NT4 and Win2000, the
operating actually rewrote the cycle counters on the second (and
beyond) pr
On 2006-08-28, Claudio Grondi <[EMAIL PROTECTED]> wrote:
>> I don't see any claim above that they run at different speeds, only
>> that the counters are several million cycles apart, IOW running at the
>> same speed but with different initial values, or more likely starting
>> at different time
Rob Williscroft wrote:
> Claudio Grondi wrote in news:[EMAIL PROTECTED] in
> gmane.comp.python.general:
>
>
>>Tim Roberts wrote:
>>
>>>"Tim Peters" <[EMAIL PROTECTED]> wrote:
>
>
>>>It is much simpler than that. With a multiprocessor HAL, including
>>>on a dual-core or hyperthreaded system, Q
Claudio Grondi wrote in news:[EMAIL PROTECTED] in
gmane.comp.python.general:
> Tim Roberts wrote:
>> "Tim Peters" <[EMAIL PROTECTED]> wrote:
>>
>> It is much simpler than that. With a multiprocessor HAL, including
>> on a dual-core or hyperthreaded system, QueryPerformanceCounter
>> returns th
Tim Roberts wrote:
> "Tim Peters" <[EMAIL PROTECTED]> wrote:
>
>
>>[Giovanni Bajo[
>>
>>>>I experimented something very strange, a few days ago. I was debugging an
>>>>application at a customer's site, and the problem turned out
"Tim Peters" <[EMAIL PROTECTED]> wrote:
>[Giovanni Bajo[
>>> I experimented something very strange, a few days ago. I was debugging an
>>> application at a customer's site, and the problem turned out to be that
>>> time.clock() was going &quo
Claudio> such access results in adjusting the time a bit and leads
Claudio> eventually to such problems.
Wouldn't that affect time.time (time since the start of the Epoch), not
time.clock (cpu time used by the current process)?
Skip
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
>>>I experimented something very strange, a few days ago. I was debugging an
>>>application at a customer's site, and the problem turned out to be that
>>>time.clock() was going "backwards", that is it was sometimes
>>>(randomically)
>&
[Giovanni Bajo[
>> I experimented something very strange, a few days ago. I was debugging an
>> application at a customer's site, and the problem turned out to be that
>> time.clock() was going "backwards", that is it was sometimes
>> (randomically) returning
Terry Reedy wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>Hello,
>>
>>I experimented something very strange, a few days ago. I was debugging an
>>application at a customer's site, and the
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello,
>
> I experimented something very strange, a few days ago. I was debugging an
> application at a customer's site, and the problem turned out to be that
> time.clock() w
Giovanni Bajo wrote:
> Hello,
>
> I experimented something very strange, a few days ago. I was debugging an
> application at a customer's site, and the problem turned out to be that
> time.clock() was going "backwards", that is it was sometimes (randomically)
>
Op 25-aug-2006, om 16:13 heeft Giovanni Bajo het volgende geschreven:
> Hello,
>
> Is it possible this to be a bug in Python itself
> (maybe, shooting at the moon, in the conversion between the 64bit
> performance
> counter and the floating point representation retu
Hello,
I experimented something very strange, a few days ago. I was debugging an
application at a customer's site, and the problem turned out to be that
time.clock() was going "backwards", that is it was sometimes (randomically)
returning a floating point value which was "
t.
In linux at least time.time() has microsecond precision.
>>> for i in range(10): print "%20.6f" % time.time()
...
1153130111.566463
1153130111.566513
1153130111.566535
1153130111.566557
1153130111.566578
1153130111.566601
1153130111.566621
1153130111.
On 2006-07-14, Tobiah <[EMAIL PROTECTED]> wrote:
> So I "man 3 clock" and notice:
>
> The value returned is the CPU time used so far as a clock_t; to get
> the number
>of seconds used, divide by CLOCKS_PER_SEC.
>
> So, I'm wondering how to get that value from python.
What valu
Tobiah wrote:
> import time
>
> while 1:
> print time.clock()
>
> This gave me a stream of floats, the integer part of which
> only updated about every three seconds. Now, the manual
> also states:
>
> The precision, and in fact the very definit
Tobiah wrote:
> The manual says:
>
> On Unix, return the current processor time as a
> floating point number expressed in seconds.
>
> So I ran this program:
>
> #!/usr/bin/python
>
> import time
>
> while 1:
> print time.clock()
>
&g
Tobiah wrote:
> Am I barking up the wrong tree?
I don't think so, time.clock() has always worked fine for me. You can
also try time.time(). It is not as precise, but it might be sufficient
for your needs.
--
http://mail.python.org/mailman/listinfo/python-list
The manual says:
On Unix, return the current processor time as a
floating point number expressed in seconds.
So I ran this program:
#!/usr/bin/python
import time
while 1:
print time.clock()
This gave me a stream of floats, the integer part of which
only updated
john peter wrote:
> let's say i'm taking timing measurements in Windows XP
>
> t1 = time.clock()
> ...
> t2 = time.clock()
>
> t3 = t2 - t1 = say, 0.018
> what is the unit of measurement for t3? is it correct to say that t3 =
> 18 milliseconds?
> micro
let's say i'm taking timing measurements in Windows XP t1 = time.clock() ... t2 = time.clock() t3 = t2 - t1 = say, 0.018 what is the unit of measurement for t3? is it correct to say that t3 = 18 milliseconds? microsends? what if the timing function used for t1 and t2 was
john peter wrote:
>
> let's say i'm taking timing measurements in Windows XP
>
> t1 = time.clock()
> ...
> t2 = time.clock()
>
> t3 = t2 - t1 = say, 0.018
> what is the unit of measurement for t3? is it correct to say that t3 =
> 18 milliseconds
let's say i'm taking timing measurements in Windows XP t1 = time.clock() ... t2 = time.clock() t3 = t2 - t1 = say, 0.018what is the unit of measurement for t3? is it correct to say that t3 = 18 milliseconds? microseconds? w
[Russell Warren, playing w/ time.clock() on Windows]
> ...
> 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:
>
>
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. C
Russell Warren wrote:
> Does anyone know how long it takes for time.clock() to roll over under
> win32?
>
> I'm aware that it uses QueryPerformanceCounter under win32... when I've
> used this in the past (other languages) it is a great high-res 64-bit
> performance co
Does anyone know how long it takes for time.clock() to roll over under
win32?
I'm aware that it uses QueryPerformanceCounter under win32... when I've
used this in the past (other languages) it is a great high-res 64-bit
performance counter that doesn't roll-over for many (many)
1:07 pm >>>
I have to measure the time of a while loop, but with time.clock i
always get 0.0s, although python manual sais:
"this is the function to use for benchmarking Python or timing
algorithms"
So i tested timer functions capabilities with a short script:
import t
Woa, if you don't mind my asking, why do you do a time-cache on your
messages?
--
http://mail.python.org/mailman/listinfo/python-list
"Szabolcs Nagy" <[EMAIL PROTECTED]> writes:
> time.time seems much better solution, but python manual sais: "not all
> systems provide time with a better precision than 1 second"
>
> Should i use time.clock or time.time to be more crossplatform?
>
I have to measure the time of a while loop, but with time.clock i
always get 0.0s, although python manual sais:
"this is the function to use for benchmarking Python or timing
algorithms"
So i tested timer functions capabilities with a short script:
import time
import os
def test_timer
Shane Hathaway wrote:
> However, isn't this thoroughly un-Pythonic? No wonder people have to
> ask.
Only if they've never read K&R, and I thought that was compulsory! ;^)
There are a few python libraries, such as time and math, that are
basically just thin wrappers around standard C libraries.
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> I'm trying to benchmark some function calls for Zope project
Other folks have explained time() vs. clock(), so I'll leave that.
But rather than roll your own timer functions, consider using timeit.
--
http://mail.python.org/mailman/listinfo/pyth
Magnus Lycka wrote:
> Shane Hathaway wrote:
>
>>time.time() measures real time, while time.clock() measures the time the
>>CPU dedicates to your program.
>
>
> I suppose that varies with the platform... "help(time.clock)" says:
>
>
Magnus Lycka wrote:
> On Windows, you're likely to prefer time.clock(), to
> measure relative times, since time.time() will have too low resolution
> for measuring short thingies.
Specifically, using the NT/XP family of Windows operating systems
time.time() has a resolution of
Shane Hathaway wrote:
> time.time() measures real time, while time.clock() measures the time the
> CPU dedicates to your program.
I suppose that varies with the platform... "help(time.clock)" says:
Help on built-in function clock:
clock(...)
clock() -> floating point
[EMAIL PROTECTED] schrieb:
> What's the difference between time.clock() and time.time()
> (and please don't say clock() is the CPU clock and time() is the actual
> time because that doesn't help me at all :)
clock (depending on the platform ?) measures the time spent by y
[EMAIL PROTECTED] wrote:
> What's the difference between time.clock() and time.time()
> (and please don't say clock() is the CPU clock and time() is the actual
> time because that doesn't help me at all :)
>
> I'm trying to benchmark some function calls f
What's the difference between time.clock() and time.time()
(and please don't say clock() is the CPU clock and time() is the actual
time because that doesn't help me at all :)
I'm trying to benchmark some function calls for Zope project and when I
use t0=time.clock(); foo(); p
84 matches
Mail list logo
