Random numbers greater than unsigned 32-bit?

[Ledigimate]

Dear LiveCoders,

LiveCode's random function can only generate numbers up to 4294967295 (unsigned 32-bit). I need to generate random numbers up to 274877906943 (38-bit). I have the following code:

Code: Select all

function randomNbit n
   -- Returns a random number between 1 and the maximum range of an unsigned n-bit number.
   local tRandomNumber, tRandomBit, tBit
   put 0 into tRandomNumber
   put random(n) into tRandomBit
   repeat with tBit = 0 to tRandomBit - 1
      add (random(2) - 1) * (2 ^ tBit) to tRandomNumber
   end repeat
   if tRandomNumber is 0 then put 1 into tRandomNumber
   return tRandomNumber
end randomNbit

But surely there must be a better way?

Regards,

Gerrie

[dunbarx]

Hi.

This may seem odd as a solution, but couldn't you just append one random number to another, and still be happy with the quality of the randomness?

Code: Select all

put random(4294967295) & random(4294967295)

Craig Newman

[Ledigimate]

I suppose I could, because uniform distribution isn't that important for my own purposes.
If, however, uniform distribution is important then your solution would not be suitable because uniform distribution is diminished with every addition.

C++11 lets one generate uniformly distributed floating point numbers ranging from 0 to 1 and with 53-bit precision, so one could write a LiveCode external for this, but I was hoping to avoid that.

Thanks for your input.

[dunbarx]

Ah, I see what you mean. Appending two random numbers has "two" limiting issues instead of one, a limiting issue being the max value of each appended portion. So there would be greater "order" in such a list, as opposed to a single random function with a larger max value.

Craig

[dunbarx]

Keeping this odd, it would not be hard, nor slow, to shuffle the two random strings instead of appending them. I am not sure how pure the randomness would be after such an operation, but it "feels" better.

Craig

[Ledigimate]

For my own purposes I suppose that could also suffice. The only real problem arises when uniform distribution is a must, in which case my original code is the closest thing I could think of.

It may be worth noting at this point that LiveCode can accurately compute unsigned integers only up to 57-bit precision. Subject to this limitation, my original code should not be used for generating random numbers requiring greater than 57-bit precision.

edit: changed 56-bit to 57-bit.

[[-hh]]

Without limit for the bits precision:
You could use, instead of a pseudo-random generator, if not Pi, Stoneham's constant that is base 2 normal.
Popularized article to that: http://www.huffingtonpost.com/david-h-b ... 85725.html.

Although it's not yet proven to be normal, the advantage of Pi is that a large number of digits is already (double-checked) computed.