Random Number?

[Sickan]

@pitbuller

static final public int random()
{
  //todo change this to 2
  return 3;
}

Determined by a fair dice toss

[masteryoom]

@sproingie

Oh goody, another random thread. Rather than debate the finer points, let’s boil it down to some do’s and don’ts:

• Don’t use the static methods on Random. Create an instance of Random instead. If you’re saving a seed (e.g. for maps) then this advice isn’t really optional.
• If you don’t mind depending on java7, use ThreadLocalRandom.
• If you need a cryptographic random source, just stop and ask what you’re doing first. If you’re generating nonces for a web session, great, use SecureRandom. If you’re trying to actually encrypt something, then consider that if you’re expert enough to do crypto from scratch, you should be smart enough not to. Use a proper crypto implementation like BouncyCastle or Jasypt.

I do mind. I’m on Java 6. ;D

[Sammidysam]

Why don’t you update to Java 7?

[masteryoom]

I thinking of asking my dad to update my computer.

[Jimmt]

@masteryoom

I thinking of asking my dad to update my computer.

What does this have to do with Java 7?
oh you must be on a non-admin account. carry on

[Sickan]

@Jimmt

@masteryoom

I thinking of asking my dad to update my computer.

What does this have to do with Java 7?
oh you must be on a non-admin account. carry on

Or a gasp old Mac version!

Cheers!

[Roquen]

A basic summary of java.util.Random (and everything based on it is) is meh:

1. Random is thread safe. I’d guess that this was chosen to make it general purpose and so people could use it without any PRNG knowledge. Bad choice IMHO. You never ever want to call the same generator in more that one thread. It makes your code non-deterministic. While that might sound good for random numbers…that’s an illusion as it doesn’t improve the quality, it just makes your code hard (or near impossible) to debug. Secondly it means you’re hitting the same memory if two concurrent threads are generating at the same time which leads to cache thrashing. Bad bad. For ThreadLocalRandom this obviously isn’t an issue. Never use the same generator on more than one thread. Because of this you never what to use Math.random(), unless single-threaded. (That call really shouldn’t exist IHMO).

2. Neither the method nor the chosen constants were not “state-of-the-art” when it was first written. Far from in fact. My educated guess is it was thrown together in a rush pulling stuff from the then most recent version of Knuth’s Art of… book. Having said that, it was (and to an extent still is) a popular choice and at the time was a reasonable-ish one. While for gaming purposes this isn’t a big deal, but it’s kinda desirable to get the most bang for a given cost.

3. They use a rejection method to get integer results. This involves a modulo (slow…less so today, but still slow). The purpose of the rejection method is to improve uniformity of the result (equal probability of all values in the range) when performing the mod (so only for non-power-of-two ‘n’). The problems here are that, first mod-power-of-two LCG are poorish quality generators (again, more than sufficient for gaming purposes) and doing a rejection method with this rather silly. Secondly mod gives higher importance to low-bits, which for mod-power-of-two LCGs are the least random (you want to use high bits). But the biggest issue is…you don’t need to use a modulo anyway. Using fixed point (or floating point like some of the examples above) multiplication avoids the problem and it’s crazy faster.

4. The methods that returned floats was broken (improperly biased) for many versions

So, individually each of these is “meh”, but combined in a big palmslap.

OP: I should have mentioned, I threw this together for simulating die rolls: http://www.java-gaming.org/topics/dice-roller/26974/view.html.

[Varkas]

Thank you for the detailed explanation. Now I know better why you said, it’s bad. Particularly (3) doesn’t sound like there were experts at work, indeed.

[sproingie]

Everything Roquen says is spot on, but I’d add that j.u.Random is still good enough for your average RPG dice roller. Just don’t use the static methods, and never use it (or any other PRNG) where real money or sensitive info is on the line.