# Random Number Generation and Seed Value

Faraz Alig
Greenhorn
Posts: 24
Hi,

I am using the following code

public static void main(String[] args) {
// TODO Auto-generated method stub
Random random1 = new Random(3);
System.out.print("From random1: ");
for (int i = 0; i < 10; i++)
System.out.print(random1.nextInt(1000) + " ");
Random random2 = new Random(4);

System.out.print("\nFrom random2: ");
for (int i = 0; i < 10; i++)
System.out.print(random2.nextInt(1000) + " ");

and I am getting these set of values as result

From random1: 734 660 210 581 128 202 549 564 459 961
From random2: 862 452 303 558 767 105 911 846 462 427

Just wanted to know if these set of output nos are tied to seed 3
My requirement is that if I use the seed 3, why I am not getting any other set of results lets say

887 717 422 664 282 922 556 234 665 254

887 717 422 664 282 922 556 234 665 254

Not sure but let me know if this question really makes sence

- Faraz

Faraz Alig
Greenhorn
Posts: 24
Please ignore my previous post. This is the correct one

I am using this code

import java.util.Random;

public class RandomSeed {

/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
Random random1 = new Random(3);
System.out.print("From random1: ");
for (int i = 0; i < 10; i++)
System.out.print(random1.nextInt(1000) + " ");
Random random2 = new Random(3);

System.out.print("\nFrom random2: ");
for (int i = 0; i < 10; i++)
System.out.print(random2.nextInt(1000) + " ");
and getting the output as

From random1: 734 660 210 581 128 202 549 564 459 961
From random2: 734 660 210 581 128 202 549 564 459 961

Just wanted to know if these set of output nos are tied to seed 3
My requirement is that if I use the seed 3, why I am not getting any other set of results lets say

887 717 422 664 282 922 556 234 665 254

887 717 422 664 282 922 556 234 665 254

Not sure but let me know if this question really makes sense

- Faraz

Campbell Ritchie
Sheriff
Posts: 50284
80

Henry Wong
author
Marshal
Posts: 21518
84
That's how the Random class works. It isn't a real random number generator, but a formula that generates what seems to be random numbers. If you start from the same seed, you'll get the same series of seemingly random numbers.

You have two choices, have the two clients share the same random number generator, so that they can't get the same series of random numbers. Instead, they will get different portions of one series. Or have the two clients uses different seeds. The Random class no-arg constructor actually uses the system time as the initial seed, so using that constructor would also work.

Henry

Sha Jar
Greenhorn
Posts: 23
Henry Wong wrote:The Random class no-arg constructor actually uses the system time as the initial seed,

Not anymore, because of the problems associated with it.

Since Java 6 you're guaranteed a random sequence that's "very likely to be distinct from any other invocation of this constructor" which is much better.

Rob Spoor
Sheriff
Posts: 20671
65
Sha is almost right. Since Java 5.0 already this is part of the source code (lines 62-63 in Java 6, lines 63-64 in Java 5.0):
It still uses the system time, but a) no longer the time in milliseconds but in nanoseconds, and b) with a unique seed number. Well, as unique as any incremented long gets. After 2^64 calls you will get the same seed number. Fortunately the time in nanoseconds should then be different.

Mike Simmons
Ranch Hand
Posts: 3090
14
Rob Prime wrote:Sha is almost right.

Mmmm, she is right. She didn't say the system time had no role at all in the generation of Random instances. She said it was no longer used as the seed. Which is entirely true.

Rob Prime wrote:Well, as unique as any incremented long gets. After 2^64 calls you will get the same seed number. Fortunately the time in nanoseconds should then be different.

Not quite. The combination of the ++ operator with a volatile primitive is not atomic. Thus, it's possible for two different threads to observe the same value of seedUniquifier. Had they used AtomicLong rather than long for the seedUniquifier, as they did for the seed itself, there would've been no problem. Perhaps ther are minor performance benefits to using a primitive here, but it seems a strange choice, given that they used AtomicLong for the seed.

Rob Spoor
Sheriff
Posts: 20671
65
Mike Simmons wrote:
Rob Prime wrote:Sha is almost right.

Mmmm, she is right. She didn't say the system time had no role at all in the generation of Random instances. She said it was no longer used as the seed. Which is entirely true.

The almost was because she said since Java 6, while it was since Java 5.0. Yes, I'm a nitpicker. Deal with it

Rob Prime wrote:Well, as unique as any incremented long gets. After 2^64 calls you will get the same seed number. Fortunately the time in nanoseconds should then be different.

Not quite. The combination of the ++ operator with a volatile primitive is not atomic. Thus, it's possible for two different threads to observe the same value of seedUniquifier. Had they used AtomicLong rather than long for the seedUniquifier, as they did for the seed itself, there would've been no problem. Perhaps ther are minor performance benefits to using a primitive here, but it seems a strange choice, given that they used AtomicLong for the seed.

True, I forgot about thread safety. So yes, it is possible that two threads get the same seed. Fortunately, the changes are very small.