int randomNumber = (arc4random() % 83) + 1;
Is this the best way to generate "the most random" number? Or is there a better way to generate a random number?
When you use arc4random you avoid one pitfall of using % with linear congruential generators (which is the usual algorithm used by rand): the low-order bits aren't less random.
However, you still have truncation issues: i.e., because (1 << 32) % 83 is 77, that means that numbers between 0 and 76 appear (slightly) more frequently than numbers between 77 and 82. To avoid this, you should throw away the incoming value (i.e., call arc4random again) if it's above (1 << 32) / 83 * 83.
(I assume the range of arc4random is from 0 to 232-1. Adjust the above explanation accordingly.)
arc4random has a superior algorithm for generating random numbers based on the current time. There are other rand functions but they are not as good and require seeding.
The best random number generator I've ever seen (as well as a very clear definition of what random means) can be found in Stephen Wolfram's A New Kind of Science. He's been using a very simple cellular automata as his random number generator for decades in his Mathematica software program so it's been extremely well tested.
Related
I have smallish(?) sets (ranging in count from 0 to 100) of unsigned 32 bit integers. For a given set, I want to come up with minimal parameters to describe a minimal(istic) perfect hash of the given set. High level of the code I used to experiment with the idea ended up something like:
def murmur(key, seed=0x0):
// Implements 32bit murmur3 hash...
return theHashedKey
sampleInput = [18874481, 186646817, 201248225, 201248705, 201251025, 201251137, 201251185, 184472337, 186649073, 201248625, 201248721, 201251041, 201251153, 184473505, 186649089, 201248657, 201251009, 201251057, 201251169, 186646818, 201248226, 201248706, 201251026, 201251138, 201251186, 186649074, 201248626, 201248722, 201251042, 201251154, 186649090, 201248658, 201251010, 201251058, 201251170]
for seed in range(11111): // arbitrary upper seed limit
for modulus in range(10000):
hashSet = set((murmur(x, seed=seed) % modulus for x in sampleInput))
if len(hashSet) >= len(allValves):
print('minimal modulus', modulus, 'for seed', seed)
break
This is just basic pseudo code for a 2 axis brute force search. I add lines by keeping track of the different values, I can find seed and modulus values that give a perfect hash and then select the one with the smallest modulus.
It seems to me that there should be a more elegant/deterministic way to come up with these values? But that's where my math skills overflow.
I'm experimenting in Python right now, but ultimately want to implement something in C on a small embedded platform.
I'm running on R2012a version. I tried to write a function that imitates randi using rand (only rand), producing the same output when the same arguments are passed and the same seed is provided. I tried something with the command window and here's what I got:
>> s = rng;
>> R1 = randi([2 20], 3, 5)
R1 =
2 16 11 15 14
10 17 10 16 14
9 5 14 7 5
>> rng(s)
>> R2 = 2+18*rand(3, 5)
R2 =
2.6200 15.7793 10.8158 14.7686 14.2346
9.8974 16.3136 10.0206 15.5844 13.7918
8.8681 5.3637 13.6336 6.9685 4.9270
>>
A swift comparison led me to believe that there's some link between the two: each integer in R1 is within plus or minus unity from the corresponding element in R2. Nonetheless, I failed to go any further: I checked for ceiling, flooring, fixing and rounding but neither of them seems to work.
randi([2 20]) generates integers between 2 and 20, both included. That is, it can generate 19 different values, not 18.
19 * rand
generates values uniformly distributed within the half-open interval [0,19), flooring it gives you uniformly distributed integers in the range [0,18].
Thus, in general,
x = randi([a,b]]);
y = rand * (b-a+1) + a;
should yield numbers with the same property. From OP’s experiment it looks like they might generate the same sequence, but this cannot be guaranteed, and it likely doesn't.
Why? It is likely that randi is not implemented in terms of rand, but it’s underlying random generator, which produces integers. To go from a random integer x in a large range ([0,N-1]) to one in a small range ([0,n-1]), you would normally use the modulo operator (mod(x,N)) or a floored division like above, but remove a small subset of the values that skew the distribution. This other anser gives a detailed explanation. I like to think of it in terms of examples:
Say random values are in the range [0,2^16-1] (N=2^16) and you want values in the range [0,18] (n=19). mod(19,2^16)=5. That is, the largest 5 values that can be generated by the random number generator are mapped to the lowest 5 values of the output range (assuming the modulo method), leaving those numbers slightly more likely to be generated than the rest of the output range. These lowest 5 values have a chance floor(N/n)+1, whereas the rest has a chance floor(N/n). This is bad. [Using floored division instead of modulo yields a different distribution of the unevenness, but the end result is the same: some numbers are slightly more likely than others.]
To solve this issue, a correct implementation does as follows: if you get one of the values in the random generator that are floor(N/n)*n or higher, you need to throw it away and try again. This is a very small chance, of course, with a typical random number generator that uses N=2^64.
Though we don't know how randi is implemented, we can be fairly certain that it follows the correct implementation described here. So your sequence based on rand might be right for millions of numbers, but then start deviating.
Interestingly enough, Octave's randi is implemented as an M-file, so we can see how they do it. And it turns out it uses the wrong algorithm shown at the top of this answer, based on rand:
ri = imin + floor ( (imax-imin+1)*rand (varargin{:}) );
Thus, Octave's randi is biased!
This is my first thread here and I would like to ask you a couple of questions for universal hashing of integers.
A universal hashing algorithm is supposed to use this:
equation =
((a*x+b)mod p) mod m
a=random number from 1 to p-1
b=random number from 0 to p-1
x= the Key
p= a prime number >=m
m=the size of the array
I know the numbers I am going to hash are on the range of 1-2969.
But I cannot understand how to use this equation in order to make as low collisions as possible.
At the time a and b are random I cannot do anything about it.
My question is how I am supposed to pick the prime if I have more than one choice, the range of primes I can use are from 2 to 4999.
I tried to pick the first available that corresponds the requirements for the function but sometimes it can return negative numbers. I have searched on Google and Stackoverflow but I could not figure out what I am not doing wrong.
I am coding in C. Also, I can use only universal hashing.
Thank your for your time.
How do I Select a random element α ∈ Z∗p? P is a random 1024 bit prime BigInteger.
Here is how I find BigInteger p:
Random rand = new Random(new Date().getTime());
BigInteger p= new BigInteger(1024, rand);
while(!p.isProbablePrime(3))
{
BigInteger p= new BigInteger(1024, rand);
}
Thanks in advance.
I assume this is Java. In that case you are actually not picking a 1024 bit prime. You are picking a prime between 0 and $2^{1024}$. Take a look at the API though. There is a static method called some thing like probableprime which will give you a probable prime of a given bit length.
Now to sample a number $a \in Z_p$, you can use the method you used before to sample a random number $r$ between 0 and $2^{1024}$. Then check if $r < p$. If not resamble $r$ until you get an $r < p$. This is called rejection sampling, and should be reasonably efficient in this case.
You should, however, make sure that the randomness used by Java is good enough for your purpose.
I guess what you probably need in practice is a random k-bit prime (cf. Guut Boy's answer). Maurer published an algorithm of generating such a prime that is "provably" prime (in contrast to one that is obtained with the Miller-Rabin test). I have a Python implementation of Maurer's algorithm available at: http://s13.zetaboards.com/Crypto/topic/7234475/1/
I need some help on how to generate odd random numbers using Matlab. How do you generate odd random numbers within a given interval, say between 1 and 100?
Well, if I could generate EVEN random numbers within an interval, then I'd just add 1. :)
That is not as silly as it sounds.
Can you generate random integers? If you could, why not multiply by 2? Then you would have EVEN random integers. See above for what to do next.
There are tools in MATLAB to generate random integers in an interval. If not, then you could write your own trivially enough. For example, what does this do:
r = 1 + 2*floor(rand(N,1)*50);
Or this:
r = 1 + 2*randi([0 49], N,1);
Note that Rody edited this answer, but made a mistake when he did so when using randi. I've corrected the problem. Note that randi intentionally goes up to only 49 in its sampling as I have changed it. That works because 2*49 + 1 = 99.
So how about in the rand case? Why have I multiplied by 50 there, and not 49? This is taken from the doc for rand:
"r = rand(n) returns an n-by-n matrix containing pseudorandom values drawn from the standard uniform distribution on the open interval (0,1)."
So rand NEVER generates an exact 1. It can generate a number slightly smaller than 1, but never 1. So when I multiply by 50, this results in a number that is never exactly 50, but only potentially slightly less than 50. The floor then generates all integers between 0 and 49, with essentially equal probability. I suppose someone will point out that since 0 is never a possible result from rand, that the integer 0 will be under-sampled by this expression by an amount of the order of eps. If you will generate that many samples that you can see this extent of undersampling, then you will need a bigger, faster computer to do your work. :)