time output in milliseconds

[KevinL]

I'm writing a random number generator program and using time() to seed it.
I found out that time() output is in seconds. Do you know of another function
that outputs in thousands of seconds ? Thanx.

[Mike Wahler]

"KevinL" <Ke*******@ureach.com> wrote in message
news:83**************************@posting.google.c om...

I'm writing a random number generator program and using time() to seed it.
I found out that time() output is in seconds.
Perhaps it is for your implementation. But it's not necessarily
the case for all.

------------------------------------------------------------------------
ISO/IEC 9899:1999 (E)

7.23.2.4 The time function

Synopsis

1 #include <time.h>
time_t time(time_t *timer);

Description

2 The time function determines the current calendar time. The
encoding of the value is unspecified.

Returns

3 The time function returns the implementation's best approximation
to the current calendar time. The value (time_t)(-1) is returned
if the calendar time is not available. If timer is not a null
pointer, the return value is also assigned to the object it
points to.
------------------------------------------------------------------------
Do you know of another function
that outputs in thousands of seconds ? Thanx.

The standard C library does not provide one. Your implementation may
or may not. Check your documentation.

You might also want to investigate the 'clock()' function and the
'CLOCKS_PER_SEC' macro (also declared by <time.h>), which will
typically get you more granularity than 'time()'.

Is using 'time()' with a one-second resolution really insufficient
for your RNG seeding?

-Mike

[Richard Bos]

"Mike Wahler" <mk******@mkwahler.net> wrote:

You might also want to investigate the 'clock()' function and the
'CLOCKS_PER_SEC' macro (also declared by <time.h>), which will
typically get you more granularity than 'time()'.

Mind you, using clock() for seeding the RNG is not a good idea unless
you let the user burn some clock ticks before that. Since clock()'s
return value depends only on the processor time used, your seed will be
quite predictable if you always execute the same code before asking
clock() for a seed.

Richard

[Darrell Grainger]

On Wed, 30 Jun 2004, KevinL wrote:

I'm writing a random number generator program and using time() to seed
it. I found out that time() output is in seconds. Do you know of
another function that outputs in thousands of seconds ? Thanx.

First, you found out that your implementation of the C standard time()
function outputs in seconds. There is no guarantee this is true for all
implementations.

Second, there is no function guaranteed to output thousands of seconds.
There is a clock() function. It will return 1/CLOCKS_PER_SEC.
Additionally, this function will return the implementation's best
approximation to the processor time used. If the clock on your machine is
only accurate to a certain degree you might find this is off by a few
milliseconds.

Third, the clock() function is the number of 'ticks' since a predefined
time period. That time period could be a fixed date (just like time()
does) or it could be the start of program execution. If you have no user
input and no external events that change the run time of your application,
the clock() function could return the same value. Even worse, if there is
no support for clock() it will always return (clock_t)-1.

Finally, you never stated WHY you need something with better granularity
than the time() function. I cannot give you a function that is guaranteed
to return a value in thousands of seconds and without knowing why you need
that I cannot suggest an alternative.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov

[Keith Thompson]

da*****@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:
[...]

Third, the clock() function is the number of 'ticks' since a predefined
time period. That time period could be a fixed date (just like time()
does) or it could be the start of program execution. If you have no user
input and no external events that change the run time of your application,
the clock() function could return the same value. Even worse, if there is
no support for clock() it will always return (clock_t)-1.

Actually:

The clock function returns the implementation's best approximation
to the processor time used by the program since the beginning of
an implementation-defined era related only to the program
invocation.

That typically means that clock returns an estimate of the CPU time
used since program startup. I don't think an implementation that
returns the CPU time since a fixed date, or since system startup,
would be conforming (though I find the wording a bit vague).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Darrell Grainger]

On Fri, 2 Jul 2004, Keith Thompson wrote:

da*****@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:
[...]

Third, the clock() function is the number of 'ticks' since a predefined
time period. That time period could be a fixed date (just like time()
does) or it could be the start of program execution. If you have no user
input and no external events that change the run time of your application,
the clock() function could return the same value. Even worse, if there is
no support for clock() it will always return (clock_t)-1.

Actually:

The clock function returns the implementation's best approximation
to the processor time used by the program since the beginning of
an implementation-defined era related only to the program
invocation.

