Zachary Seldess

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.

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. 

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. 

combined-intfloat-random-number-generator

> 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

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 

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 

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 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

>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...

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. 

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? 

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.

> 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

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

> 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

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

> 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 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

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

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

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...

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.

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...

(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...

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

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, means 15 ints from the range of 0 to 14. The 15, strictly speaking, neither specifies the upper or lower threshold. So what would mean? It can't mean 15.2 possibilities. It would be better to alter the Random object to behave like a typical random function - that is, specify a floor and ceiling.

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.

"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... ;-)"

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,  means 15 ints  from the range of 0 to 14. The 15, strictly speaking, neither specifies the upper or lower threshold. So what would  mean? It can't mean 15.2 possibilities. It would be better to alter the Random object to behave like a typical random function - that is, specify a floor and ceiling.

combined int/float random number generator