### combined int/float random number generator

Hey everyone,

Here’s a convenient abstraction I’ve been using to do away with the tedium of scultping random ranges with the random object. Thought I would post it here, in case anyone else finds it useful.

This abstraction takes up to 3 arguments (min value, max value, number of decimal places). If one of the first two args is a float and/or if the 3rd arg is non-zero, output will be in floats, otherwise output will be in ints.

So you can, for example, quickly generate a random range between -1.246 and 2.0417 including numbers to the 6th decimal place with the following three args: -1.246 2.0417 6

I’ve attached the patch along with a js file (keep in same folder or in Max search path), and a .help file. Comments or suggestions are definitely welcome.

Zachary

Thanks for sharing,

Zachary Seldess schrieb:

> I’ve attached the patch along with a js file (keep in same folder or

> in Max search path), and a .help file. Comments or suggestions are

> definitely welcome.

The concept of decimal points is a bit strange and of course doesn’t

really work. Set a range from 1000 to 1200 and 2 decimal points and you

know what I mean… ;-)

I guess you just define the resolution of your random range, as only the

original random object is utilised. This will naturally lead to 32-bit

float resolution limits and alike…

But as you use a javascript anyway, why not doing the random in js as well?

By the way typechecking for int/float is easy with [route int float], if

you prefer to do it without js…

Stefan

–

Stefan Tiedje————x——-

–_____———–|————–

–(_|_ —-|—–|—–()——-

– _|_)—-|—–()————–

———-()——–www.ccmix.com

Thanks for the response Stefan.

>The concept of decimal points is a bit strange and of course >doesn’t really work. Set a range from 1000 to 1200 and 2 >decimal points and you know what I mean… ;-)

I don’t really know what you mean here. If I set a range from 1000 to 1200 and 2 decimal points, I get exactly what it is I’m after in that scenario — a random range of 20001 possibilities constrained between 1000 to 1200 (i.e. 1000.00, 1000.01, 1000.02… 1199.99 1200.0).

Likewise, If I set a range from 1000 to 1200 and 1 decimal, I want a random range of 2001 decimals constrained between 1000 to 1200 – which is what I get. This isn’t hard to achieve in max with the random object, but the point of the abstraction is to automate the process – using the random object.

>This will naturally lead to 32-bit float resolution limits and >alike…

And this is a good point. If you specify a range of possibilities larger than the 32-bit float will allow… it breaks! For example a range of -1000 to 1200 with 6 decimals, is too large – but 5 decimals is not. I suppose I should add a patch that checks this, modifies the range/# of decimals, and prints an error.

>But as you use a javascript anyway, why not doing the random >in js as well?

I suppose I should do this — 64-bit float resolution, right?

>By the way typechecking for int/float is easy with [route int >float], if you prefer to do it without js…

Doh! Thanks. ;)

Zachary

FWIW: the stock random object gives you at best 31 bits (not 32) and the low-order bits are not very random. You can’t actually count on more than 5 random digits.

If you’re thinking of rolling your own, reliable algorithms for generating random numbers are listed, for instance, in the bibliography to the Litter Power documentation.

Generating random numbers is too important to be left to chance.

Zachary Seldess schrieb:

> I don’t really know what you mean here. If I set a range from 1000 to

> 1200 and 2 decimal points, I get exactly what it is I’m after in that

> scenario — a random range of 20001 possibilities constrained

> between 1000 to 1200 (i.e. 1000.00, 1000.01, 1000.02… 1199.99

> 1200.0).

I get for example 1151.140015 or 1024.22998 in the help file on bottom.

Of course, if you have a float display correction activated a number box

will fool you, some of these two decimals numbers aren’t even

representable in 32-bit floating point. (Thats what I refer to

expectable… ;-)

> Likewise, If I set a range from 1000 to 1200 and 1 decimal, I want a

> random range of 2001 decimals constrained between 1000 to 1200 -

> which is what I get. This isn’t hard to achieve in max with the

> random object, but the point of the abstraction is to automate the

> process – using the random object.

Yes that was, what I was assuming, you create a limited number of

possible values which is not a continuum, and in most cases this is all

you need. But this has nothing to do with the number of decimals in a

base 10 number representation. For certain applications it might be

usefull…

> And this is a good point. If you specify a range of possibilities

> larger than the 32-bit float will allow… it breaks! For example a

> range of -1000 to 1200 with 6 decimals, is too large – but 5 decimals

> is not. I suppose I should add a patch that checks this, modifies the

> range/# of decimals, and prints an error.

I wouldn’t bother to be honest… ;-)

> I suppose I should do this — 64-bit float resolution, right?

At least a 32-bit continuum… On the other hand I would expect a new

random object in Max 5 might accept float arguments, I don’t understand

why it doesn’t anyway…

But to patch it, is trivial, if you don’t need type changes on the fly:

#P window setfont "Sans Serif" 9.;

#P window linecount 1;

#P newex 63 187 155 196617 scale 0 1073741823 $1 $2;

#P newex 63 144 103 196617 random 1073741824;

#P connect 0 0 1 0;

#P window clipboard copycount 2;

(for integer ranges you have to type the high number + 1, but thats

easy… ;-)

Also, there is nothing wrong with using Peter Castines objects, he is

not only the expert for random distributions but also for number

representations, I use random if the distribution is not critical, and

peters objects if I need it more precise and robust…

Stefan

–

Stefan Tiedje————x——-

–_____———–|————–

–(_|_ —-|—–|—–()——-

– _|_)—-|—–()————–

———-()——–www.ccmix.com

"I get for example 1151.140015 or 1024.22998 in the help file on bottom.

Of course, if you have a float display correction activated a number box

will fool you, some of these two decimals numbers aren’t even

representable in 32-bit floating point. (Thats what I refer to

expectable… ;-)"

I don’t mind being fooled when the number produced is the number I would expect in the abstract! But that’s just me. ;)

"At least a 32-bit continuum… On the other hand I would expect a new random object in Max 5 might accept float arguments, I don’t understand why it doesn’t anyway…"

Maybe I’m wrong here, but by adding a float argument you are changing the nature of the object itself in Max, because the argument represents (I should say seemingly represents, as I haven’t seen the code) the NUMBER of possibilities, and not the outer thresholds of a range. As you know,

So all I’ve done is added the floor/ceiling, but also kept a way to control number of possibilities when outputing floats (a conflation of the two approaches I guess). Take it or leave it.

"Also, there is nothing wrong with using Peter Castines objects, he is not only the expert for random distributions but also for number representations, I use random if the distribution is not critical, and peters objects if I need it more precise and robust…"

Peter’s objects are wonderful – I love them – thank you Peter! Also, there is nothing wrong with constructing your own simple idiosyncratic alternatives.

Zachary

sorry guys but i can’t find the patch!