Nekromanti OBT6 och sannolikheter

[Troberg]

Efter en diskussion om vad som var medelvärdet på en OBT6 så pillade jag ihop ett litet program som simulerade det (det var enklare än att göra det på det korrekta sättet). Jag provade först 1000 försök, eftersom det är tillräckligt för att ge ett statistiskt vettigt resultat, sedan kom jag på att det är en ynklig ursäkt när man kan bränna massor av CPU-cykler, så jag körde istället en entimmeskörning med 100 000 000 försök.

Här är resultatet (inga utfall över blev 62):

Antal: 100000000
Medel: 3.750007

1: 16667481
2: 17128658
3: 17616660
4: 18136783
5: 18680615
6: 2591531
7: 2274002
8: 1918759
9: 1517830
10: 1066334
11: 557843
12: 449934
13: 350167
14: 261013
15: 188674
16: 135057
17: 105142
18: 80459
19: 63026
20: 46648
21: 35200
22: 28306
23: 22175
24: 16432
25: 12948
26: 9808
27: 7611
28: 6394
29: 5058
30: 3780
31: 3102
32: 2653
33: 1991
34: 1672
35: 1309
36: 1114
37: 782
38: 589
39: 552
40: 384
41: 349
42: 162
43: 198
44: 179
45: 162
46: 125
47: 80
48: 62
49: 45
50: 36
51: 27
52: 27
53: 0
54: 9
55: 0
56: 9
57: 18
58: 9
59: 18
60: 0
61: 0
62: 9

Man kan ganska fort se, speciellt på de höga resultaten att slumpgeneratorn är lite kass, vilket jag redan visste och är anledningen till att jag brukar göra en egen, bättre slumpgenerator.

Bra va?

 

[han göte]

väldigt bra

 

[Jarre]

Procent

Gav utfallen procentvärden istället, så att det blev lite lättare att se.

Utfall Procentuell sannolikhet
1: 16,66748%
2: 17,12866%
3: 17,61666%
4: 18,13678%
5: 18,68062%
6: 2,59153%
7: 2,27400%
8: 1,91876%
9: 1,51783%
10: 1,06633%
11: 0,55784%
12: 0,44993%
13: 0,35017%
14: 0,26101%
15: 0,18867%
16: 0,13506%
17: 0,10514%
18: 0,08046%
19: 0,06303%
20: 0,04665%
21: 0,03520%
22: 0,02831%
23: 0,02218%
24: 0,01643%
25: 0,01295%
26: 0,00981%
27: 0,00761%
28: 0,00639%
29: 0,00506%
30: 0,00378%
31: 0,00310%
32: 0,00265%
33: 0,00199%
34: 0,00167%
35: 0,00131%
36: 0,00111%
37: 0,00078%
38: 0,00059%
39: 0,00055%
40: 0,00038%
41: 0,00035%
42: 0,00016%
43: 0,00020%
44: 0,00018%
45: 0,00016%
46: 0,00013%
47: 0,00008%
48: 0,00006%
49: 0,00005%
50: 0,00004%
51: 0,00003%
52: 0,00003%
53: 0,00000%
54: 0,00001%
55: 0,00000%
56: 0,00001%
57: 0,00002%
58: 0,00001%
59: 0,00002%
60: 0,00000%
61: 0,00000%
62: 0,00001%

 

[fusk]

Statistik på Ob tärningar... Ja, det har jag sett innan någon gång.
Så jag dök tillbaka i tiden, tillbaka till ill-gröna moderatorer och gula smilisar...


För i urminnes tider i EON forumet fanns det nämligen en användare som hette Roger och skrev en väldans massa om statistik på Ob-tärningar.
Var väll inte så många som brydde sig kanske...
Det här inlägget, nr4822. behandlar ämnet.
Och än idag är hans webbsida uppe och letar man runt lite där så hittar man under "Projekt T100" både en teoretisk formel och sannolikhets tabeller.
Snabblänk

 

[Jaggernaut]

Jaså, säger du det [ANT]

Efter en diskussion om vad som var medelvärdet på en OBT6 så pillade jag ihop ett litet program som simulerade det

Det har jag vetat länge, varför var det ingen som frågade mig Det står nämligen längst bak i Eon II grundboken, så jag förstår varför ni andra inte uppmärksammat det . Medelvärdet för Ob1T6 = 3,75. Det lät sannolikt och ditt program verkar tycka samma sak.

 

