Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > time

Reply
 
 
Bill Cunningham
Guest
Posts: n/a
 
      11-21-2012
Adam Wysocki wrote:

> Maybe adding process ID to the seed calculation would do the job.
>
> Instead of:
>
> srand(time(NULL))
>
> Use:
>
> srand(time(NULL) ^ getpid())
>
> Or even:
>
> srand(time(NULL) ^ (getpid() << 16))


Is that really that random? As long as a process has fork() 'ed and the
process is running it's pid isn't going to change is it until the system
kills it.btw to stay on-topic here that caret and those << indicators. I've
never seen that in C except maybe headers. Are they preprocessing tokens?

Bill


 
Reply With Quote
 
 
 
 
osmium
Guest
Posts: n/a
 
      11-21-2012
"Bill Cunningham" wrote:

> btw to stay on-topic here that caret and those << indicators. I've never
> seen that in C except maybe headers. Are they preprocessing tokens?


K&R has one of the best indexes I have ever seen in a technical book. It
starts on p 263. But the whole point of writing a book is for people to
*read* it. Try it some time.


 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      11-21-2012
"Bill Cunningham" <(E-Mail Removed)> writes:
> Adam Wysocki wrote:
>> Maybe adding process ID to the seed calculation would do the job.
>>
>> Instead of:
>>
>> srand(time(NULL))
>>
>> Use:
>>
>> srand(time(NULL) ^ getpid())
>>
>> Or even:
>>
>> srand(time(NULL) ^ (getpid() << 16))

>
> Is that really that random? As long as a process has fork() 'ed and the
> process is running it's pid isn't going to change is it until the system
> kills it.


You only call srand() once during the execution of the program.

> btw to stay on-topic here that caret and those << indicators. I've
> never seen that in C except maybe headers. Are they preprocessing tokens?


^ is the exclusive-or operator. << is the left-shift operator.
You'll find both in the index of the C standard and of K&R, which
you could have checked before wasting everyone's time by asking
about it here.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Bill Cunningham
Guest
Posts: n/a
 
      11-21-2012
Keith Thompson wrote:
> "Bill Cunningham" <(E-Mail Removed)> writes:
>> Adam Wysocki wrote:
>>> Maybe adding process ID to the seed calculation would do the job.
>>>
>>> Instead of:
>>>
>>> srand(time(NULL))
>>>
>>> Use:
>>>
>>> srand(time(NULL) ^ getpid())
>>>
>>> Or even:
>>>
>>> srand(time(NULL) ^ (getpid() << 16))

>>
>> Is that really that random? As long as a process has fork() 'ed
>> and the process is running it's pid isn't going to change is it
>> until the system kills it.

>
> You only call srand() once during the execution of the program.
>
>> btw to stay on-topic here that caret and those <<
>> indicators. I've never seen that in C except maybe headers. Are they
>> preprocessing tokens?

>
> ^ is the exclusive-or operator. << is the left-shift operator.
> You'll find both in the index of the C standard and of K&R, which
> you could have checked before wasting everyone's time by asking
> about it here.


Oh yes that's right. I was thinking shells and posix in this discussion
about arc4random. The bit-wise operators ok I know what they are. Fell
asleep for a minute.

Bill


 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      11-22-2012
On Wed, 21 Nov 2012 19:09:18 +0000, Adam Wysocki wrote:

>> If srand(time(NULL)) were used in that program, it would generate the
>> same exact sequence of random numbers for all requests received during
>> the same second.

>
> Maybe adding process ID to the seed calculation would do the job.


It would, and that's common. But there's no portable way to read the PID
(if such a concept even exists on a given platform).

The main issue is that time() appears to be about the only portable source
of non-determinism available, and it's typically rather weak.

On Wed, 21 Nov 2012 12:01:46 -0800, Keith Thompson wrote:

> If it's worth going to that much trouble, it's probably worth using a
> better random number generator than rand() (one provided by the
> implementation but not specified by the C standard).


But that doesn't do anything about the lack of non-determinism (entropy).
A better PRNG may give you better random numbers, but without something
other than time(), they'll be exactly the same random numbers as any
other invocation which gets the same value from time().

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-22-2012
Nobody <(E-Mail Removed)> writes:
> On Wed, 21 Nov 2012 19:09:18 +0000, Adam Wysocki wrote:

[...]
> On Wed, 21 Nov 2012 12:01:46 -0800, Keith Thompson wrote:
>> If it's worth going to that much trouble, it's probably worth using a
>> better random number generator than rand() (one provided by the
>> implementation but not specified by the C standard).

>
> But that doesn't do anything about the lack of non-determinism (entropy).
> A better PRNG may give you better random numbers, but without something
> other than time(), they'll be exactly the same random numbers as any
> other invocation which gets the same value from time().


Some PRNGs are self-seeding. For example, if you can read
data from /dev/random, you'll get numbers that are pretty much
cryptographically secure (and /dev/urandom is nearly as good and
much faster).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Rosario1903
Guest
Posts: n/a
 
      11-22-2012
On Wed, 21 Nov 2012 14:23:26 -0600, "osmium" wrote:

>K&R has one of the best indexes I have ever seen in a technical book.


yes
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-22-2012
(E-Mail Removed)d (Adam Wysocki) writes:

> James Kuyper <(E-Mail Removed)> wrote:
>
>> If srand(time(NULL)) were used in that program, it would generate
>> the same exact sequence of random numbers for all requests received
>> during the same second.

>
> Maybe adding process ID to the seed calculation would do the job.
>
> Instead of:
>
> srand(time(NULL))
>
> Use:
>
> srand(time(NULL) ^ getpid())
>
> Or even:
>
> srand(time(NULL) ^ (getpid() << 16))


There a small thing you can do that might help on some (possibly
theoretical) systems:

srand(time(NULL) * 1000ULL);

It's largely harmless on most systems since all you normally want is
something that varies using the least significant bits of the time and
1000 times that is as good anything else, but on a system with a
floating point time_t you get more of the variation.

(The use of ULL is just to make it unlikely that the multiplication will
overflow in the case of a signed integer time_t.)

--
Ben.
 
Reply With Quote
 
Adam Wysocki
Guest
Posts: n/a
 
      11-23-2012
Keith Thompson <(E-Mail Removed)> wrote:

>> srand(time(NULL) ^ (getpid() << 16))

>
> If it's worth going to that much trouble, it's probably worth using
> a better random number generator than rand() (one provided by the
> implementation but not specified by the C standard).


It might work when the only goal is to have different random seed in
processes forked many times per second.

AW
 
Reply With Quote
 
Adam Wysocki
Guest
Posts: n/a
 
      11-23-2012
Ben Bacarisse <(E-Mail Removed)> wrote:

> but on a system with a floating point time_t you get more of the
> variation.


POSIX says that "time_t and clock_t shall be integer or real-floating
types", so it is possible, but can you give an example of such system?
I've never seen one.

AW
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is time.time() < time.time() always true? flamesrock Python 8 11-24-2006 06:51 AM
Re: interpreting the fractional portion of time.clock() vs time.time(0measurements Peter Hansen Python 0 02-22-2006 02:02 PM
Re: interpreting the fractional portion of time.clock() vs time.time()measurements Peter Hansen Python 0 02-22-2006 12:03 AM
time.clock() or time.time() peterbe@gmail.com Python 8 08-05-2005 01:51 PM
delta time = time stop - time start engsol Python 2 01-26-2004 12:06 PM



Advertisments