dannyflint

So i wanted to make a random number generator for a few reasons. Firstly to understand what is going on behind such objects, and secondly to replace lp.shhh and the like until I get paid and buy the litter pro package.

Is this the general kind of patch for such generation?

is-this-similar-or-better-than-random

I just thought, perhaps this is better still

Not sure what you're trying to do, but I use this a lot when I want a high resolution random float.

you patch actually does not generate a number between 0. and 1. : it create a list of 10 integers, that's very different !

here are a couple of examples showing how to generate random floats between 0. and 1. , using basic Max objects :

thanks guys, i'll check them out now. i just realised the error of my ways mathieu but now i have a different problem haha

Rodrigo, Firstly i just wanted to see/guess how the random object was actually made. didn't know if it was a noise based algorithm, expr based or what.

secondly i just figured that using a load of randoms to create 1 RNG would be even more random?

First of all, there is also the "Classic Litter" package, which is entirely abstraction based. Works with any and every Max release, and you can tweak things to your heart's content. And it is absolutely free. (Just please don't distribute modified versions -- I let someone do that once, and came to regret it bitterly.)

Sampling noise at non-deterministic intervals (as in Danny's first patch) is an interesting approach to trying to get random values without the problems of [random]. The [noise~]-[snapshot~] combo isn't going to give you a "better" RNG, if anything it's likely to have higher correlations than [random] and definitely has a shorter cycle before it starts repeating itself. OTOH, the sample jitter introduced by manually triggered 'bang' messages might make up for that. Someone would need to analyze the output to see if it really is an improvement, but it has a chance of being actually "random."

For the other proposals here: almost all the methods submitted share the same problem -- they rely on [random], which is simply not a good random number generator (RNG). (See note at the end of this message for gory details.) But whatever gets you through the night. Of these examples, the only one of real interest is the JavaScript-related approach. Neither JavaScript nor Java document the algorithm used by Math.random(), but there's a reasonable chance it's better than the atrocity from 

Mathieu's second example and Rodrigo's example both share a subtle problem in that the distribution is not quite flat. (But probably close enough for many people.)

As for [jit.noise], it's no better a RNG than [random]. Both use the same algorithm.

The standard [random] object (and apparently all the other pseudo-random objects in Max/MSP) uses code taken from the collection 

, and the algorithm provided there is known to be of low quality. The problems with the algorithm are [1] that the low-order bits are not random at all but highly deterministic; [2] that the cycle of the pseudo-random number generator is relatively short; and [3] that there are correlations in the sequence of pseudo-random numbers. The first problem is (largely) mitigated in the Max/MSP objects by truncating lower-order bits; the second problem is a question of how long a cycle you need (2^31 is long enough for a fair number of applications); the third problem won't be notice by most casual observers, although it can drive a statistics professional to the point of a nervous breakdown.

For the other proposals here: almost all the methods submitted share the same problem -- they rely on [random], which is simply not a good random number generator (RNG). (See note at the end of this message for gory details.) But whatever gets you through the night. Of these examples, the only one of real interest is the JavaScript-related approach. Neither JavaScript nor Java document the algorithm used by Math.random(), but there's a reasonable chance it's better than the atrocity from Numerical Recipes used in [random].

Mathieu's second example and Rodrigo's example both share a subtle problem in that the distribution is not quite flat. (But probably close enough for many people.) 

The standard [random] object (and apparently all the other pseudo-random objects in Max/MSP) uses code taken from the collection Numerical Recipes, and the algorithm provided there is known to be of low quality. The problems with the algorithm are [1] that the low-order bits  are not random at all but highly deterministic; [2] that the cycle of the pseudo-random number generator is relatively short; and [3] that there are correlations in the sequence of pseudo-random numbers. The first problem is (largely) mitigated in the Max/MSP objects by truncating lower-order bits; the second problem is a question of how long a cycle you need (2^31 is long enough for a fair number of applications); the third problem won't be notice by most casual observers, although it can drive a statistics professional to the point of a nervous breakdown.


This is a pretty cheap way of generating random numbers without the use of a ready-made pseudo random generator. It is called LCG(linear congruential generator). It's coefficients are chosen without though in this case. They are important and influence the quality of the outcome very much. Refer to Knuth for more information. (I posted a audio rate version of this somewhere on the forum, look for lcg noise)

not sure if i did multiplication+addition in the right order there.

cheers WOYTEG looks interesting, i can see some kind of 2,4,6,8 recursive pattern with the example coefficients, i'm guessing this is to do with the inclusion of the modulo operator in the algorithm

The general from of the linear congruence generator is 

I'm not sure where Knuth gives the particular values for 

 that you're using. Part of the problem with LC generators is that the quality varies so much depending on the parameter values. And, for all 

 is an incredibly important work, the section on Random Numbers is no longer quite state-of-the-art.

The general from of the linear congruence generator is X[n+1] == (a * X[n] + c) mod m. So multiply first, then add.

I'm not sure where Knuth gives the particular values for a, c, and m that you're using. Part of the problem with LC generators is that the quality varies so much depending on the parameter values. And, for all The Art of Computer Programming is an incredibly important work, the section on Random Numbers is no longer quite state-of-the-art.


Thanks for the informative post. I had come across some of that info at one point, but it's nice seeing it listed together.

A silly question, but why isn't the RNG in max updated? If it's just a matter of swapping out the algorithm, that seems like it would be trivial. I'm sure it still wouldn't be 'real' random, but at least 'better'.

I use that [random 1000000/1000000.] as my go-to random float generator and have never minded the results, but improvements are always welcome.

Thanks for the informative post. I had come across some of that info at one point, but it's nice seeing it listed together. 

A silly question, but why isn't the RNG in max updated? If it's just a matter of swapping out the algorithm, that seems like it would be trivial. I'm sure it still wouldn't be 'real' random, but at least 'better'. 

I use that [random 1000000/1000000.] as my go-to random float generator and have never minded the results, but improvements are always welcome.


@Peter, yes, I just wanted to add this here without much thought. Again the coefficients I used are in no sense good or proposed by anyone, I just picked anything.

Is this similar or better than random?