max limit for random()

[Shari Shark]

What is the max limit for the random function? I read the documentation that number are represented as 64-bit IEEE 754 bit when I tested the random function, it appears to be give me a max length of up to 10 digits.

[Henrik "The Developer" Lindqvist]

For a random integer with an upper limit just specify it +1 as the argument, e.g. random(101) for a value between 0 and 100, see: https://llamalab.com/automate/doc/function/random.html

Without an argument, the result is between 0 and 1 (exclusive), how many "digits" is has depends on how its displayed. For how its generated see: https://docs.oracle.com/javase/8/docs/api/index.html

[Shari Shark]

No this didn't answer the question. I know how to use the random function but I want to determine the max limit as I want to use it to iterate an array of dictionary words. Hence i need to know what is the max limit.

[Bushmills]

with an expression  "floor(random()*1.0E50)"  I get 50 digits pseudo random numbers, but I can't make a statement about quality of such long numbers.

[Shari Shark]

Using such a function would have the pitfall of locking the numbers to only 50 digits long. Hence lower numbers won't be generated at all. That's why I'm looking for the random function limits.

[Bushmills]

That's not correct.     random()  returns a pseudo random number between 0 and 1. For example,  0.0001.

0.0001*1E50 is 1E46  -  the chance to get a result with fewer digits is just lower, just as random(1000000) will most of the time produce a 6 digit result, simply because the count of numbers between 100000 and 999999 is higher than the count of numbers between 0 and 99999 - but it's not "locked" to 6 digits, just more probable.

[Bushmills]

Anyway, it appears that number of digits of random number returned by random() is 18 - what I tended to do with a system which provided random integers limited to 15 bits in a 16 bit system was  to generate numbers 0..9999 several times, and concatening their string representation formatted to 4 digits.  In Automate, that would be analog to doing   numberFormat(random(10000), "0000") ++ numberFormat(random(10000), "0000") ++ numberFormat(random(10000), "0000"), with the difference that you should be able to harvest 18 digits per step, rather than just four.

[Shari Shark]

Doing so is still not a good idea because the chance of getting low numbers are skewed towards 0. This will not give a equal distribution of numbers and as such, is flawed. I'm working on a passphrase generator and I'm not comfortable that the distribution is skewed in such a manner. Thanks for the suggestion though.

I guess I'll have to code in html/JavaScript and run the code in a dialog web block then.

[Bushmills]

Well, there is pseudo file /dev/random where you can pull good quality random from.

[Bushmills]

There's also /proc/sys/kernel/random/entropy_avail, which tells you how much entropy is left in /dev/random before reading from it goes into blocking mode until refilled.

[Ricardo Fernández Serrata]

`random()` has a flat probability distribution, and containers cannot have more than 2^32 elements. so `char_array[random(#char_array)]` is perfect for generating a random character. If you need to generate a password, use `/dev/urandom` file (/dev/random can get "empty" so it's not reliable) because "urandom" has cryptographically secure randomness quality. The number of digits is the decimal logarithm of a number, it's NOT the same as the numerical value. The average output of random is always equal to half its input (normalized/flat distribution), that's why the number of digits is almost the same as the digits in the input. If you want higher probability for lower numbers, then you're looking for a inverse logarithmic distribution, which looks like a curve when plotted graphically. A password gen. with "InvLog. dist.", would return text like "aabcbaaaabacbabaabcb" instead of "enchuwbrguydiuqpakxnznbyr"

[Ricardo Fernández Serrata]

This is a random string generator I made, that uses /dev/urandom as source: Truly Random String

[Ricardo Fernández Serrata]

Please read this: https://stackoverflow.com/a/10984975

TLDR: My implementation is currently biased, even though the source is cryptographically secure. Don't use my implementation if you must require an strictly uniform distribution

[Ricardo Fernández Serrata]

Wait, @Shari Shark is right, `random() * 1.0E50` always generates an integer because of fixed-precision, so using `floor` is useless. random() * pow(2, 53) always generates a random "safe int" (JS definition), but random() * pow(2, 54) always generates an even number because the mantissa cannot store the full int, so the exponent compensates, this means the min value (excluding 0) is 2. If we increase the multiplier, the number has more unconditional trailing zeros (in binary), which gives the illusion of generating more random data, when in fact the max number of random bits is always 53. I did some tests and it seems random(n) (where n is greater than 2^32) always generates an Int32, which has a max value of 2^31 - 1, and an average of 2^30-1. This is why a multiplier is needed to extract all 53 bits generated by the function, because giving an input arg forces the function to use 32bit mode, instead of generating 64bit floats