Slumpmässighetsgenerator...

Förmodligen ger den inte så hög grad av slumpmässighet som man önskar även om resultatet ser slumpmässigt ut. Egentligen är det ju bara tid man räknar, så om man vet ett värde och hur långt efter nästa värde genererades borde man ha stora chanser att förutsäga även det senare värdet.

Det kom faktiskt nyheter i Ivy Bridge: http://spectrum.ieee.org/computing/hardware/behind-intels-new...

Den metoden skulle man helt klart kunna implementera men det skulle gå lika bra att göra det i programkoden. Det finns redan en sådan klocka i datorn processorn. Det finns också expansionskort som gör mätningarna på för att generera slumptal men minns inte riktigt vad det var de gjorde.
Faktum är också att de pseudoslumpgenerator som finns och används idag är tillräckligt slumpmässiga för att generera otroligt många slumptal som är 100% slumpmässiga. Det kan i princip göras hur många som helst och beror enbart på hur generatorn är programmerad. Svårigheten här blir i istället att använda ett slumpmässigt seed. Men det görs oftast med den metoden du nämnde. Fast man brukar ta antalet sekunder sedan 1970 som seed.
Det enda problemet är ju att om man vet koden kan man förutsäga svaret. Dock så är det givet två mätserier omöjligt att avgöra vilken som är pseudogenerarad och vilken som är "äkta" slumptal

Om du inte vill ha 1000 gånger per sekund i klockräknare kan du räkna nanosekunder istället. Det blir 1,000,000,000 gånger i sekunden.

Förutom klockan brukar t.ex. accesstid på hårddiskar och muspekarens koordinater kombinerat och sedan kört det igenom någon kryptoalgoritm/hashalgoritm, för att sedan användas som seed och på så sätt få det så "random" som möjligt. Men IB's lösning verkar vara ett steg i rätt riktning, eftersom prollarna blir så små så kan de använda utrymmet för lite kryptografiska grejer.

Och jag kan inte tänka på slumpmässiga siffror utan att tänka på:

Jag tycker att tillräckligt mycket har skrivits om slumptalsgeneratorer i tråden och jag vet inte hur mycket TS kan eller vet om användningen men jag skulle starkt tvivla på att det finns någon större användning av dom i spel. Jag har själv använt mig av en del slumptal (ganska många faktiskt) och jag har fått berättat för mig att våra mjukvaru-generatorer kan ha "serier" dvs att slumptalen upprepar sig. OM!: man drar en sådär 10 miljoner stycken i rad. Och då använder vi sådana tal i statistik där det faktiskt kan vara viktigt och inte i spel. Därmed inte sagt att spel inte är viktigt men det är knappast något som skulle förstöra spelupplevelsen.

Allmänt om slumptal

Att förlita sig på något som tickar fram i konstant hastighet fungerar inte för att generera slumptal. Anledningen är ganska simpel.

Vi har en processor som tickar på i 100 steg i sekunden.
Nu skriver vi en funktion som använder ett slumptal.
När vi kör funktionen så visar det sig att det tar exakt 10 steg att exekvera den.
När vi nu loopar denna funktion så innebär det att vi kommer att läsa av klockan vart 10 steg. Eftersom klockan är linjär så vet vi att nästa tal kommer exakt ha en differens på 10 steg. Eftersom skillnaden alltid är konstant innebär det att våra slumptal inte alls är beroende på slump utan är helt linjärt genererade.

Ivy Bridge är helt klart intressant men det krävs förstås att det implementeras överallt.

När man pratar om serier eller tabeller så pratar man om en speciellt egenskap hos mjukvarubaserade lösningar. Nämligen att dessa generatorer arbetar med tillstånd. Om vi har en slumplatsgenerator som befinner sig i tillstånd A och vi sen får fram tillstånd B, så vet vi med säkerhet att nästa gång vi har A kommer B att följa.

En simpel generator. Vi har en variabel, slump, som endast kan innehålla siffrorna 0-4.

slump = 11 * seed + 3

Låt oss initiera vår generator med seed=4 och sen hämta ut ett par värden.

seed = 4
slump = 11 * 4 + 3   ger oss att slump = 2 Eftersom slump endast är mellan 0-4. Överflödet försvinner.

seed = 2  Bytar tillstånd på generatorn genom att använda vårt föregående slumptal.
slump = 11 * 2 + 3  ger slump = 0

seed = 0
slump = 11 * 1 + 3 ger slump = 3

