2

I'm trying to create a long (= 2^31) list of 32 and 16 bit random numbers. For 32 bits, I'm using lfsr113_Bits() from implementation of rand() , but I'm not sure what would be the best way to get a quality sequence of 16 bit numbers.

Unfortunately, the included in rand() is a bit short since as per documentation: "The rand function returns a pseudorandom integer in the range 0 to RAND_MAX (32767).

I'm thinking about using the lfsr113_Bits() and a union to get 16 bit numbers by utilizing: 

union {
    uint16  i16[2];
    uint32  i32;
} u; 

u.i32 = lfsr113_Bits();

And then use the number from either u.i16[0] or u.i16[1], or perhaps from both, one after another, but I have that gut feeling that the sequences obtained this way could be significantly worse than one obtained by using a native 16 bit generator.

Any idea on what would be the best approach to generate 16 bit random numbers?

Community
  • 1
  • 1
JSz
  • 127
  • 1
  • 3
  • Given a good PRNG, the split 32bit into two 16bit numbers is a good approach. If you want more quality you can do something like the **leapfrog-approach**. Every even-bit of some 32-bit sequence is within **A**, every odd-bit of some 32-bit sequence is within **B** (given a perfect PRNG there is no difference; in practice, the latter is often better). – sascha Oct 17 '16 at 01:25
  • Do you have access to `#include `? If so, you should _definitely_ be using that instead of `rand`. – Brian Rodriguez Oct 17 '16 at 01:41
  • That's **one of the worst SO duplicate-calls i ever saw**! (Greetings to the PRNG experts supporting this...) – sascha Oct 17 '16 at 01:44
  • @PatrickM'Bongo If you feel the need to add some approach as comment, why link to some arguably unrelated question? Also: this fully-automatic ```don't use rand/rand_s.../whatever``` stuff is really cheap (people used these decades ago, with success...; it's just a matter of understanding the limits). – sascha Oct 17 '16 at 01:49
  • @PatrickM'Bongo The most upvoted answer is generating some bounded integer(discrete)-distribution. No reasoning about wasting random-bits and such.... If someone does not understand the difference, he should not close the question or at least explain why he thinks that's a valid ```duplicate-call```. – sascha Oct 17 '16 at 01:55
  • 3
    You can't "waste random bits". Getting the distribution correct is the only concern. – Cat Plus Plus Oct 17 '16 at 01:59
  • @CatPlusPlus If that would be the only concern, everyone would use something based on crypto-hash-functions / block-ciphers. – sascha Oct 17 '16 at 02:00
  • @sascha OKAY I guess not using a garbage generator is also a concern, tho I've yet to see a non-garbage rand() so that advice is dumb, use PCG or xorshift or something. Definitely don't use slow-ass cipher based RNG for general purpose non-crypto stuff, that's also dumb. – Cat Plus Plus Oct 17 '16 at 02:07
  • Coincidentally I agree that the duplicate post is bad, but mostly because it recommends Mersenne Twister. But that's typical SO quality for ya. – Cat Plus Plus Oct 17 '16 at 02:10
  • @CatPlusPlus Even if it's unrelated: check some sampling-techniques for gaussians. The best methods (total time used) are wasting random bits (rejection-sampling). Of course it's also possible to increase the quality of any distribution delivered by some PRNG by using more samples and do some fancy stuff on it. Again... your *upvoted...* comment is not that valid anymore... (yeah, i know.... it's very general and you are getting punished for that...) – sascha Oct 17 '16 at 02:14
  • @CatPlusPlus But it's good to hear about your opinion about the duplicate-call. – sascha Oct 17 '16 at 02:15

0 Answers0