BTW, The sadam Library (see http://cycling74.com/forums/topic.php?id=42930 ) contains an object ([sadam.limits]) which will tell you the largest and smallest float and integer that can be represented by Max on different platforms.

No real need for trial-and-error. Max uses 32-bit integers and 32-bit floating point. Integers are in 2s-complement, so the largest value that can be represented is (2^31)-1. This holds for [random], [counter], [number], etc. etc. and for every other object dealing with ints. And this is true for both Mac OS and Windows (always has been).

The only exception is Max 6.1 in 64-bit mode, and here a bit of trial-and-error may prove interesting. As I understand the SDK, Max uses 64-bit atoms (ie, 64-bit ints, floats, pointers, etc.) But that doesn’t necessarily mean that absolutely all objects will automatically be working with 64-bit structures internally. In particular, the algorithm for [random] that DDZ documented here many years ago is intrinsically 32-bit (note: the algorithm would easily handle unsigned 32-bit ints, but Max interprets all ints as signed). It would be necessary to modify the calculations performed inside [random] to generate values outside the 32-bit range.

A quick look seems to indicate that, in Max 6.1 under 64-bit mode, it is possible to feed [random] a range parameter larger than (2^31)-1. However, it’s not immediately clear what this is doing! Take a look (don’t forget to set Max 6.1 to 64-bit mode, what happens in 32-bit mode is perfectly clear and a little bit boring):

— Pasted Max Patch, click to expand. —

Copy all of the following text. Then, in Max, select New From Clipboard.

All random number generators have some parameters. Range is only the most common (after distribution, which is also more-or-less constant for [random]).

The thing with [random 2147483647] is that you’re going to have to wait an awfully long time the highest value to come out (which, btw, is 2147483646… one less than the range). And just how long you’re going to have to wait is unpredictable (or, at least, very difficult to foresee).

David Zicarelli posted that [random] simply used the Linear Congruence algorithm as implemented in Numerical Recipes. This was many years ago, but there is no particular reason why this should have changed (although, as mentioned earlier, the 64-bit environment might be a motivation to update).

Yes, the Numerical Recipes implementation is a weak RNC (deterministic low-order bits, correlations in higher dimensions) but it is apparently deemed "good enough" for use in Max/MSP.

In case you don’t know this, there are much stronger RNCs implemented in the Litter Power Package, as well as pretty much every random number distribution known to humankind.