[Blippe]

Det här kommer upp då och då när någon har lust att skriva ett program som testar deras randomatiserare på deras "datris".

Frågan är om ingen har lust att skriva ett riktigt test som inte måste köras i flera timmar för att få ett "exakt" resultat. (och som enkelt kan köra 6T6).

Så för att få igång det hela, vad är fel med:

P=g+(1/6)* Sum(a=1,n,P(a)*P(n-a))
där g=1/6 då 1 =< n =< 5 (0 annars)

och medel(x)=1/6 * (1+2+3+4+5) + 2/6 * medel(x)
dvs: medel(x)=3,75

Har man sammanställt en tabell av P så borde sannolikheterna för (tex) 3T6 räknas ut som:
summan av alla P(a)*P(b)*P(n-a-b) då a och b går från 1 till n (ungefär)

 

[Blippe]

millisekunder i matlab

Skrev en kort matlabfil och efter mindre än en sekunds datorkraftsansträngning på min sju år gamla grej fick jag reda på så viktiga saker som att chansen att få 63 med en ob1t6 är ungefär 0,000002820469% och att Trobergs och mina resultat skiljer sig åt någonstans på 4 eller 5 decimalen...

 

[avatarex]

Delbarhet på nio

Är det inte lite lustigt att alla utfallsmängder på summor på 49 och över är delbara på 9?
49: 45
50: 36
51: 27
52: 27
53: 0
54: 9
55: 0
56: 9
57: 18
58: 9
59: 18
60: 0
61: 0
62: 9

 

[Blippe]

Eftersom jag inte kan sova och alltid har drömt om att dumpa stora mängder med totalt meningslösa siffror rakt ner i forumet följer här just detta:
<pre> ob1t6 ob2t6 ob3t6 ob4t6 ob5t6 ob6t6 ob7t6 ob8t6 ob9t6 ob10t6
1 0.1667 0 0 0 0 0 0 0 0 0
2 0.1713 0.0278 0 0 0 0 0 0 0 0
3 0.1762 0.0571 0.0046 0 0 0 0 0 0 0
4 0.1813 0.0881 0.0143 0.0008 0 0 0 0 0 0
5 0.1868 0.1208 0.0294 0.0032 0.0001 0 0 0 0 0
6 0.0259 0.1554 0.0503 0.0082 0.0007 0.0000 0 0 0 0
7 0.0228 0.1365 0.0777 0.0168 0.0020 0.0001 0.0000 0 0 0
8 0.0192 0.1152 0.0980 0.0302 0.0049 0.0005 0.0000 0.0000 0 0
9 0.0152 0.0911 0.1104 0.0466 0.0101 0.0013 0.0001 0.0000 0.0000 0
10 0.0107 0.0639 0.1138 0.0640 0.0180 0.0030 0.0003 0.0000 0.0000 0.0000
0.0056 0.0334 0.1070 0.0798 0.0286 0.0061 0.0008 0.0001 0.0000 0.0000
0.0045 0.0270 0.0886 0.0914 0.0414 0.0109 0.0019 0.0002 0.0000 0.0000
0.0035 0.0210 0.0710 0.0955 0.0550 0.0178 0.0037 0.0005 0.0001 0.0000
0.0026 0.0157 0.0549 0.0930 0.0673 0.0266 0.0067 0.0012 0.0001 0.0000
15 0.0019 0.0113 0.0411 0.0854 0.0768 0.0369 0.0111 0.0023 0.0003 0.0000
0.0013 0.0081 0.0304 0.0741 0.0821 0.0477 0.0171 0.0042 0.0007 0.0001
0.0011 0.0063 0.0241 0.0615 0.0829 0.0578 0.0245 0.0070 0.0014 0.0002
0.0008 0.0049 0.0188 0.0501 0.0793 0.0662 0.0330 0.0110 0.0026 0.0005
0.0006 0.0037 0.0144 0.0403 0.0726 0.0717 0.0419 0.0161 0.0044 0.0009
20 0.0005 0.0028 0.0111 0.0322 0.0642 0.0740 0.0505 0.0224 0.0070 0.0016
0.0004 0.0021 0.0086 0.0257 0.0552 0.0732 0.0578 0.0296 0.0106 0.0028
0.0003 0.0017 0.0067 0.0206 0.0466 0.0696 0.0633 0.0371 0.0151 0.0045
0.0002 0.0013 0.0053 0.0164 0.0388 0.0641 0.0665 0.0445 0.0205 0.0069
0.0002 0.0010 0.0041 0.0130 0.0321 0.0575 0.0673 0.0511 0.0266 0.0101
25 0.0001 0.0008 0.0032 0.0104 0.0264 0.0505 0.0658 0.0564 0.0331 0.0141
0.0001 0.0006 0.0025 0.0083 0.0216 0.0436 0.0625 0.0601 0.0396 0.0188
0.0001 0.0005 0.0020 0.0066 0.0176 0.0372 0.0578 0.0618 0.0455 0.0241
0.0001 0.0004 0.0016 0.0052 0.0144 0.0315 0.0524 0.0618 0.0506 0.0297
0.0000 0.0003 0.0012 0.0042 0.0117 0.0265 0.0467 0.0600 0.0544 0.0355
30 0.0000 0.0002 0.0010 0.0033 0.0095 0.0221 0.0410 0.0570 0.0568 0.0409
</pre>


