Re^3: Is rand() really that slow or am I just using it wrong?

Fair point!

My confusion came from a recent experience of using rand() to generate 50,000 unique random numbers over a range of 1 to ~3,000,000,000. It worked fine on osx and linux, but not when I tested it on windows xp, where it struggled to ~32000 unique numbers and gave up. I can see though that if the numbers don't need to be unique and are within a small range, this wouldn't be a problem.

I still don't quite understand why this was only an issue on windows - will have to go and google it a bit more.

In any case, thanks for the correction!

Comment on Re^3: Is rand() really that slow or am I just using it wrong?

Replies are listed 'Best First'.
Re^4: Is rand() really that slow or am I just using it wrong? by BrowserUk (Patriarch) on Aug 09, 2013 at 00:03 UTC
I still don't quite understand why this was only an issue on windows The default rand (from the MS CRT) only produces 15-bits of randomness. Ie. `int( rand215 )` produces: 0 .. 32767. If you multiply by a larger factor, there are gaps in the range of values produced. Eg. `int( rand() 65535 )` produces 32767 unique values: 0 .. 65535 step 2. Hence your problem. Used as is, it will never produce 50,000 unique values. It can be used to provide a greater range with a little ingenuity. This packs 8 random bytes and unpack as a quad to produce a reasonable 64-bit rand that is still quicker than the MT: `sub myRand{ unpack('Q', pack'C8', map rand()256, 1 ..8) / 264 } undef%hash; say time; ++$hash{ int( 50000myRand() ) } while keys %has +h < 50000; say time;; 1376006416.04139 1376006418.40272 say ~~keys %hash;; 50000 print sum values %hash;; 543283` [download] Why this sad state persists in the MS CRT is because it seen as better to keep a seriously deficient rand function for trivial purposes and thus force users to seek out/write a better one for their particular serious purposes. That if they added (say) the MT, then people would either fall foul of or complain that it wasn't good enough for cryptographic purposes. And if they added a cryptographically-secure PRNG, then people would decry it as too slow for Monte-Carlo simulation purposes. Etc. Take that as you may. 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.	[reply] [d/l] [select]
Re^5: Is rand() really that slow or am I just using it wrong? by bulk88 (Priest) on Aug 10, 2013 at 21:54 UTC
https://rt.perl.org/rt3//Public/Bug/Display.html?id=115928	[reply]
Re^6: Is rand() really that slow or am I just using it wrong? by BrowserUk (Patriarch) on Aug 11, 2013 at 05:19 UTC
Interesting. I'd hope that if P5P decides to implement a single, consistent PRNG, that they opt for a fast, non-cryptogrpahic, well-known and tested, and 64-bit (not 48; at least on 64-bit versions) such as: MWC64X George Marsaglia's Reed And not just make one up. 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.	[reply]


Just another Perl shrine
	PerlMonks