...also, unless I'm mistaking things, while selecting for a local min and max of 1 and 100 produces an initial 0..99 (from the modulus) which becomes 1..100 after the addition of the minimum value, if you had a min and max of 50 and 100, that would give you 50..149 as a final range, not what you want at all.
(Ignoring, for now, the modulus bias as already mentioned[1], you need to mod by the range (max-min+1) to get 0..range-1, then add the value of min. This sends the lower end to 0+min, which is min (as you want), and the upperend goes from range-1 (or (max-min+1)-1 to (max-min+1)-1+min, which comes out as plain "max".
When looking at "int r = min + rand() / ( RAND_MAX / ( max - min ) + 1 );", this looks
roughly the same, but I'm sure there's a value of one missing in there. I'd want to check if rand()
actually gives a RAND_MIN effective value of zero or one, and whether RAND_MAX is actually the top value, or whether that's the value above. I'm assuming we're talking C-family code here (sorry, missed any specifics on that), but not all language's versions of rand() behave in that same way.
Take Perl. I tend to do "rand()*$range-$min"-type code, with the output of the rand() with no specified parameter being 0<=x<1 (fractional), and letting the code do the integer conversion. It's
assumedely evenly split, and multipliying by the range (here in one term) and adding the minimum does (if I've not messed it up, Pedant's Curse, and all) what I want. I think. (I find I write code better
outside of examples.
)
Also in Perl you can alsk for rand(n) for an 0<=i<n value (integer output). So for 1..100 I'd ask for rand(100)+1, or 50..100 I'd go for rand(51)+50, or generically rand(max-min+1)+min). Or for a random item in an arbitrarily-sized list, $list[rand(@list)] returns the list item in 'one' step
[2]. A list @list being used in an integer situation (as it is in in rand()) will give the number of items in the list 'n'. The array itself is $list[0]..$list[n-1]. Which fits in fine with the rand(n) giving values from 0..n-1.
(Of course, some people make the mistake of doing $list[rand($#list)], which uses the term to return the top-end value (i.e. the n-1), which when plugged into the rand() only gives 0..n-
2 as choices. You
could use rand($#list+1), but why would you?)
[2] Assuming you've not messed with the 'zero' array item index, which is always possible, so this isn't a 'bulletproof' method unless you take the value of "$[" fromthe integer output of @list and add it back onto the rand() result within the array specification, but I've a
feeling that it's being deprecated from Perl, and I'd probably never (intentionally) use it.)
((Oh, and that's all assuming "between the values m and n" in the OQ is also qualified by the word "inclusively". The trouble with a lot of discussions about PRNG ranges is the "pass it a maximum and it'll give you a number between (0|1, depending on implementation) and that maximum"... Does it
actually give you that maximum? I'd be tempted to run a quick trial program to give me a running total of a million random numbers from the equivalent of "rand(10)" and see both if 10 is included in the end tota (and, if so, whether it's roughly in proportion to the other digits) and also whether zero is encountered (it'll probably be in proportion to all numbers <10, if it is, but again you can check that).
Or check your MyRand() function directly (you might as well functionise it, so that you don't have to worry about typing the maths right
every single time), so you make sure you've tuned it to your own expectations. Define an array that you know has indexes 0..10, plus an underflow and overflow counter (or another storage structure that will accept such information), all values initially zero, run your "MyRand(1,10)" a million times and each time increment the result, or the underflow/overflow variables if it's not a number that's
inclusively between one and ten. Then print the final tallies and see if they look Ok. Missing numbers (or zero present when you didn't expect it), any further underflow/overflow counts (you could have had a "minimumseen" and "maximumseen" instead, or as well, to help you tie down the
true range of your function) and any obvious imbalance in those that you
do get from the standard recorded set means you need to look at the maths surrounding the rand(), and (if applicable) within its parameter. !!Science!! Probably good practice.))
[1] Probably trivial for trivial usages of numbers that are several orders of magnitude lower than the maximum unprocessed random number, which is what you get if looking for values 1..100 on a system with a 16/32-bit top end Rand...
Author
Topic: Programming Help Thread (For Dummies) (Read 96117 times)