Vlákno názorů k článku Hardwarový generátor náhodných čísel aneb náhoda z atomů od dolik.rce - Není to trošku nefér porovnávat ten 50kB výstup...

Není to trošku nefér porovnávat ten 50kB výstup z arduina s 30x menším souborem z /dev/random? Statistika mi nikdy nešla, ale myslím že u menšího vzorku bude vždycky větší korelace... O tom že třeba ten Monte Carlo test spošítá Pi podstatně hůř ani nemluvě.

Stačí kvedlat myší a dat je hned habaděj.

Zkusil jsem vygenerovat posloupnost přesně stejné délky jako v článku z /dev/random i /dev/urandom a je vidět, že na tom tyto generátory nejsou tak špatně. Myslím že podle tohoto testu nelze s jistotou říct, který z těchto generátorů je nejlepší.

Pro /dev/random
Entropy = 7.996967 bits per byte.
Optimum compression would reduce the size
of this 53943 byte file by 0 percent.
Chi square distribution for 53943 samples is 225.58, and randomly
would exceed this value 90.77 percent of the times.
Arithmetic mean value of data bytes is 128.1016 (127.5 = random).
Monte Carlo value for Pi is 3.138598443 (error 0.10 percent).
Serial correlation coefficient is -0.004200 (totally uncorrelated = 0.0).

Pro /dev/urandom
Entropy = 7.996040 bits per byte.
Optimum compression would reduce the size
of this 53943 byte file by 0 percent.
Chi square distribution for 53943 samples is 294.47, and randomly
would exceed this value 4.51 percent of the times.
Arithmetic mean value of data bytes is 127.4627 (127.5 = random).
Monte Carlo value for Pi is 3.139488320 (error 0.07 percent).
Serial correlation coefficient is -0.002909 (totally uncorrelated = 0.0).

len ci sa nepohybujes v statistickej chybe. urandom neblokuje ked nema dostatok entropie, takze lepsi vysledok by "nemal" dat (teda aspon ak mu naozaj dojde, mozno si len mal dostatocnu zasobu).

Ano, souhlasim s tou statistickou chybou. Ted uvedu co se stane, kdyz clovek ignoruje statistickou chybu a spatne interpretuje vysledky.

Kdyby neco vyslo v libovolnem testu POKAZDE jako 100% nahoda (a ne treba 99.998%) tak to znamena, ze se NEJEDNA o nahodna data, ale o data ktera presne vyhovuji dannemu testu. Takovych dat je malo, a tedy NEJSOU nahodna. Jako priklad bych zvolil ten aritmeticky prumer, ktery je v tech vypisech videt. Kdyby mi pri hodech kostkou vysel _vzdy_ prumer presne 3.5, tak to znamena, ze jeden z hodu (treba ten posledni) muzu dopocitat z ostatnich hodu. Tedy neni nahodny.

Podle mne je zasadni chybou toho programu, ze statistickou chybu nevypisuje a proto svadi k misinterpretaci vysledku.

Vysledok u mna:

~ $ time head -c 53943 /dev/random > temp/random.txt

real 334m50.805s
user 0m0.030s
sys 0m0.070s

$ ./ent ../../temp/ran­dom.txt
Entropy = 7.996672 bits per byte.

Optimum compression would reduce the size
of this 53943 byte file by 0 percent.

Chi square distribution for 53943 samples is 250.19, and randomly
would exceed this value 57.33 percent of the times.

Arithmetic mean value of data bytes is 127.5240 (127.5 = random).
Monte Carlo value for Pi is 3.148832036 (error 0.23 percent).
Serial correlation coefficient is -0.004329 (totally uncorrelated = 0.0).