letzter Beitrag von Mike am
Der Ansatz von TheRyk mit dem Rauschen vom SID klingt für mich vielversprechend (wenn man tatsächlich die Werte vom Rauschen abgreifen kann). Im Emulator ist's imho müßig, weil das Rauschen dort mittels Zufallsgenerator simuliert wird (würd' mich wundern, wenn nicht).
Ich meine mich zu erinnern, dass auch im SID nur mit Wasser gekocht und das "zufällige" Rauschen per LFSR erzeugt wird. VICE bildet das sogar exakt nach, IIRC.
Hallo,
anbei die unter retro-programming.de erklärten Möglichkeiten. Der Zufallswert steht dann jeweils im Akku und kann noch abhängig von einer Benutzereingabe ausgelöst werden und damit zeitpunktgesteuert variiert werden.
Interessant finde ich den SID als Zufallsgeber. Die dritte Stimme des SID dabei auf Rauschen (Noise) stellen, Frequenz <>0 setzen und ab $D41B Zufallswert abgreifen. Tonausgabe dabei nicht aktivieren. Ich weiß auch nicht welche Konsequenzen das in einem Spiel mit Hintergrundmusik hätte, aber den Ansatz finde ich erwähnenswert.
In Basic nutze ich den Befehl
x=rnd(-time)
direkt nach einer Benutzereingabe, damit der C64 sich bei der Zufallsgenerierung nicht wiederholt. Siehe auch im Anhang mein Basic Spiel Kniffel, wo es um genau darum geht, eben nicht immer dieselben Würfe zu reproduzieren.
Ich denke, DATA-LANDs Nutzung der Basic RND Funktion ist doch spieletechnisch legitim. Subjektiv fällt mir als Spieler doch kein wiederholendes Muster auf, selbst wenn es eines gibt und selbst wenn die Zahlen sich algorithmusbedingt immer in denselben Größenbereichen bewegen sollten.
Mathematisch sieht es wieder anders aus. Wenn man hier einen mathematisch echten Zufall generieren will, geht das nicht ohne externe Einflüsse auf die Hardware, sei es nun Benutzeraktivität oder externer Signalinput.
Ich meine mich zu erinnern, dass auch im SID nur mit Wasser gekocht und das "zufällige" Rauschen per LFSR erzeugt wird. VICE bildet das sogar exakt nach, IIRC.
Ja, kann sehr gut hinkommen, dass das Rauschen im SID künstlich generiert wird... mir fiel gestern abend noch ein, dass der SID bei der Tonerzeugung digital arbeitet (Wellenformen sind als "Wavetables" hinterlegt), so dass das Rauschen auch nicht unbedingt von einem Transistor kommen muss. Wobei ich an Rauschen als eine Wellenform in der Tabelle gedacht habe (die Lösung ist sicher nur 2-3 google-Suchen entfernt)
Das SID-Rauschen ist ncht analog und eine Musik darf dann natuerlich auch keine 3. Stimme haben, d.h. man koennte 'drums' ueber eben jedes Rauschen simulieren 
Ich weiss auch nicht, ob man das SID-Rauschen beliebig schnell auslesen darf, ganz sicher nicht direkt nach dem setzen.
Alles anzeigenPRNGs aber die will man fuer vieles nicht
Ein 8 bit PRNG hat im Idealfall 256 verschiedene Werte aber keinen Doppelt natuerlich.
Es haengt eh immer vom Einsatz-Zweck ab.
Der Wuerfeltest bestaetigt ausschliesslich, dass das BASIC RND nicht komplett kaputt ist.
Aber ueber die Nutzbarkeit und Qualitaet sagt das nichts aus.
Bei fast allen PRNGs die so einfach sind, sind auch nicht alle bits gleich 'zufaellig'. Meist eher die oberen.
Der BASIC RND ist glaube ich wirklich relativ brauchbar, so ein Test ist aber keinesfalls geeignet das zu bestaetigen.
Eine Reihe (i%6+1) waere demnach perfekt
Der oben vorgestellte Code erzeugt schon 16 komplette (iirc) Reihen von $00-$ff, daher auch die Anmerkung mit dem Wechsel von Reihe zu Reihe nach $ff durchläufen, damit erzielt man schon gute Ergebnisse - und die Reihe 1,2,3,4,5,6 darf beim Würfeln auch vorkommen ohne dass dies was besonderes wäre - sie ist genauso wahrscheinlich wie jede andere Reihe auch.
Die Wahrscheinlichkeit dafür liegt halt bei 1/(6^6), also bei ca. zwei tausendstel Prozent.
Ein PRND, vernünftig eingesetzt, ist keine schlechte Sache. Der hier vorgestellte hat jede Zahl des Spektrums exakt einmal, womit es auch nicht zur Zufälligkeitshäufung im oberen Bit-Bereich kommt. Der Nachteil liegt wohl mehr darin dass der Wertebereich für einen Würfel eher groß ist - ein Modulo wird nötig, und das frisst halt viele Zyklen. Dann sollten jedoch alle Ergebnisse nahezu gleichverteilt sein- die 1-4 kommen 43 mal, die 5 und 6 42 mal.
Modulo ist aber keine gute Idee. rand() % N ist nicht gleichverteilt.
Mag idR nicht aufffallen, ist aber so
Wenn ich nach einer 6 weiss dass die naechste 172 erst in (und zwar genau dann) 255 Schritten kommt, ist das ebenfalls kein besonders toller Zufall
Mein Beispiel mit i%6+1 liefert eine perfekte Gleichverteilung 'am Ende' ist aber ansonsten natuerlich quark.
IdR sind bei PRNGs die oberen bits zufaelliger als die unteren uebrigens.
Bei Assembloids sieht man das schoen je zufaelliger ich das machte, umso schwerer wurde das. Da spuerte man zwei LSR tatsaechlich im Spiel.
Eine grafische Darstellung wie strik sie schon ansprach, ist als Test schonmal sehr viel aussagekraeftiger.
Eine 'ungefaehre' Gleichverteilung am Ende ist das absolute Minimum an Bedingung. Wer das nicht besteht, ist kein Zufallsgenerator, aber es reicht noch lange nicht, um dessen Qualitaet zu bestimmen.
Modulo ist aber keine gute Idee. rand() % N ist nicht gleichverteilt.
Mag idR nicht aufffallen, ist aber so
Wenn ich nach einer 6 weiss dass die naechste 172 erst in (und zwar genau dann) 255 Schritten kommt, ist das ebenfalls kein besonders toller Zufall
Über die Strecke von 00-ff bei jeder Zahl einmal kommt auch Modulo 6 immer in Gleichversteilung heraus.
Und: Du weisst eben nicht dass die nächste 172 in exakt 255 Schritten kommt - da ja wie ich schon erwähnte ein mitlaufender Counter die Reihe wechselt wenn sie durchlaufen wurde. Es ist und bleibt ein PRNG, aber durch die Erhöhung der Möglichkeiten wirst Du Otto normaluser von dieser Wiederholung ausreichend ablenken. Und wenn der 8er es nicht tut nimmst Du die 16er Variante, die schon 2048 verschiedene Reihen mit 65536 Werten pro Reihe liefert.
Bei fast allen PRNGs die so einfach sind, sind auch nicht alle bits gleich 'zufaellig'. Meist eher die oberen.
Das wird oft behauptet, aber nie erklärt, obwohl es doch sehr kontraintuitiv ist, wenn man bedenkt, dass die Bits an einem Ende des Registers früher mal am anderen Ende standen.
Und für welche Schieberichtung soll das gelten, rechts- oder linksherum?
Über die Strecke von 00-ff bei jeder Zahl einmal kommt auch Modulo 6 immer in Gleichversteilung heraus.
Imho nur, wenn 00-ff eine durch 6 Teilbare Anzahl wäre. Bei 255 bleibt aber ein Rest von 3, die Zahlen 4-6 kommen daher 1mal seltener vor.
Was du aber nicht untersucht hast, ist ob diese Würfelaugen nicht immer in der gleichen Reihenfolge fallen.
Eine vollständige Untersuchung eines Zufallsgenerators muss beides umfassen.
Habe ich hier nachgeholt!
Zufalls Chart
und nur eine Gleichverteilung der Werte ist jetzt noch kein so richtig tolles Qualitätsmerkmal für Zufallszahlen
Ja stimmt, aber es ist sehr wichtig! Das muss man einfach mal überprüft haben.
SID-Rauschen
Rauschen vom SID
SID als Zufallsgeber
Ich habe davon früher mehrmals in Fachbüchern gelesen, mich aber nie damit intensiv beschäftigt. Ist es denn möglich dem SID mitzuteilen, in welchem Bereich er "rauschen" soll? Kann ich bspw. vom SID Zufallszahlen nur von 0...5 oder 1...6 für einen Würfel bekommen? Und kostet mich das eine Stimme des SIDs?
da der Generator alle 256 Werte exakt einmal auswirft bevor er sich wiederholt.
Ich kenne den von dir beschriebenen Algorithmus nicht, aber bedeutet das, dass sich keine Zahl wiederholt, ehe die ganze Folge durch ist? Dann wäre das ja ein großer Nachteil!? Oder habe ich da jetzt was falsch verstanden?
x=rnd(-time)
Wenn du am Anfang des Programms für
X = RND (-PEEK(53266)*PEEK(56324))
nimmst, hast du eine von 65536 verschiedenen Startfolgen, anstatt nur 256.
Im Thread "Zufalls Chart" ist ein Anhang dabei, der u.a. auch eine neuere Version der "Würfel Analyse" beinhaltet. Damit lässt sich auch ein gezinkter Würfel simulieren. Bei einem neutralen Würfel ist jede Zahl mit einem Anteil von knapp 17% vertreten. Ich habe beim gezinkten den Anteil der "6" auf knapp 29% erhöht! Das ist gemein ich weiß - viel gemeiner ist aber noch die Tatsache, dass das bei kurzem Gebrauch gar nicht auffällt! 
Erst auf lange Sicht mekt man, dass die "6" doppelt so oft vorkommt wie jede andere Zahl!
Ja, so ein Zufallsgenerator ist schon ein tolles Spielzeug...
Bevor hier noch weitere Loblieder auf den RNG von CBM BASIC gesungen werden: der ist *richtig* kaputt!
Nur soviel: im Prinzip handelt es sich um einen linear-kongruenten Generator, d.h. ein Seed wird mit einer Zahl multipliziert, eine weitere wird addiert und dann erfolgt eine Restbildung. Zur "Verfügung" steht ein 32-Bit-Seed, und damit könnte man im Prinzip eine Periode von 2^32 Zahlen erzeugen, bevor sich die Zufallszahlenfolge wiederholt.
Leider dachten sich die Programmierer damals ganz was tolles (nicht!), als sie sich entschieden, dazu dem Generator noch was "Würze" zu geben, in dem die nieder- und höherwertigen Bytes des Seeds auch noch vertauscht werden. Allerdings sind gerade die niederwertigen Bits eines lin.-kong. Generators überhaupt nicht zufällig, die dann auch nach vorne zu bringen, "bricht" den Generator: anstelle einer langen Folge von 2^32 Zahlen gibt es jetzt zehntausende von Zyklen mit teilweise nur ~58000 bzw. ~750 verschiedenen Zahlen, andere Zahlen werden je nach Seed nur einmal erzeugt und danach nie mehr (der Generator läuft dann in einen der genannten Zyklen ein).
Siehe auch hier:
der ist *richtig* kaputt
Ich halte sehr viel von dir und schätze auch deine Meinung, aber ob er nun richtig kaputt oder richtig gut ist, sollte man an den Ergebnissen messen. Wenn ein kaputter Z-Generator super Chaos fabriziert, ist mir das recht - nur bitte keine Muster, Regelmäßigkeiten und Wiederholungen!
Hast du dir zufällig schon die "Zufalls Charts" oder zumindest die Fotos angeschaut, die er produziert? Was ist deiner Meinung da nicht i.O.? Andersrum gefragt, wie sollte sich denn sonst ein Z-Generator verhalten, der wie in diesem Fall bspw. 320 Werte mit einem Spektrum von 0...199 erzeugen soll???
Alles in allem macht er einen sehr guten Job - ich habe keinen Grund zur Kritik!
Mit den paar zehntausend Zahlen, die mit deinem Analyse-Programm gezogen werden, plus im Falle des Würfels, der kleinen Klassenanzahl kannst Du die Güte des Generators auch nicht annähernd einschätzen.
Das soll hier ja jetzt auch nicht unbedingt ein Crash-Kurs in Statistik werden, aber wenn an Stelle von 2^32 verschiedenen Werten mit einem "schlechten" Seed irgendwann nur noch ein Zyklus von etwa 750 Zahlen erzeugt wird, macht sich das in jedweder auch selbstgebastelter Statistik sehr schnell bemerkbar. Und sei es nur so, daß selbst in dem günstigen Fall einer Klassenbildung von 6 Fällen sich die Abweichungen nicht mehr nivellieren und währenddessen auch noch zwischen den Klassen hin- und herpendeln, nein, die Abweichungen bleiben, nivellieren sich nicht und bestimmte Klassen werden stark bevorzugt.
Ein besonders schlechter Seed ist z.B. der im verlinkten Thread genannte Wert -7621. Mit diesem Seed und einem Warmlaufenlassen über etwa 100000 Aufrufe läuft RND() in einen kurzen Zyklus ein. Dieser Zyklus wird in deinem Würfeltest garantiert auffallen. Und mit einem klassischen "Käseknabber"-Programm, welches mit X,Y-Koordinaten aus RND() Punkte setzt, wird der 320x200-Bildschirm garantiert nicht letztenendes gefüllt, es werden nur ein paar hundert Punkte gesetzt und das war's dann.
Zitat von DATA-LANDDer Maschinensprachekode beeinflusst die ROM Routine mit einer Kombination aus Rasterzeile und CIA Timer.
Damit enthebst Du dich höchstens noch weiter einer guten Kontrolle über die statistischen Eigenschaften der Zahlen. Prinzipiell lassen sich hier zeitliche Korrelationen ebenfalls nicht ausschließen.
Beim Programmstart einen zufälligen Seed mit Hilfe von Timern zu ermitteln, geht meines Erachtens schon in Ordnung. Danach sollte das Verfahren aber schon deterministisch sein.
die Güte des Generators
Okay genug der Theorie. Was ist deiner Meinung nach an der Ausgeglichenheit und der Reihenfolge (vgl. Fotos von Thread "Zufalls Chart") nicht in Ordnung??? Was erwartest du von einem Zufallsgenerator? Was wäre deine Alternative?
Ist es in Ordnung, wenn ich in ca. 10 Minuten mit einem grafischen Beispiel zeige wie scheiße RND() ist?
300 Quatloos auf Mike!
:popkorn:
wie scheiße RND() ist?
Du solltest aber auch Bezug zum aktuellen Kode nehmen. Die Methodik deiner Anwendung ist ja wahrscheinlich nicht identisch. Mit dieser Analyse hier habe ich überprüft, dass sich die Zahlen (zum Glück) langfristig ausgleichen. Mit den Zufalls Charts sieht man die "Wertechronik".
Zitat von DATA-LANDDu solltest aber auch Bezug zum aktuellen Kode nehmen.
Sorry, aber *das* hab' in meinen Beiträgen zuvor bereits gemacht.
Mit einer "eindimensionalen" Zeitreihendarstellung sieht man eine Periode natürlich erst dann, wenn man auch soviele Punkte darstellt, wie die Periode umfaßt. Und hier solltest Du schon nachvollziehen, daß eine Pseudozufallsfolge mit einer Periode von ca. 750 de-facto unbrauchbar ist, und in *jeder* Art von Statistik durchfällt.
Aber egal, hier jetzt mein Beispiel: ein Käseknabber-Programm - Textmodus reicht aus. Normalerweise sollte man erwarten, daß die X,Y-Koordinaten die im nachfolgenden Programm in den Zeilen 3 und 4 ermittelt werden, letztenendes den Bildschirm füllen:
Tja, das tun sie leider nicht. Hier nach kurzem Warp das Ergebnis:
tun sie leider nicht
Das ist natürlich ein ganz anderes Programm, aber ich werde es mit meiner Methodik nachahmen, wobei ich bin mir jetzt schon zienlich sicher bin, dass sich das Bild füllen wird. Allerdings kann es eine bestimmte Zeit dauern, da sich manche Zufallszahlen ja wiederholen, aber das sollen sie ja schließlich auch.
Ich bitte dich dann aber auch die Software herunterzuladen und zu testen und keine fremden Seiten zu zitieren. Das hilft nicht weiter und bringt auch nix. Danke!
Werde schauen, dass ich es morgen Abend schnell machen kann...
Ich zitiere "fremde" Seiten hier im Thread? Wo bitte?
Der einzige Link den ich hier im Thread gepostet hatte, zeigt auf eine andere Diskussion hier im Forum64.
Für mich ist die Diskussionsgrundlage jetzt weitgehend erschöpft. Wenn Du dich an einem RNG mit einer Periode von ca. 750 Zahlen nicht störst, ist das im weiteren nicht mehr mein Problem.
