![]() In practice, this means that rand can only be implemented as a pseudorandom number generator (PRNG) rather than as a nondeterministic RNG, and that rand's PRNG algorithm can't differ in a given implementation whether the application calls srand or not. If srand is not called before rand is, rand behaves similarly as though srand(1) were first called.The fact that the algorithm and the seeding procedure for rand and srand are unspecified means that even reproducible "randomness" is not guaranteed between rand/ srand implementations, between versions of the same standard library, between operating systems, etc.(On the other hand, letting applications supply additional data to supplement "randomness", as in BCryptGenRandom, is less problematic even so, however, this is generally seen only in cryptographic RNGs.) For example, JavaScript's Math.random and FreeBSD's arc4random don't have this problem, since they don't allow applications to seed them for repeatable "randomness" - it's for exactly this reason that the V8 JavaScript engine was able to change its Math.random implementation to a variant of xorshift128+ while preserving backward compatibility. These two points, taken together, hamper the ability of implementations to improve on rand's implementation (e.g., to use a cryptographic random number generator or an otherwise "better" algorithm for producing pseudorandom numbers). allows that algorithm to be initialized with srand for repeatable "randomness".Uses an unspecified algorithm for the sequence of numbers it generates, yet.What is bad about rand/ srand is that rand. The general rule of thumb is that don't trust rand(), use your own pseudo-random number generator which fits your needs and usage requirements. Still, there are notable examples of excellent LCGs, like L'Ecuyer's 64 and 128 bits multiplicative linear congruential generators presented in Tables of Linear Congruential Generators of Different Sizes and Good Lattice Structure, Pierre L'Ecuyer, 1999. Some implementations try to reduce the lower bits problem by shifting the bits right by a pre-defined amount, however this kind of solution also reduces the range of the output. The lower bits of these generators have much lower statistical randomness than the higher bits and the generated numbers can produce visible lattice and/or planar structures (the best example of that is the famous RANDU PRNG). Rand() is completely implementation defined, but historically it is implemented as a Linear Congruential Generator (LCG), which is usually a fast, but notoriously bad class of PRNGs. Actually, there are very good PRNGs, which are statistically hard or impossible to distinguish from true random numbers. Rand() is a pseudo-random number generator (PRNG), but this doesn't mean it must be bad. None of the answers here explains the real reason of being rand() bad. In modern C++ you should definitely use the C++ library from which comes with multiple random well-defined engines and various distributions for integer and floating point types. There are other answers here detailing this better than I could, so please read them. But the issue with this is that unless RAND_MAX is an exact multiple of 1018 you won't get an uniform distribution.Īnother issue is the Quality of Implementation of rand. A commonly (and naive) used formula is rand() % 1018. But most often you need a random number in a specific interval. It is uniform in this interval, which means that each number in this interval has the same probability to appear. The most visible problem of it is that it lacks a distribution engine: rand gives you a number in interval. It also greatly complicates multithreaded tasks. This makes it impossible to use multiple random engines at the same time. ![]() One issue is that it has a global state (set by srand). And here we arrive to the real troubles with the C random library (which includes rand and srand) that are specific to it and make it obsolete (a.k.a.: the reasons you should never use rand and the C random library). So you analyzed your problem and you conclude a pseudo-random generator is the solution. A true random generator has its own issues (efficiency, implementation, entropy) so for problems that are not security related most often a pseudo-random generator is used. And there are most certainly a lot of classes of problems where a pseudo-random generator is acceptable. It's an issue with any pseudo-random generator. This makes it not suitable for certain applications where security is of a great concern. For a given seed it will always give the same sequence (assuming the same implementation). First, rand is a pseudorandom number generator. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |