Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Random Number Generation

Reply
Thread Tools

Random Number Generation

 
 
adrian.bartholomew@gmail.com
Guest
Posts: n/a
 
      09-12-2008


public Deck() {
reset();
try {
random = SecureRandom.getInstance(RANDOM_ALGORITHM);
} catch (NoSuchAlgorithmException e) {
throw new NoSecureRandomException(e);
}
}

public final void reset() {
cards.clear();
cards.addAll(Card.allCards);
}

public void shuffle() {
for (int i=0; i<10; i++) {
random.setSeed(System.currentTimeMillis());
Collections.shuffle(cards, random);
}
}
......

The above code works, except that after a while i begin to see the
same patterns in hands dealt.
I can predict what the other hands would hold and can continue with
correct anticipatory play.
This should not be.
As you can see, I have even tried shuffling 10 times each time.

Any help would be appreciated.
 
Reply With Quote
 
 
 
 
zerg
Guest
Posts: n/a
 
      09-13-2008
Matt Humphrey wrote:
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>

>
> <snip code>
>
>> The above code works, except that after a while i begin to see the
>> same patterns in hands dealt.
>> I can predict what the other hands would hold and can continue with
>> correct anticipatory play.
>> This should not be.
>> As you can see, I have even tried shuffling 10 times each time.

>
> SecureRandom (and Random) are pseudo-random and will reproduce the same
> sequence for the same seed. Most likely your shuffle loop is so fast that
> the clock you're using for seeds does not change between iterations. Many
> PC-based millisecond clocks are only accurate to about 3 or 13 milliseconds,
> which is actually a very long time for fitting in calculations. Secure
> random includes a good pre-randomizer based on thread scheduling so try not
> setting a seed at all or set the seed once when the PRNG is created.


There's also System.nanoTime(), which is supposed to have a far higher
resolution than currentTimeMillis().
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      09-13-2008
On Fri, 12 Sep 2008 15:47:31 -0700 (PDT), http://www.velocityreviews.com/forums/(E-Mail Removed)
wrote, quoted or indirectly quoted someone who said :

> random.setSeed(System.currentTimeMillis());


don't do that. Set the seed only ONCE. If you don't want to
reproduce results, you don't even need a seed.

See http://mindprod.com/jgloss/pseudorandom.html
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      09-13-2008
(E-Mail Removed) wrote:
> public void shuffle() {
> for (int i=0; i<10; i++) {
> random.setSeed(System.currentTimeMillis());
> Collections.shuffle(cards, random);
> }
> }


From experience, I can tell you that you've shuffled at most twice (if
you're lucky), and probably once, assuming you have no more than 52
cards. A millisecond is an awful long time for a computer, and the
method does not in general have millisecond-scale resolution (10 and 16
are common, IIRC).

Resetting the seed so rapidly kills your entropy big time. Even if each
shuffle takes 1 ms, you'd essentially only see changes in the last 4-6
bits, throwing away several bits of good information. Don't reset the
seed, you don't need to.

Also, note that, although using the current time in milliseconds might
be fair entropy across invocations, using it multiple times in the same
invocation hurts entropy. The random number generator, without a seed,
will generate its own without any problems, and it does so in a far
smarter way.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Uwe Schmitt
Guest
Posts: n/a
 
      09-13-2008
On 13 Sep., 00:47, (E-Mail Removed) wrote:
> * * public Deck() {
> * * * * reset();
> * * * * try {
> * * * * * * random = SecureRandom.getInstance(RANDOM_ALGORITHM);
> * * * * } catch (NoSuchAlgorithmException e) {
> * * * * * * throw new NoSecureRandomException(e);
> * * * * }
> * * }
>
> * * public final void reset() {
> * * * * cards.clear();
> * * * * cards.addAll(Card.allCards);
> * * }
>
> * * public void shuffle() {
> * * * * for (int i=0; i<10; i++) {
> * * * * * * random.setSeed(System.currentTimeMillis());
> * * * * * * Collections.shuffle(cards, random);
> * * * * }
> * * }


You should call setSeed only once before shuffling. You can move it
outside the for loop, or into your constructor.

Greetings, Uwe
 
Reply With Quote
 
adrian.bartholomew@gmail.com
Guest
Posts: n/a
 
      09-13-2008
On Sep 12, 7:26 pm, Joshua Cranmer <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > public void shuffle() {
> > for (int i=0; i<10; i++) {
> > random.setSeed(System.currentTimeMillis());
> > Collections.shuffle(cards, random);
> > }
> > }

>
> From experience, I can tell you that you've shuffled at most twice (if
> you're lucky), and probably once, assuming you have no more than 52
> cards. A millisecond is an awful long time for a computer, and the
> method does not in general have millisecond-scale resolution (10 and 16
> are common, IIRC).
>
> Resetting the seed so rapidly kills your entropy big time. Even if each
> shuffle takes 1 ms, you'd essentially only see changes in the last 4-6
> bits, throwing away several bits of good information. Don't reset the
> seed, you don't need to.
>
> Also, note that, although using the current time in milliseconds might
> be fair entropy across invocations, using it multiple times in the same
> invocation hurts entropy. The random number generator, without a seed,
> will generate its own without any problems, and it does so in a far
> smarter way.
>
> --
> Beware of bugs in the above code; I have only proved it correct, not
> tried it. -- Donald E. Knuth


Thanks guys. So you're saying that I DONT even need a seed? And that
the seed itself is what's causing my predictability?
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      09-13-2008
(E-Mail Removed) wrote:
> Thanks guys. So you're saying that I DONT even need a seed? And that
> the seed itself is what's causing my predictability?


More accurately, the problem is that you are reseeding unnecessarily and
in such a manner that you are reseeding with the same value over and
over again under the illusion that it will increase randomness.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-13-2008
On Sat, 13 Sep 2008 10:30:47 -0700 (PDT), (E-Mail Removed)
wrote, quoted or indirectly quoted someone who said :

>Thanks guys. So you're saying that I DONT even need a seed? And that
>the seed itself is what's causing my predictability?


The only time you use a seed is if you want reproducibility. This can
be helpful in debugging or when you want others to get the exact same
results as you when they rerun.

If you want random effects, don't use a seed at all. The class will
start itself with a clever seed based on time and perhaps other random
factors.

Then there is something in between -- picking a "random" quote of the
day, which should pick the same quote any time the computation is done
that day. I talk about that too at
http://mindprod.com/jgloss/pseudorandom.html
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
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
Math.random() and Math.round(Math.random()) and Math.floor(Math.random()*2) VK Javascript 15 05-02-2010 03:43 PM
Random Number Generation dpi VHDL 4 03-26-2010 10:31 AM
random.random(), random not defined!? globalrev Python 4 04-20-2008 08:12 AM
Need Help With Random Number Generation Between Upper and Lower Bound ANM Java 2 03-07-2004 07:18 AM
random number generation and Monte Carlo simulation in C++ mescaline C++ 4 09-10-2003 09:01 PM



Advertisments