• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Random Number Generation and Seed Value

 
Faraz Alig
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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: 48378
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your post is very difficult to read without [code] tags.
 
Henry Wong
author
Marshal
Pie
Posts: 20881
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 20493
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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: 3028
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 20493
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic