Printable View
I have found out a code that can give random numbers but I think this code gives a random number between 0-32767.
Could it be possible to get a random number between two values like for example: 0-30 ?
Code:#include <cstdlib>
#include <iostream>
using namespace std;
int main()
{
int random_integer = rand();
cout << random_integer << endl;
}
Yes
edit: Also check srand() and google/search forum for more information about random numbersCode:int random_integer = rand() % 31;
Thanks for the guidance :)
Code:int test = 0;
test = rand() % 30;
If you do % 30 you will get from 0-29. Since if rand() is 30 you will get 0 not 30. So you need 31
I see, I didn´t think about that. Thanks for the hint.
That said, I suggest reading Prelude's articles on Using rand() and Random Numbers.
This is generalyl a better random number generator than rand(). It only generates random bytes, so just generat 4 random bytes into a DWORD and then apply the aforementioned % 31.
And of course, you know that franse needs a better random number generator from what has been discussed so far?Quote:
Originally Posted by abachler
And "better" is of course a matter of how you defeine "better". "good" random numbers are important if you are working on something where the quality of the random numbers have a commercial consequence.
DWORD is not a standard type in anything other than Windows.
Doing a loop of 64K for EVERY BYTE seems excessive. Is this actually a recognized method of generating random numbers, or just something you thought up yourself? There are a huge number of GOOD random number generators that have had years of research to prove that they are good, the Mersenne-Twister being one of those: http://en.wikipedia.org/wiki/Mersenne_Twister. It uses less memory and less, and only loops around for 624 iterations every 624th random number - which is about 600 * 100 times better than your code.
--
Mats
DWORD is just a macro for unsigned int, to say 'well its only available in windows' is a bit facesious, since windows is argueably the most important operating system in existance today.
Besides, you can reduce the 64K loop to much smaller loop and still have random numbers of high enough quality for your purpose. Personally I use a much larger loop for some projects.
And mersenne twisters are very poor quality, they repeat in reasonable time. My code will not repeat during the lifetime of the universe, not even close.
And that is a good reason, you say? Why not use a typedef of your own that equates to unsigned int? - that way, the code is genuinely portable.Quote:
Originally Posted by abachler
Quote:
And mersenne twisters are very poor quality, they repeat in reasonable time. My code will not repeat during the lifetime of the universe, not even close.
So you have evidence to say that the MT paper:
http://www.math.sci.hiroshima-u.ac.j...earticles.html
that describes the initial implementation is not only wrong, but considerably wrong? According to that paper it has a period (which I take to be the point where it repeats) of 2^19937 - which is certainly considerably longer than I can expect to live. So where did they go wrong, seeing as this is a peer-reviewed paper, and implemented for MANY platforms in different languages - and all of the people that have been using it over the last 10 years are obviously not aware of this deficiency. Are you planning on to release a paper with your findings, so that we can learn what you know?
--
Mats
Nonetheless, it is not the only operating system in actual use today, and in fact is not dominant in some areas of computing.Quote:
Originally Posted by abachler
That is weird: all the literature I have read on it disagrees with you, and in fact state that the Mersenne Twister algorithms are high quality pseudo-random number generators for non-cryptographic use.Quote:
Originally Posted by abachler
However, that does not prove that it is a high quality pseudo-random number generator, e.g., a generator that merely increments the previously generated number will also theoretically never repeat (for eternity), but obviously it does not have very "random" characteristics. Is this algorithm in the published literature?Quote:
Originally Posted by abachler
Precisely.Quote:
Originally Posted by laserlight
Then you are mistaken: there are valid uses for non-cryptographic quality PRNGs, e.g., for simulations.Quote:
Originally Posted by abachler
How does the PRNG you suggested compare to say, Blum Blum Shub?
It was developed from similar foundations, but uses different methods. It has a cryptographic strength of greater than 512K bits.Quote:
Originally Posted by laserlight
I see. What publications are available that describe it and provide analyses of its quality?Quote:
Originally Posted by abachler
It may be due to my lack of expertise in this area, but that does not make sense to me. What does it mean for a cryptographically secure PRNG to have "a cryptographic strength of greater than 512K bits"?Quote:
Originally Posted by abachler
Well, a few things don't seem to fit quite well.Quote:
Originally Posted by abachler
First of all, no offense, but the code is quite horrible. It's mixed C with C++, missing indentation and, you know, I never knew 9 and 15 and 25 were prime numbers. You claim the algorithm is better than mersenne twister, but I doubt that. I'll try to find out what the cycle is. However, what good is a pseudo random number generator when you can't seed? Any value coming from it will be predictable, by simply re-running the sequence. And, as stated, your algorithm is horribly slow.
How secure really is your algorithm? Did you make it up yourself? Because my bet is: nowhere near as secure as mersenne twisters.
Also, if you like secure random numbers, how come you do advies to use "% 31"? Not really secure, is it?
Edit: Ok, analysing it, it won't repeat anytime soon, no ;). So security wise, should a proper seed be added, this may be OK. Even though I don't know enough to compare its security with mersenne twister.
9 and 15 and 25 dont get selected as prime, seeing as how it starts at 257 you must have misread the code. Its easily seeded by loading the public: array State, if you are going to give a critical analysis, at least bother to analyze the code first.Quote:
Originally Posted by EVOEx
the % 31 is specifically for the OP's needs
Ah, yes, I missed that line. I would've ran the code if I could, but "unfortunately" I run linux. Anyway, what about 289 then? And several others...Quote:
Originally Posted by abachler
meh, yeah i must have given you an older version of it, although it doesnt effect the security, since it doesnt require primes, only numbers that meet other requirements that all primes just happen to meet. The only non-primes that get selected are pseudo-primes that have roots of the form 2X+1, i.e. 4X^2 + 4X + 1.
AFAIK, the code can be run under linux with a few modifications, for example, you dont have toinclude windows.h and insert
For my purposes, since I use a much larger number of primes, I load them directly from a database of primes. This version is mainly for applications that dont have access to this database. I can give you the database if you want, but it is quite large at 775MB.Code:#define DWORD unsigned int
#define BYTE unsigned char
Here is the database, its compressed with RAR so you need to get WinRAR
Um, abachler, you still need to cite (and hopefully link to) those publications that describe and analyse this algorithm whose implementation you posted. At the moment all we have is your word that it is cryptographically secure, and to be honest the "cryptographic strength of greater than 512K bits" claim makes it sound like snake oil to me.
That said, I suspect that a cryptographically secure PRNG is not necessary. If one was necessary, then you should not suggest scaling down the number using modulo as it can affect the distribution.
laserlight, it is an unpublished algorithm of my own design, but I am qualified to design cryptographic algorithms. If you find some unknown security flaw let me know, but it is based on sound research. If you dont think it is, just try running it for a few hundred trillion years and see if it repeats. As pointed out already there are some potential optimizations, but I know of no security flaws, obviously or I would have fixed them.
Now, as it is a pseudo-random number generator, its security does depend on the randomness of the seed if you are using it for cryptographic purposes.
The OP specifically needs an output %31, yes it will affect the distribution and thus the modified output woudl not be truly random, but I suspect for the OP's uses non-repeateability is more important than perfect distribution. Repeatability is the only problem I have with rand(), although to be honest i havent checked rand()'s distribution.
If I were designing a version to specifically generate modulo 31 outputs, the distribution would be perfect, but since I supplied a version that generates modulo 256 outputs, it will not remain perfect after % 31.
The reason I did not give the exact strenght is because it depends upon the specific primes or pseudo-primes used, and since the version I posted and the version I use have different methods of generating the 'Primes' they would have different bit strengths, and thus an approximation is the closest I can come to describing them both. Since each prime used in this version adds a minimum of 8 bits of cryptographic strenght, I just did a quicky estimation of 8 * 65536 to get the 512K. Specifically the formula for the strenght is :
Unfortunately, I am not qualified to design cryptographic algorithms. What I do know is that it is generally accepted that - even when the algorithm is designed by an expert - extensive peer review is required before an algorithm can truly be considered strong. Clearly, as I am not qualified to perform such peer review, I would like to see what peer review has been done before we can really recommend it to the OP (if the OP even needs a cryptographically secure PRNG... at the moment we're guessing about almost everything).Quote:
Originally Posted by abachler
As I pointed out, this does not seem a particularly convincing proof that the algorithm is cryptographically secure since it addresses only one aspect, as important as it may be.Quote:
Originally Posted by abachler
However, there is a simple technique to avoid this that applies to non-cryptographic PRNGs as well: simply reduce the range into n "buckets", and discard those generated numbers that cannot fit into any "bucket".Quote:
Originally Posted by abachler
The algorithm for rand() is not specified by the C++ Standard (or the C Standard, for that matter), so you would only be checking a particular implementation of rand().Quote:
Originally Posted by abachler
Unfortunately, I still do not understand what this "bit strength" means with respect to cryptographic PRNGs. I would appreciate it if you could link me to an online source that explains it in detail.Quote:
Originally Posted by abachler
The strength is a definition of approximately how many unique states you would have to check to guarantee (100%) findign the exact state used to encrypt the original data. In modern cryptography it is generally defined in bits. So for example, if I was encoding a message using a Vigenere Cipher (a poor example but used for simplicity) using only a single letter as the key it would have 26 unique states (one for each possible letter). This would give it a strenght of ~4.7 bits, log2(26). If you used a 2 letter key then it woudl have ~9.4 bits, since there are now 676, 26 * 26, possible combinations. In modern cryptography the bit strength is used because the actual number of combinations are generally too large to write out. In modulus based cryptography, keys are not subject to the weaknesses of the Vigenere cipher, as any single bit change in the key significantly alters the encoding process.Quote:
Originally Posted by laserlight
The method I posted essentially uses a series (65536) of modulus counters to produce a highly parallel Linear Feedback Shift Register.