Hello,
please explain me the syntax of how to generate random numbers between 65 and 75 in C?
Printable View
Hello,
please explain me the syntax of how to generate random numbers between 65 and 75 in C?
65 <= x <= 75
You might want to initialize the random seed to get a new sequence of pseudo-random numbers on every run.Code:int x = (rand() % 11) + 65;
The most common technique is:
Code:srand( time(NULL) );
I suggest reading Prelude's article on Using rand(). In particular, she points out weaknesses in xuftugulus' suggestions that you may want to be aware of.
Thanx for the very nice link laserlight. It really confuzzled me bedazzled head and i will use my own RNG from now on.
Although I'm sure the article is correct, I still have no idea why using (rand() % n) is wrong or what that whole thing about the low order bits was talking about? I also don't know why seeding it with time() wouldn't work very well (assuming you wait > 1 second between seeds)?Quote:
Originally Posted by laserlight
Suppose you want the range to be [0,3). Using the rand() % n method, n = 3.Quote:
I still have no idea why using (rand() % n) is wrong or what that whole thing about the low order bits was talking about?
Suppose also that RAND_MAX is 3. Then we have the following possibilities:
0 % 3 = 0
1 % 3 = 1
2 % 3 = 2
3 % 3 = 0
This means that half of the time you will get 0 as the random number generated. If you were looking for a uniform distribution, this obviously is not ideal.
Of course RAND_MAX is much larger than this, so the effects of the non-uniform distribution are less pronounced.
Prelude's suggestion does seed with the return value of time(), only that it seeds with a hash of the bytes of the value returned by time().Quote:
I also don't know why seeding it with time() wouldn't work very well (assuming you wait > 1 second between seeds)?
That's the part I don't get. How would that be any better than using time() by itself?Quote:
Originally Posted by laserlight
The article says the first random number could be the same for up to about 13 minutes by just using time(). Why?
To have guaranteed portability.Quote:
How would that be any better than using time() by itself?
Probably implementation dependent on how srand() works.Quote:
The article says the first random number could be the same for up to about 13 minutes by just using time(). Why?
I read the article to much time ago - so I do not remember the reason that Prelude was giving. But If we look at srand - it takes unsigned longQuote:
Originally Posted by cpjust
So when time() returns 8 bytes value - you will take only half of it... And this half could stay the same for very long time...
If you're only getting one random number -- it probably wouldn't make much of a difference. But if you're generating more than one number, starting a random number generator is better than just querying the time all the time. (Sorry.)Quote:
That's the part I don't get. How would that be any better than using time() by itself?
Actually, if you're only getting one number and that number doesn't change for, say, 17 minutes, that matters quite a lot. You can go through several die rolls with that kind of time. :)Quote:
Originally Posted by dwks
I wasn't talking about using time() as a random number. I was talking about using time() as the seed for srand().Quote:
Originally Posted by dwks
An 8 byte value? time() returns a time_t, which is a long (which is usually 4 bytes).Quote:
Originally Posted by vart
But either way, even if it took half, it would only take the lower half right?
>> An 8 byte value? time() returns a time_t, which is a long (which is usually 4 bytes).
time_t is only guaranteed to start at the epoch of computing (January 1, 1970) and be an arithmetic type. time_t as double would be an awkward, but Standards conforming implementation that isn't exactly mungeable into a unsigned int type. I haven't seen anything too different though and it is probably somewhat an irrational concern. OTOH, it is nice to have a seed which is not so bound to the clock: for one thing, hashing it makes it more difficult to predict rand()'s sequence as long as the hash algorithm is kept somewhat of a secret or is cryptographically strong anyway.
Once you figure out how a prng works and how it's seeded, predicting things is easy because you can imitate its' behavior, look for patterns, and cheat. :p
Only if you need numbers that are less pseudo-random and more random than rand() can provide.Quote:
It really confuzzled me bedazzled head and i will use my own RNG from now on.
Quote:
There is really nothing wrong with rand(), despite what you may be told. The problem is with the people who use it, and how they use it incorrectly and without having all of the facts.
Yes, I'm sorry, I misunderstood your post. And it was rather flawed anyway, as citizen pointed out. :)Quote:
I wasn't talking about using time() as a random number. I was talking about using time() as the seed for srand().
So . . . why is this
better than this?Code:unsigned time_seed()
{
time_t now = time ( 0 );
unsigned char *p = (unsigned char *)&now;
unsigned seed = 0;
size_t i;
for ( i = 0; i < sizeof now; i++ )
seed = seed * ( UCHAR_MAX + 2U ) + p[i];
return seed;
}
srand ( time_seed() );
That was your question, right?Code:srand((unsigned)time(0));
The general idea of a hash function is that any input will generate a unique output. Ever seen MD5 sums? Change one byte, and the entire thing changes. This particular hash function just happens to be very simplistic; but using this sort of thing for a random number generator seed would probably be a very good idea.
http://en.wikipedia.org/wiki/Cryptog..._hash_function
http://en.wikipedia.org/wiki/Hash_function
Maybe I'd understand this better if I knew how rand() & srand() actually work.
This all seems like it should be the job that srand() should be doing, so that passing it 123456 should generate a completely different set of random numbers than passing it 123457...
BTW, what does the 2U in that code mean? I've never seen anything like that in any code.