an altenative PRNG seed (other than time(0))

okay, it's pretty standard practice to use

Code:

---

srand(static_cast<unsigned int>(time(0)));

---

to seed your PRNG (ignore the downsides to rand() for the moment).

but I was wondering if there was some other (portable) way to create another seed. for example, I have two programs, one a bubble sort and one a quicksort. when I run them like so:

Code:

---

jshao@MCP ~/Programming/C++/quickSort $ ./QuickSort && ../bubbleSort/BubbleSort

---

the PRNG creates the same set of values in each program. now I know that's to be expected because they're using the same seed in that context, but I was wondering if there was something else I could use in case I wanted to force two programs that seed their generators at the same time to end up with a different data set (making the code for each program different isn't an option - the only difference I want in the code is the sort() method of their respective classes)

basically, my question is this: I need to seed two generators (pretty much) at the same time and have them come up with different values, but the code for both needs to be the same (and it has to be portable, so /dev/random isn't acceptable), and I don't want to add any devices that create noise or anything of the sort...

I'm not sure if this is even really possible, becuase the only way I can think is to introduce another "random" variable into the equation, but that's not possible (for obvious reasons), and I can't think of another non-random variable (like time(0)) that would suffice...

edit: I know this isn't strictly C++, so if a mod feels there's a better place for this, please move it.

Pass the seed as a command line parameter, then do (crudely)
srand(atoi(argv[1]));

Code:

---

./QuickSort 1 && ../bubbleSort/BubbleSort 2

---

There are all sorts of ways of generating different numeric strings in the shell :)

Some sort of entropy pool instead of time(0)?

Quote:

---

Originally Posted by Salem

Pass the seed as a command line parameter, then do (crudely)

---

hmm... kinda hackish, but it may unfortunately be the best way...

Quote:

---

Originally Posted by Tonto

Some sort of entropy pool instead of time(0)?

---

thank you for summing up my question :D

There is no standard way of finding out information about whether other processes ran in the same second, so you always have the problem of time(NULL) returning the same result in two different processes

I mean, you could do this if you're on a *ix platform.

Code:

---

srand(static_cast<unsigned int>(time(0) + getpid()) );

---

Process ID's are unique amongst all active processes, and since all the low-numbered processes like 0 and 1 are permanent fixtures, the chance of time(0) + getpid() being the same in two processes is slim.

Or you could do this

Code:

---

./QuickSort && sleep 2 && ../bubbleSort/BubbleSort

---

To make sure there is always a delay between the two, and thus ensure that time(0) will return different results.

I knew there was no way to make sure time(0) returned different times when two processes used it at the same time - I was just hoping there was some other thing I could use (kinda like the PID idea)... oh well... thanks for your help anyway...

just an idea: would it be harmful to read some un-initialized memory?
I'm working on that now, but the OS keeps giving both programs the same memory address... :(

Another idea: use the filesize of argv[0] in conjunction with time(0).

except both programs have the same exact code. it's only the classes they use that are different... well, they're off by a few bytes, now that I think about it (the class names and headers are different)

I guess that could do, but I'd want something a little more... random than that... I thought about just creating a hash out of argv[0], but idk... it's just not satisfying :D

Quote:

---

I thought about just creating a hash out of argv[0], but idk... it's just not satisfying

---

I thought about that too, but that and my suggestion are flawed because both will fail might a user want to run the same program twice simultaneously.

I'm convinced using the app's process ID is the best way to go. Clearly there is no portable function that is platform-dependent (mutual exclusivity afforded by definition), but you can use getpid() for Unix/Linux and GetCurrentProcessId() for Windows.

I ran into this same problem once in a programming contest, the testing program ran the contest program from a batch and because the program ran so fast, every 2 or 3 runs would have the same result.

The solution is to use a higher resolution timer, I used a non-portable one, but a portable solution is to use clock() instead of time;

the following code produce 2 separate values for each line, which I would assume would run milliseconds apart from each other.

Code:

---

#include <ctime>
#include <iostream>
using namespace std;

int main()
{
        cout << clock () << endl;
        cout << clock () << endl;

}

---

Have you tried time( 1 ) ? :D


Quzah.

Quote:

---

Originally Posted by quzah

Have you tried time( 1 ) ? :D


Quzah.

---

I am guessing this is a joke, though I don't get it.

but in case it isn't, the time parameter is output, not input, so time(1) will give an error.

doesn't clock() return the amount of time the program has been running? in that case, even if there was a delay in between the programs, they should still be pretty close (with the exceptions of a few cpu cycles maybe)

According to cppreference clock() returns type clock_t which appears to be a typedef of type double as it also says that you can determine the amount of time in seconds by dividing the return value by CLOCKS_PER_SEC which apparently is defined by the OS somewhere and on POSIX compliant machines is defined as 1,000,000. So, if you want to cast type clock_t to type int so it can be used in srand() as a seed the difference between two successive calls in two successive lines of code will to small to make a difference. But, you could try multiplying by a factor of 10^7 and the differences even in just a line or two of code running may be enough to create different seeds in a random enough fashion to satisfy your requirements.

Yeah, but clock starts at 0, at program start, so testing it first is still going to produce much the same answer in both program instances.