but in this instance he was wrong.

Really? I added this sub:

sub shuffleEm {
    ( shuffle 1 .. $range )[ 0 .. $uSize ];
}
[download]

To your benchmark:

cmpthese( -1, {
    grepGen  => sub{ @grep  = grepGen();  },
    mapGen   => sub{ @map   = mapGen();   },
    smartGen => sub{ @smart = smartGen(); },
    shuffleEm=> sub{ @shuffled = shuffleEm() },
} );
[download]

And got these times:

C:\test>junk
             Rate   grepGen    mapGen  smartGen shuffleEm
grepGen    35.3/s        --      -51%      -97%     -100%
mapGen     72.6/s      106%        --      -94%     -100%
smartGen   1250/s     3439%     1621%        --      -95%
shuffleEm 26859/s    75977%    36902%     2049%        --
[download]

And that doesn't include the time and memory you waste building your pointless pool of 1M values.

But hey. It's your time you are wasting.

Yes, you added an efficient random number generator, but how do you think those "shuffled" results relate to what the other results represent? What do you think I am benchmarking? How do you interpret the results you posted?

You are pinpointing on a specific facet of my code and not looking at my code as a whole.

those "shuffled" results relate to what the other results represent?

They achieve the same results -- an array of 100 random integers in the range 1 ,, 120 -- 20 times more efficiently than your best attempt and nearly 100 times more efficiently than your worst; whilst saving 100MB of memory and the setup costs.

And the random selection of the values in that array is statistically fair with my method and not with yours.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The output of your program is meant to be a set of unique random numbers. How it is achieved is surely irrelevant (well almost). The code produced by BrowserUk delivers the same output as the previous 3 functions in a much shorter time.

I hope this is regarded as informative and educational. TBH, I didn't think of looking at the problem in the same way as BrowserUk did until he posted his idea. It often happens, especially round here, that people look at a problem completely differently from the way you do and achieve a much better result. It's happened a few times to me as well. I believe it's called an XY problem, when people come on here talking about how to do Y when they should really be talking about X, the step that got them to Y; and its the person who first spots that who often produces the most interesting answer.

If you are arguing that what he achieved was "against the rules" in some way, and you expected each function to have to sort through duplicates, then knock yourself out....:-)

A Monk aims to give answers to those who have none, and to learn from those who know more.