Predictable Randomization
Author
I''ve upgraded to Visual C++.NET from an ancient copy of Borland''s Turbo C. I wrote a function that used the "rand" function to generate random numbers from X-Y, but for any given set of X & Y, the function returns the same random variable over and over again, even if I seed the random number generator with the system time!!
For goodness sakes, someone help me out here! How do I generate random numbers that are actually random?
In case you need to know, the function uses the 0-32767 number returned, converts it to a double, rescales it by multiplying it by Y-X+1 and dividing it by 32767, rounds it off, and adds X. (At least I think this is how I wrote it; I''m not typing this post on my own computer.)
Is there a simpler system function, perhaps?
double num = (double)rand() / (double) RAND_MAX;int r = (num *((double)Y-X+1)) + X;return r
rand isn''t broken. Either you''re re-seeding the same value between each call, or your function to manipulate the number is aliasing everything to the same values. Post some code.
Author
As a fairly recent (started learning C two years ago, C++ this month) convert to Visual C++, I may not know what I''m doing, but this seems like a fairly clear-cut case of poor documentation to me.
Here''s the function:
Here''s the function:
#include <math.h>#include <stdlib.h>#include <time.h>int trueRand(int start, int finish){ srand( (unsigned)time( NULL ) ); double scaleConversion=RAND_MAX/(1+finish-start); int tmpRandom=rand(); tmpRandom=((tmpRandom+start)/scaleConversion)+start-1; return tmpRandom;}
Remove that srand call; it''s seeding the random number generator with the same value over and over.
And that''s not a "true" random number generator. This is.
And that''s not a "true" random number generator. This is.
quote:Original post by DuranStrife
As a fairly recent (started learning C two years ago, C++ this month) convert to Visual C++, I may not know what I''m doing, but this seems like a fairly clear-cut case of poor documentation to me.
The MSDN docs I own say this:
"The srand function sets the starting point for generating a series of pseudorandom integers."
Note the term ''series'', which implies that you call srand once for every X calls of rand. It may not be explicit what you need to do in your situation, but sometimes you do need to call srand several times, so it can hardly say "you must only call srand once".
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]
quote:Original post by Kylotan
The MSDN docs I own say this:
"The srand function sets the starting point for generating a series of pseudorandom integers."
Note the term ''series'', which implies that you call srand once for every X calls of rand.
I don''t see how A implies B here.
The docs merely explains what rand does: returns a pseudorandom series, meaning that from any starting seed the random numbers generated will be the same as subsequent calls to rand starting from the same seed. This doesn''t imply that you need to re-seed it every X calls. It wouldn''t hurt your randomness unless you seed it to the same value each time, but it would incur unnecessary overhead.
quote:
It may not be explicit what you need to do in your situation, but sometimes you do need to call srand several times, so it can hardly say "you must only call srand once".
The only times I can think you''d want to call srand are:
- beginning of the program.
- beginning of a "replay" or some function where you want to synchronize the pseudo-random sequence to a prior value.
- beginning of a "match" in a multiplayer game where it''s important that random events are generated in the same way on each player''s computer.
quote:Original post by Stoffel
This doesn''t imply that you need to re-seed it every X calls.
What I said was unclear. I didn''t mean that you need to re-seed it every X calls, I meant that there is a 1 to many relationship between srand and rand calls, as opposed to the 1 to 1 relationship that so many new programmers mistakenly use.
quote:The only times I can think you''d want to call srand are:
- beginning of the program.
- beginning of a "replay" or some function where you want to synchronize the pseudo-random sequence to a prior value.
- beginning of a "match" in a multiplayer game where it''s important that random events are generated in the same way on each player''s computer.
I use it to get reproducable ''random'' number sequences, meaning that someone with a 1% lockpicking skill on my RPG can''t just try 100 times (or thereabouts) and be sure to succeed.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]
quote:Original post by Kylotan
I use it to get reproducable ''random'' number sequences, meaning that someone with a 1% lockpicking skill on my RPG can''t just try 100 times (or thereabouts) and be sure to succeed.
Very nice, hadn''t thought of that application. That''s pretty ingenious.
Note that if a player has 1% lockpicking chance, it can mean three things:
1°/ If he finds a door, and tries to lockpick it 100 times and be sure to get it open.
2°/ If he finds 100 doors, he will be able to open only one of them.
3°/ You skipped the wrong mathematics course.
Cheating on the player will get the player angry, even if he doesn''t know it. Instead of preventing the player from opening the door JUST because you don''t want him to open the door, prevent him by telling him his lockpick is broken.
Moreover, if he cannot open a door just by lockpicking it 100 times, then his lockpicking chance is less than 1%. If you tell him it IS 1%, you''re just feeding the player false information. And if you''re not USING that percentage anyway, why do you show it? Wouldn''t it be easier and less rude to the player to use fuzzy values (for instance Lockpicking LVL 3)?
This is just the way I''m being frustrated when playing Diablo2: having 95% chances hitting some monster, and having 20-30 misses in a row against it...
Not so cheerful, ToohrVyk.
1°/ If he finds a door, and tries to lockpick it 100 times and be sure to get it open.
2°/ If he finds 100 doors, he will be able to open only one of them.
3°/ You skipped the wrong mathematics course.
Cheating on the player will get the player angry, even if he doesn''t know it. Instead of preventing the player from opening the door JUST because you don''t want him to open the door, prevent him by telling him his lockpick is broken.
Moreover, if he cannot open a door just by lockpicking it 100 times, then his lockpicking chance is less than 1%. If you tell him it IS 1%, you''re just feeding the player false information. And if you''re not USING that percentage anyway, why do you show it? Wouldn''t it be easier and less rude to the player to use fuzzy values (for instance Lockpicking LVL 3)?
This is just the way I''m being frustrated when playing Diablo2: having 95% chances hitting some monster, and having 20-30 misses in a row against it...
Not so cheerful, ToohrVyk.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