Sen börjar det bli lite väl meningslöst!

 

[Snow]

Re: Delbarhet på nio

jag skulle tro att det var det Troberg menade med att slumptalsgeneratorn var kass

 

[Troberg]

Re: Delbarhet på nio

jag skulle tro att det var det Troberg menade med att slumptalsgeneratorn var kass

Japp. Den har (precis som alla programmeringsspråk jag testat) två brister:

- Lägre upplösning än vad den förefaller ha. Även om den ger en hel radda decimaler så är det bara vissa värden som förekommer. Det betyder oftast att om man ska slumpa mellan mer än tusen värden eller så så måste man förbättra den, annars är det vissa som aldrig kommer att komma upp.

- Återkommande sekvenser. När man kör i en relativt tight loop som jag gjorde här så kan man ofta se att likadana eller snarlika sekvenser upprepas. Detta förklarar antagligen varför de höga resultaten klumpade ihop sig.

 

[Troberg]

Re: Jaså, säger du det [ANT]

Det har jag vetat länge, varför var det ingen som frågade mig Det står nämligen längst bak i Eon II grundboken, så jag förstår varför ni andra inte uppmärksammat det .

Man ska inte tro på allt man läser utan att testa det först.

 

[Guest]

Re: Delbarhet på nio

Om du vill ha ett system som kollar äktare random än en "vanlig"* dator kan frambringa så gör så att det kopplar upp sig mot www.random.org.

Med vanlig så menar jag 32bitars processor med fungerande ram och utan antenner, då allt är viktigt för att bli av med random delar.

 

[walium]

It's a Neverending Loop of Pain!

"Man ska inte tro på allt man läser utan att testa det först."

Du menar alltså att vi inte ska lita på det som du har skrivit heller utan skriva ihop våra egna program vars resultat andra i sin tur ska tvivla på så att de skriver egna program och så vidare i alla evighet... When will it end? Who can we trust? Oh the horror!

 

[gråhök]

Re: Delbarhet på nio

- Lägre upplösning än vad den förefaller ha. Även om den ger en hel radda decimaler så är det bara vissa värden som förekommer. Det betyder oftast att om man ska slumpa mellan mer än tusen värden eller så så måste man förbättra den, annars är det vissa som aldrig kommer att komma upp.

Detta ätr faktiskt "samma" som nedan.

- Återkommande sekvenser. När man kör i en relativt tight loop som jag gjorde här så kan man ofta se att likadana eller snarlika sekvenser upprepas. Detta förklarar antagligen varför de höga resultaten klumpade ihop sig.

Jo. De flesta pseudoslumptalsgeneratorer bygger på en feedback-loop av ngt slag. En bra har en lång period innan de upprepar sig (i storleksordningen 2^16-2^32 iterationer innan upprepning), en dålig i storleksordningen 2-3 iterationer (eller ger samma resultat jåmt).

Tyvärr är det så, om man inte har "riktig slump" att ta av.

 

[Troberg]

Re: Delbarhet på nio

Detta ätr faktiskt "samma" som nedan.

Nej, i ena fallet handlar det om att bara ett visst antal av de till synes tänkbara utfallen kommer att användas. Ungefär som en D100 som aldrig slår 38.

