Code: Select all
#ifdef _a_real_c_compiler
#include <cstdlib>
#define Random(_n) rand()%(_n)
#endif
How fast is your code compared to Random(16)?
John Hansen
Code: Select all
#ifdef _a_real_c_compiler
#include <cstdlib>
#define Random(_n) rand()%(_n)
#endif
I would say it was your code if that is what you used to generate a random number between 0 and 3. Seriously? You can't be serious.muntoo wrote:Or maybe it was my code
(I might have done something dumb like:)Code: Select all
int rand4() { return(Random() >= 4 ? 3 : Random()); }
From what I can gather, people generally recommend not using rand()%n. See, for example, here:doc-helmut wrote:I will test the speed asap!
For dev C++ rand()%(x) is no problem - so why use this macro?
But Random(_n) and rand()%(_n) seem to be different in NXC.
why?
But anyway, it obviously seems to be relatively quite better than Lego rand(). My program only should show the Lego rand() issue, it should not claim that the Kernighan and Ritchie thing was the "best RNG ever".Wikipedia wrote:LCGs are fast and require minimal memory (typically 32 or 64 bits) to retain state. This makes them valuable for simulating multiple independent streams.
(picture: Hyperplanes of a linear congruential generator in three dimensions)
LCGs should not be used for applications where high-quality randomness is critical. For example, it is not suitable for a Monte Carlo simulation because of the serial correlation (among other things). They should also not be used for cryptographic applications; see cryptographically secure pseudo-random number generator for more suitable generators. If a linear congruential generator is seeded with a character and then iterated once, the result is a simple classical cipher called an affine cipher; this cipher is easily broken by standard frequency analysis.
LCGs tend to exhibit some severe defects. For instance, if an LCG is used to choose points in an n-dimensional space, the points will lie on, at most, m1/n hyperplanes (Marsaglia's Theorem, developed by George Marsaglia). This is due to serial correlation between successive values of the sequence Xn. The spectral test, which is a simple test of an LCG's quality, is based on this fact.
A further problem of LCGs is that the lower-order bits of the generated sequence have a far shorter period than the sequence as a whole if m is set to a power of 2. In general, the nth least significant digit in the base b representation of the output sequence, where bk = m for some integer k, repeats with at most period bn.
Nevertheless, LCGs may be a good option. For instance, in an embedded system, the amount of memory available is often severely limited. Similarly, in an environment such as a video game console taking a small number of high-order bits of an LCG may well suffice. The low-order bits of LCGs when m is a power of 2 should never be relied on for any degree of randomness whatsoever. Indeed, simply substituting 2n for the modulus term reveals that the low order bits go through very short cycles. In particular, any full-cycle LCG when m is a power of 2 will produce alternately odd and even results.
Code: Select all
j = rand() / ((RAND_MAX-1)/16+1);
Code: Select all
j = rand()%16;
?(RAND_MAX-1)/16+1) is optimized at compile-time to be 2048
Users browsing this forum: Semrush [Bot] and 2 guests