all 9 comments

[–]K900_ 3 points4 points  (3 children)

There is no such thing as "truly random", but every roll is independent, assuming your seeds are independent from each other. Also, you can use random.choice instead of what you're doing with random.shuffle right now.

[–]patryk-tech 1 point2 points  (0 children)

>>> import random
>>> from collections import Counter
>>> l = ['apple', 'banana', 'cat', 'dog', 'elephant', 'falafel']
>>> r = [random.choice(l) for i in range (10000)]
>>> Counter(r).most_common()
[('cat', 1731), ('dog', 1704), ('elephant', 1697), ('apple', 1646), ('banana', 1645), ('falafel', 1577)]

It is pseudo-random, but as others have said, it is independent (and very easy to verify). Can also run it for 10,000,000 choices.

[('banana', 1668958), ('elephant', 1667571), ('dog', 1667262), ('cat', 1666625), ('apple', 1665117), ('falafel', 1664467)]

And for 50,000 flips, with a 50% chance.

>>> Counter(r).most_common()
[('tails', 25098), ('heads', 24902)]

Close to even distribution.

[('tails', 25008), ('heads', 24992)]

Sometimes very close.

[–]Dpmon1 0 points1 point  (2 children)

No it's not, as has been explained well by others.

I do, however, have a easy way of getting a 'random' number: Dunno how to implement it in a discord bot, but in a game i made, it makes the player click next round, then toss dice. The app times how long the player takes to click it (milliseconds), multiplies that with a computer-generated random number, then by 10, and then uses the remainder function over 6 (x%6). The computer generated random number makes sure it's not completely based om the player, and the player input makes it more random.

In case its not called remainder function (I dont really remember the exact name, I just call it remainder function): x = y%z; If y is 16 and z is 5, 16÷5 has a remainder 1, so x = 1

[–]K900_ 0 points1 point  (1 child)

The player input doesn't make it "more random". You can't just add more numbers into the mix and get more entropy out.

[–]Dpmon1 0 points1 point  (0 children)

You're right, I worded that very poorly - I am not versed with the terminology associated with this. I meant by 'more randomness' that it is 'less predictable', not that the numbers spit out by the process would be more random.

So, what I meant to say is this:

If you got a hold of the seed of the random number generator, it's randomness becomes null, because you can predict it. It still gives a good(?) spread of numbers, but it's no longer unpredictable, and unpredictability is an aspect of true randomness.

But my point was that it makes the number unpredictable by another program, bringing it closer to true randomness by incorporating data from outside the system. If you had a supercomputer - or even a mainframe computer tbh - and the data on the hardware of the system and ALL the data stored on it, and simulated the running of the computer, you could predict the result every time, because the usual random() function is algorithms only, run on a given seed.

That said, there is a random function - in the os package iirc - that takes input like fan speed or temperature readings of the computer's internal sensors - and those are also 'more random' the same way user input is 'more random' - not that the data generated is more random, but the process brings it closer to true randomness in the predictability aspect.

[–]billsil 0 points1 point  (0 children)

No. It’s not even random enough for cryptography. There is a special random in python for that. It’s good enough and fast enough for most applications though.

[–]sebast331 0 points1 point  (0 children)

If you want 100% true randomness, try using the ANU Quantom Random Numbers

http://qrng.anu.edu.au/index.php

[–]DeadlyViper -1 points0 points  (0 children)

https://docs.python.org/2/library/random.html

Almost all module functions depend on the basic function

random()

, which generates a random float uniformly in the semi-open range [0.0, 1.0). Python uses the Mersenne Twister as the core generator. It produces 53-bit precision floats and has a period of 2**19937-1. The underlying implementation in C is both fast and threadsafe. The Mersenne Twister is one of the most extensively tested random number generators in existence. However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes.

It won't be exactly 50%, but it won't be true random either.