Liinear distribution of random numbers?

[lawrence.jones]

Which one?

The one from 4.4 BSD (and quite likely other releases, too):

return ((next = next * 1103515245 + 12345) % 0x80000000;

Note how they cleverly expanded the range of the traditional
implementation by increasing the modulus and removing the division that
was there to avoid returning the distressingly non-random low-order bits
of the internal state.

 

[Kaz Kylheku]

The one from 4.4 BSD (and quite likely other releases, too):

return ((next = next * 1103515245 + 12345) % 0x80000000;

Note how they cleverly expanded the range of the traditional

What's so clever about a textbook-grade linear congruential PRNG?

 

[Keith Thompson]

What's so clever about a textbook-grade linear congruential PRNG?

http://imagechan.com/images/a0202573cbc03a6a90a07840be0f9535.jpg

 

[Ben Bacarisse]

What's so clever about a textbook-grade linear congruential PRNG?

Irony. I think it comes over more clearly when the rest of the
sentence is not clipped!

 

[CBFalconer]

.... snip ...

What's so clever about a textbook-grade linear congruential PRNG?

I don't see why the standard on C systems isn't the Mersenne
twister. The code is freely available. I have published a version
intended for standard C systems - a copy of the source is contained
in nmalloc.zip, available on my page. I know of no areas where
this is not satisfactory.

 

[Ben Pfaff]

I don't see why the standard on C systems isn't the Mersenne
twister.

It doesn't really make sense to use the Mersenne Twister as the
implementation of rand(), since the seed provided to srand() has
only UINT_MAX + 1 possible values.

 

[CBFalconer]

It doesn't really make sense to use the Mersenne Twister as the
implementation of rand(), since the seed provided to srand() has
only UINT_MAX + 1 possible values.

Yes, but once seeded it has many more than UINT_MAX possible
outputs before it starts to repeat. I forget how many.

 

[Keith Thompson]

Yes, but once seeded it has many more than UINT_MAX possible
outputs before it starts to repeat. I forget how many.

But rand() it can only have UINT_MAX + 1 distinct sequences (each of
which is very long). The point, I think, is that using Mersenne
Twister to implement rand() limits it fairly severely relative to just
using Mersenne Twister by itself.

 

[Phil Carmody]

Precisely where did you find that generator? My MS Visual Studio 6
(circa 1998) source has:

seed' = seed * 214013 + 2531011
n' = (seed' / 65536) % 32768

which may not be stellar, but it's certainly not depressing or pitiful.
(And it appears VS 8 is still using the same generator.)

It was in Office 2003's Excel, I think.

Phil

 

[Phil Carmody]

I don't see why the standard on C systems isn't the Mersenne
twister. The code is freely available. I have published a version
intended for standard C systems - a copy of the source is contained
in nmalloc.zip, available on my page. I know of no areas where
this is not satisfactory.

Because
a) its memory footprint is very large compared to most alternatives
b) if you don't use it correctly it's crap, and
c) if you do use it correctly, it's got a run-time overhead as well
as a memory overhead.

People who think that psuedorandom number generators with longer
periods are better because of that property are usually quite
misguided about what actually makes a good PRNG.

Phil

 

[lawrence.jones]

It was in Office 2003's Excel, I think.

I didn't know that Excel counted as a C implementation. I'm sure there
are all kind of naff random number generators running around loose, but
the discussion here was specifically about ones used to implement the
standard C library rand() function.

 

[Phil Carmody]

I didn't know that Excel counted as a C implementation.

I didn't say it did. I merely said that MS had used it, without
specifying in what product.

Phil

 

[CBFalconer]

Because
a) its memory footprint is very large compared to most alternatives
b) if you don't use it correctly it's crap, and
c) if you do use it correctly, it's got a run-time overhead as well
as a memory overhead.

People who think that psuedorandom number generators with longer
periods are better because of that property are usually quite
misguided about what actually makes a good PRNG.

As I expect I am. The above is a good enough reason. Thanks.