That typically means that clock returns an estimate of the CPU time
used since program startup. I don't think an implementation that
returns the CPU time since a fixed date, or since system startup,
would be conforming (though I find the wording a bit vague).

I'd be curious how others interpret this. I have seen systems where the
processor has a clock that needs to be manually reset. If you load an
application and check the clock it will give you different results
depending on what had been written previously.

In other words, if I load a program that prints the clock and it outputs
1000 then reload the program and run it again it could easily print out
2000 the next time. Is the compiler on this system non-conforming?

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov

[Alex Vinokur]

"Keith Thompson" <ks***@mib.org> wrote in message news:ln************@nuthaus.mib.org...
[snip]

Actually:

The clock function returns the implementation's best approximation
to the processor time used by the program since the beginning of
an implementation-defined era related only to the program
invocation.

That typically means that clock returns an estimate of the CPU time
used since program startup. I don't think an implementation that
returns the CPU time since a fixed date, or since system startup,
would be conforming (though I find the wording a bit vague).

[snip]

How can we know when the startup time ends and the runtime begins?
--
Alex Vinokur
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

[Jim]

On Fri, 02 Jul 2004 20:04:36 GMT, Keith Thompson <ks***@mib.org>
wrote:

da*****@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:
[...]

Third, the clock() function is the number of 'ticks' since a predefined
time period. That time period could be a fixed date (just like time()
does) or it could be the start of program execution. If you have no user
input and no external events that change the run time of your application,
the clock() function could return the same value. Even worse, if there is
no support for clock() it will always return (clock_t)-1.

In fact an implementation where it returns 0 for the first invocation
of clock() (ie, the epoch is when clock() was first called) and
increasing values after that, would be conforming.
Actually:

The clock function returns the implementation's best approximation
to the processor time used by the program since the beginning of
an implementation-defined era related only to the program
invocation.

That typically means that clock returns an estimate of the CPU time
used since program startup. I don't think an implementation that
returns the CPU time since a fixed date, or since system startup,
would be conforming (though I find the wording a bit vague).

It's difficult, since the only time they wouldn't be the same thing
(wall clock time and CPU time used) is if there were some other
'thing' eating CPU time at the same time as your application. Since
the C standard doesn't specify multitasking or interrupts, it's hard
to see what that thing might be. Hence one could argue that wall
clock and cpu time are the same thing. I know many implementations
that assume they are the same, but of course, that does not mean it's
conforming behaviour.

Jim

[Dan Pop]

In <2k************@uni-berlin.de> "Alex Vinokur" <al****@big.foot.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message news:ln************@nuthaus.mib.org...
[snip]

Actually:

The clock function returns the implementation's best approximation
to the processor time used by the program since the beginning of
an implementation-defined era related only to the program
invocation.

That typically means that clock returns an estimate of the CPU time
used since program startup. I don't think an implementation that
returns the CPU time since a fixed date, or since system startup,
would be conforming (though I find the wording a bit vague).

[snip]

How can we know when the startup time ends and the runtime begins?

Both start at the same time, as program startup is part of program
runtime.

But this is really splitting hairs, as long as the standard contains
wording like "the best approximation", which can mean anything at all.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

da*****@NOMORESPAMcs.utoronto.ca.com (Darrell Grainger) writes:
[...]

Third, the clock() function is the number of 'ticks' since a predefined
time period. That time period could be a fixed date (just like time()
does) or it could be the start of program execution. If you have no user
input and no external events that change the run time of your application,
the clock() function could return the same value. Even worse, if there is
no support for clock() it will always return (clock_t)-1.

Actually:

The clock function returns the implementation's best approximation
to the processor time used by the program since the beginning of
an implementation-defined era related only to the program
invocation.

That typically means that clock returns an estimate of the CPU time
used since program startup.

However, some implementations use the first clock() call as the era/epoch.
Probably not conforming, but how can a correct program tell the
difference?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <i6********************************@4ax.com> Jim <sp**@ihug.com.au> writes:

In fact an implementation where it returns 0 for the first invocation
of clock() (ie, the epoch is when clock() was first called) and
increasing values after that, would be conforming.

But *only* because of the "best approximation" wording, i.e. the
implementation is not able to approximate any better than that.

Otherwise the semantics of the standard are different from this
scenario: there is no guarantee that the time difference between
program startup and the first clock() call is constant, in which
case the epoch is not related "only to the program invocation",
as required by the standard.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de