Douweegbertje schreef op woensdag 27 augustus 2014 @ 20:14:
Verbeter me maar, maar bij genoeg iteraties, zou het aantal pixels van zowel zwart als wit gelijk moeten zijn dan? Imo het zelfde principe. Als je alle waardes zou optellen van je histogram, komt dat overeen. Ik tel het constant dmv het aantal pixels van een kleur.
Je hebt dus alleen een probleem als het in beide gevallen totaal niet random is, en dus als voorbeeld elke keer 4 returned.. Maar.. dat is ook uit te lezen op het moment dat je waardes -nooit- van elkaar fluctueren.
Door die waardes op te gaan tellen gooi je enorme hoeveelheden informatie weg. Als ik random getallen uit de reeks (1, 2, 3) genereer, 1000 keer, en ik krijg daar als tien keer ongeveer 2000 uit, dan zou jij concluderen dat het random is.
Maar nu zijn mijn resultaten:
A) 1, 2, 3, 1, 2, 3, 1, 2, 3, ...
B )1, 1, 1, 2, 2, 2, 3, 3, 3, ...
C) 2, 2, 2, 2, 2, 2 ,2, 2, 2, 2, ...
D) 1, 3, 1, 3, 1, 3, 1, 3, 1, 3, ...
E) 1, 2, 2, 2, 3, 1, 2, 2, 2, 3, ...
Lekker random dan. Sterker nog, al _lijkt jouw serie random, als ie de volgende keer dezelfde serie oplevert weet je nog niets.
Om te bepalen of het echt random is zul je
meerdere zaken moeten meten.
Bijvoorbeeld hoe vaak iedere waarde voorkomt. Dat doe jij met je pixels, maar door overlappende lijnen is je methode slecht.
A) 1: 334, 2: 333, 3:333 -> prima

1: 334, 2: 333, 3:333 -> prima
C) 1: 0, 2:1000, 2:0 -> fout!
D) 1:500, 2:0, 3:500 -> fout!
E) 1:200, 2:600, 3:200 -> fout!
Om A en B eruit te gooien kan ik gaan kijken hoe vaak bepaalde series voorkomen, hoe vaak een cijfer op een bepaalde positie in een serie staat, etcetera. Dan zie ik dat bij A de serie 123 meer dan 300 eer voorkomt, dus valt ie af, en bij B dat 111, 222 en 333 te vaak voorkomen.
Jij kijkt alleen maar naar het feit dat alle opties ongeveer 2000 als som hebben. Daarmee weet je precies niets, A, B, C, D en E zijn allemaal valide "random" series volgens dat criterium.