I andra fallet handlar det om att vissa talserier återkommer, alternativt vissa differenser mellan nuvarande och föregående tal förekommer. Ungefär som en D100 där sekvensen 69, 08, 10, 39, 78 återkommer oftare än vad sannolikhetslagarna förutspår. Jag vill ha en sådan tärning.

Jo. De flesta pseudoslumptalsgeneratorer bygger på en feedback-loop av ngt slag. En bra har en lång period innan de upprepar sig (i storleksordningen 2^16-2^32 iterationer innan upprepning), en dålig i storleksordningen 2-3 iterationer (eller ger samma resultat jåmt).

Jo, jag brukar försöka förbättra dem genom att modifiera slumptalet genom att dividera ett separat slumpat mycket stort primtal med slumptalet och sedan bara behålla decimaldelen. För säkerhets skull så kan man förbättra upplösningen ytterligare genom att göra detta flera gånger i flera steg med olika slumptal och olika primtal.

Man bör också försöka hitta bra och olika frövärdesgeneratorer, tex tiden för senaste musrörelsen, sista decimalerna i internklockan osv.

Tyvärr är det så, om man inte har "riktig slump" att ta av.

Det är värre än så. Det finns ingen perfekt slumpgenerator och det kan inte finnas en. En perfekt slumpgenerator skulle i längden ha en absolut jämn fördelning, men om den ska ha det så är ju sista slumptalet förutbestämt och därmed inte slumpmässigt.

 

[Troberg]

Re: It's a Neverending Loop of Pain!

Du menar alltså att vi inte ska lita på det som du har skrivit heller utan skriva ihop våra egna program vars resultat andra i sin tur ska tvivla på så att de skriver egna program och så vidare i alla evighet... When will it end? Who can we trust? Oh the horror!

Nejdå, det räcker att be mig posta källkoden så att ni kan granska den.

 

[Guest]

Re: It's a Neverending Loop of Pain!

Kan man få källkoden? Iallafall om den e till c pascal basic matlab eller gml, i undantagsfall även matematica men då helst som pdf då jag inte har det hemma.

 

[Troberg]

Re: It's a Neverending Loop of Pain!

Kan man få källkoden?

Självklart!

Den är VB6 och väldigt quick&dirty, så ha överseende med den. Den evolverade lite oplanerat ur en målsättning att enbart räkna ut medelvärdet.

 

[gråhök]

Re: Delbarhet på nio

Nej, i ena fallet handlar det om att bara ett visst antal av de till synes tänkbara utfallen kommer att användas. Ungefär som en D100 som aldrig slår 38.

I andra fallet handlar det om att vissa talserier återkommer, alternativt vissa differenser mellan nuvarande och föregående tal förekommer. Ungefär som en D100 där sekvensen 69, 08, 10, 39, 78 återkommer oftare än vad sannolikhetslagarna förutspår. Jag vill ha en sådan tärning.

Fast bägge fenomenen beror på samma sak.

Jo, jag brukar försöka förbättra dem genom att modifiera slumptalet genom att dividera ett separat slumpat mycket stort primtal med slumptalet och sedan bara behålla decimaldelen. För säkerhets skull så kan man förbättra upplösningen ytterligare genom att göra detta flera gånger i flera steg med olika slumptal och olika primtal.

Med en smula otur spelar det ingen roll. Speciellt inte om du använder samma slumptalsgenerator. Om du har hårdvarustöd för slumptal eller pseudoslumptal är det absolut bästa att plocka lagom mycket slump därifrån och använda det (tyvärr brukar man bara kunna plocka slump i enheter om 8 bitar, så eventuellt får du plocka lagom mycket, kolla om det ligger inom vettiga intervall och kasta bort det och plocka nytt).

Det är värre än så. Det finns ingen perfekt slumpgenerator och det kan inte finnas en. En perfekt slumpgenerator skulle i längden ha en absolut jämn fördelning, men om den ska ha det så är ju sista slumptalet förutbestämt och därmed inte slumpmässigt.

Nej, en perfekt slumptalsgenerator skulle i längden ha en asymptotiskt jämn fördelning, det innebär inte att "nästa slumptal" är, över huvud taget, beroende av de som gått före. OM du vill läsa lite håriga utläggningar om pseudoslump rekommenderas The Art of Computer Programming (Donald E. Knuth), Vol II, 3:e kapitlet, Random Numbers , där lite olika metoder analyseras i detalj.