Generatorn kommer alltså ge ut talen [2 0 3 1 4 2 0 3 1 4] om den körs 10 gånger. Notera att den återupprepar sig. En mjukvarubaserad lösning kommer alltså aldrig kunna generera fler tal än vad som får plats i dess tillstånd. Troligt vis får man fram färre tal. Väljer vi ett annat tal på som startvärde istället för seed=4 så motsvarar det att vi väljer slumptal ur en ny tabell eftersom en ny serie tal kommer att genereras.

I spel är man inte direkt bunden till kvalitén på generatorn eftersom användaren förändrar värden genom att styra karaktärer osv som helt förändrar spelvärden och därav hur datorns AI kommer att reagera.

För att ta ett exempel vad som skulle kunna ställa till med problem så låt säga att det är en slumpgenerator som bestämmer när en ovanlig monster ska dyka upp. Slumpgeneratorn räknar upp med 1 varje klockcykel till 65000. Vi vill att monstret ska dyka upp ungefär 1 gång per 6500 sekunder. Lätt som en plätt, varje sekund läser vi ut vad slumptalet/klockan visar, och är den mellan 1-10 spawnar vi monstret. För att göra det extra spännande vill vi även slumpa fram hur mycket HP monstret har, mellan 1 och 100. Lika lätt är det, läs ut vad slumptalet är och dela med 650. Det tar ca 1000 klockcykler mellan vår kodrad som säger till datorn att ta det första slumptalet och det andra slumptalet som bestämmer HP. Det gör att monstret kommer att ha under 10 i HP varenda gång det spawnar!

Även om mitt exempel är väldigt enkelt och konstruerat gäller det att veta vad man gör när det kommer till slumptal, det är lätt hänt att det blir en intressant effekt annars Som tur är finns andra som redan tänkt på det här väldigt mycket, och om man bara använder best practice och färdiga algoritmer för att ta fram sina slumptal är det ganska liten chans för konstiga fel. Du skriver att ni använder slumptal i statistikberäkningar, då låter det tex viktigt att slumptalen är jämnt fördelade för att det inte ska bli fel, och tänk vilken problem det vore om resultatet blev olika beroende på vilken tid på dagen beräkningen gjordes...

Sluligen, om man räknar in casino-spel i kategorin spel är man ute på riktigt hal is utan en väldigt djup kunskap. Det har bl.a. varit folk som knäckt slots på casinon pga att slumpserien upprepade sig vilket kan bli väldigt dyrt.

Edit: Ska lägga till att jag tycker hela frågeställningen är intressant så inget ont om Kilroy som skapade tråden.

1) För att kritisera "slumpen" som var involverad i ditt spelexempel så skulle jag gissa att det leder till en trevligare spelupplevelse om man konstruerade "spawntiden" till 6000sekunder + ett tal som är normalfördelat kring 500. LLN http://en.wikipedia.org/wiki/Law_of_large_numbers skulle iofs ge en liknande fördelning men vi kan konstruera samma fördelning som du gjorde med färre klockcykler och vi kan dessutom kontrollera det mycket bättre se nedan.

2) Det är fortfarande inte av vikt att dessa fördelningar i spel blir perfekta då det inte påverkar spelet om det är en serie eller ej. Som du själv sa så är det viktigt i casinon eller liknande men vem bryr sig om monstrena spawnar med samma intervall som tidigare efter 1000 timmars speltid. Det finns ingen som kan komma ihåg en så lång serie så länge man inte använder var 1000de tal eller liknande (som du gjorde).
Vi kan nämligen skapa ett tal från vilken fördelning vi vill med endast ett (0,1) uniformt fördelat tal mha inversetransformering http://en.wikipedia.org/wiki/Inverse_transform_sampling och vi kan då skapa exakt samma fördelning (för spawntid) som du gjorde fast med bara 1 slumptal istället för med 65000 stycken. Så du ser att de räcker ganska så långt.

Om jag inte minns helt fel så finns det någon tredjeparts mjukvara som använder kosmisk bagrundsstrålning som seed för att generera slumptal. Vet att jag snubblade över detta när jag letade efter något helt annat men jag kommer inte ihåg namn.

Skickades från m.sweclockers.com

Nej det stämmer. Är inte insatt i hur den tar fram seed men bara att den använde kosmisk bakgrundsstrålning för att generera en seed för slumpmässighet.

Kom direkt att tänka på denna: http://www.inventgeek.com/Projects/alpharad/page1.aspx