I don't think that's a good idea. More than 80% of your random numbers will be bigger than 100, which means none will be picked.
This also explains why you have problems inverting this "solution".
Furthermore a linear search in the hash won't be truly random, because the hash order is fixed within the duration of a run. This will result in a disproportionate representation of the early entries.
Solution is easy:
sort the N entries and chose a modified random function which favors one end of the range, like $i = int $N * rand() ** $e and $j = $N - 1 - $i for index in your sorted list. The way you chose $e > 1 will decide about the degree of bias ( $e=1 means no bias)
Just test the distribution of the indices:
DB<41> %h=();$e=3; $N=10; $h{ int $N * rand() **$e }++ for 1..10000 DB<42> x \%h 0 HASH(0x2f25fe8) 0 => 4670 1 => 1215 2 => 838 3 => 686 4 => 550 5 => 484 6 => 407 7 => 388 8 => 426 9 => 336 DB<43>
In this example the first 10% are more than 10 times more likely to be picked than the last 10%.
Of course YMMV about the distribution you prefer, but the basic idea is the same.
Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery
In reply to Re: Randomly choosing from a set of alternatives with varying popularity
by LanX
in thread Randomly choosing from a set of alternatives with varying popularity
by ibm1620
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |