File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Random Number Generation and Seed Value Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Random Number Generation and Seed Value" Watch "Random Number Generation and Seed Value" New topic
Author

Random Number Generation and Seed Value

Faraz Alig
Greenhorn

Joined: Mar 14, 2010
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

Joined: Mar 14, 2010
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

Joined: Oct 13, 2005
Posts: 38472
    
  23
Your post is very difficult to read without [code] tags.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18757
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Sha Jar
Greenhorn

Joined: Mar 02, 2010
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

Joined: Oct 27, 2005
Posts: 19679
    
  18

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3012
    
  10
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

Joined: Oct 27, 2005
Posts: 19679
    
  18

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Random Number Generation and Seed Value