tags:

views:

1482

answers:

5

Sometimes this piece of code always returns the same number (and sometimes it works fine):

(new Random()).nextInt(5)

I have suspicions where the problem is - it probably always creates a new Random with the same seed. So what would be the best solution:

  • create a static var for Random() and use it instead.
  • use Math.random() * 5 (looks like it uses a static var internally)

or something else? I don't need anything fancy just something that looks random.

Also it would be helpful if someone can explain why the original code sometimes works and sometimes it doesn't.

Thanks.

+5  A: 

The javadoc for java.util.Random is clear:

If two instances of Random are created with the same seed, and the same sequence of method calls is made for each, they will generate and return identical sequences of numbers.

The default constructor is also clear:

Creates a new random number generator. This constructor sets the seed of the random number generator to a value very likely to be distinct from any other invocation of this constructor.

In other words, no guarantees.

If you need a more random algorithm, use java.security.SecureRandom.

skaffman
Simply create one (and only one) instance of Random() will solve all of your randomness problems.
S.Lott
Perfectly clear. It doesn't explain though how come it returns the same value at different times (I am not calling them in parallel) and it doesn't say which seed is used by default.
serg
Indeed, which is why it shouldn't be used if you need to rely on a random number stream, and it also why it was not used by the java crypto packages.
skaffman
If you create multiple instances of SecureRandom you will compromise it's ability to deliver random numbers, just as much as Random.
S.Lott
+1  A: 

The Javadoc for Random isn't explicit about this, but the seed it uses is probably dependent on the current system time. It does state the random numbers will be the same for the same seed. If you use the call within the same millisecond, it will use the same seed. The best solution is probably to use a static Random object and use it for subsequent calls to the method.

Jorn
Not since Java 5.
erickson
I'd say he's probably using java 1.4 or earlier then.
Jorn
+1  A: 

If you're calling that line of code on successive lines, then yes, the two Random instances you're creating could be created with the same seed from the clock (the clock millisecond tick count is the default seed for Random objects). Almost universally, if an application needs multiple random numbers, you'd create one instance of Random and re-use it as often as you need.

Edit: Interesting note, The javadoc for Random has changed since 1.4.2, which explained that the clock is used as the default seed. Apparently, that's no longer a guarantee.

Edit #2: By the way, even with a properly seeded Random instance that you re-use, you'll still get the same random number as the previous call about 1/5 of the time when you call nextInt(5).

public static void main(String[] args) {
    Random rand = new Random();
    int count = 0;
    int trials = 10000;

    int current;
    int previous = rand.nextInt(5);

    for(int i=0; i < trials; ++i)
    {
        current = rand.nextInt(5);

        if( current == previous )
        {
            count++;
        }
    }

    System.out.println("Random int was the same as previous " + count +
                       " times out of " + trials + " tries.");
}
Bill the Lizard
"if an application needs" or "unless an application needs"?
S.Lott
@S.Lott: "if an application needs." I would only use his current implementation, (new Random()).nextInt(5), if my application needed exactly one random number. If I need more than one of them (which is almost universally the case, as you pointed out) I would keep that Random object around.
Bill the Lizard
+2  A: 

...Sometimes this piece of code [..] returns the same number (and sometimes it works fine)...

So it works randomly??? :) :) :)

Ok, ok, downvote me now!!

OscarRyz
I would say it randomly works :)
serg
+2  A: 

In Java 1.4, the default seed of of a new Random instance was specified in the API documentation to be the result of System.currentTimeMillis(). Obviously, a tight loop could create many Random() instances per tick, all having the same seed and all producing the same psuedo-random sequence. This was especially bad on some platforms, like Windows, where the clock resolution was poor (10 ms or greater).

Since Java 5, however, the seed is set "to a value very likely to be distinct" for each invocation of the default constructor. With a different seed for each Random instance, results should appear random as desired.

erickson