Hallo Besucher, der Thread wurde 25k mal aufgerufen und enthält 85 Antworten

letzter Beitrag von Mike am

Würfel Analyse

  • 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?

    Wenn die ganze Bandbreite an Zahlen genutzt wird kann das in der Tat ein Nachteil sein, da ja aber im beschriebenen Fall nur die unteren Bits benötigt werden ergibt sich daraus ja eine Ergebnisreihe in der die Zahlen durchaus mehrfach vorkommen.
    Es empfiehlt sich den PRNG immer um mindestens Faktor 2-3 größer zu wählen als man die Ergebnisse benötigt. Wenn du den (ebenfalls sehr flotten) 16-Bit-Algo nimmst sind Zufallszahlen bis in eine Größenordnung von 10k kein Problem. Zur besseren Gleichverteilung dann siehe unten.


    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.

    Siehe dazu meine Postings vorher - die Verteilung ist nicht komplett gleichförmig, sondern liegt bei 43:43:43:43:42:42. Modulo ergibt ebenfalls diese Verteilung- nicht komplett eben, aber sehr nahe dran. Um das zu umgehen müsste ein Algorithmus direkt nur sechs Zahlen generieren. Da aber eigentlich alle Zufallszahlen im Rechner auf Berechnungen aufbauen und der nunmal im Binärsystem arbeitet wird das schwierig. Der vorgestellte Algo ist schnell und bietet im Binärraum eine Gleichverteilung aller Ergebnisse, das ist schonmal nicht schlecht.
    Man könnte noch alle $ff Durchläufe zum Ergebnis (also vor dem Modulo) eins mehr addieren, damit verschiebt sich dann die Verteilung immer um eine Spalte nach rechts, also bei der ersten Addition zu 42:43:43:43:43:42, usf.
    Immer noch nicht perfekt, aber auf Dauer nivelliert sich das dann.

  • Mir scheint, die (jeweils völlig legitimen) Ansprüche reden ein wenig aneinander vorbei. Wie nennt man das am besten, zufällig vs. pseudo-zufällig? In der Praxis brauchbar für starke Crypto vs. "für Spiele reicht's"?

    Die Anforderungen an einen Crypto-PRNG sind wiederum anders, das hat damit nichts zu tun. Es geht darum, dass der PRNG in BASIC2 so schlecht ist, dass er zum Beispiel bei bestimmten Seeds schnell degeneriert.


    Die meisten PRNG können nur pseudo-zufällige Zufallszahlen erzeugen, das ist richtig. Selbst die Entropie für einen ordentlichen Seed ist nicht ganz einfach zuerhalten beim C64. Dennoch kann man auch gute PRNG bauen. Der im C64 gehört nicht dazu.

  • Die meisten PRNG können nur pseudo-zufällige Zufallszahlen erzeugen

    Sogar alle, daher kommt ja der Name "Pseudo Random Number Generator" :D

  • Warum schreibt ihr eigentlich nicht mal ein paar 100.000 bis 10 Millionen Zufallszahlen im Bereich von 0-255 als Bytes in eine Datei und lasst die von Tools wie ent oder diehard analysieren? Die machen etwas aufwendigere statistische Tests als nur Gleichverteilung oder visuelles Abschätzen von Korrelationen.

  • Ich bitte dich dann aber auch die Software herunterzuladen und zu testen und keine fremden Seiten zu zitieren.


    Ich zitiere "fremde" Seiten hier im Thread? Wo bitte?

    Siehe mein Zitat darüber - soll heißen einfach ausprobieren, ohne befangen zu sein, von dem was du evtl. schon irgendwo gelesen hast. ;) Ich habe es hier als Anhang.
    Bei mir füllte sich der Bildschirm nach ca. 1...2 Minuten völlig. Habe es 7 x probiert - das Programm zählt dabei die Versuche. Es schwankte zwischen 6.979 und 10.261 Versuchen, um die 1.000 Zeichen vollzukriegen. Also sagen wir vereinfacht Faktor 7...10.
    Dazu habe ich noch ein Zusatzprogramm gemacht, dass nur 6 Werte ereichen soll (alle Würfelaugen). Da schwankten die Versuche zwischen 6 und 36. Also Faktor 1...6. Meistens gab es Versuche mit einer 10'er Zahl - also Faktor 2..3.
    Ist aber auch normal denke ich, je mehr Felder, desto mehr trifft der Generator zum Schluss auf bereits besetzte Felder.


    Ich sagte dir ja schon, dass ich fachlich viel von dir halte, aber noch bin ich von meiner Zufallszahlentechnik überzeugt. Dass das BASIC V2 besser sein könnte, da sind wir uns alle einig, es geht aber darum aus dem vorhandenen das Beste zu machen. Und bisher konnte ich alles mit dieser Technik realisieren...


    ...bevor jemand merkt, dass die Zufallszahlen sich evtl. nach zigtausend Zyklen wiederholen, ist das Spiel vorbei! ^^


    Es empfiehlt sich den PRNG immer um mindestens Faktor 2-3 größer zu wählen als man die Ergebnisse benötigt.

    Man muss sich nur zu helfen wissen! ;) So macht das dann ja auch Sinn! Stell dir vor du würfelst und ehe sich ein Würfelauge wiederholt, würden immer erst alle anderen Augen an der Reihe sein - völlig unrealistisch! ^^


    43:43:43:43:42:42

    Praktisch ausgeglichen - in meinen Augen völig o.k.!


    In der Praxis brauchbar für starke Crypto vs. "für Spiele reicht's"?

    So sehe ich das auch! ;) Ich bin kein Wissenschaftler, der allerhöchste Ansprüche an einen modernen und komplexen Algorithmus stellt, sondern ich brauche eine Zufallstechnologie für die Entwicklung von Spielen. Meine Ansprüche hatte ich schon in diesem Thread formuliert: Zufalls Chart


    - Eine von 65536 Startfolgen bei Neustart
    - Kurzzeitig betrachtet erwarte ich ein chaotisches Durcheinander ohne Muster, Regelmäßigkeiten und Wiederholungen. Es sollen sich aber einzelne Werte durchaus wiederholen, wie es bspw. beim echten Würfeln ja auch vorkommt.
    - Langfristig wünsche ich mir "Gerechtigkeit", d.h. es sollte ein Ausgleich zwischen allen Werten herrschen, also eine gleichmäßige Verteilung. Es darf nicht der Eindruck eines gezinkten Würfels entstehen.
    - Das vorgegebene Wertespektrum möchte ich definieren. Bspw. 6 Werte (0...5 oder 1...6) für ein Würfelspiel.


    Alle Kriterien erfüllt meine Technik, die als Kernstück den BASIC RND Generator benutzt. Für besonders anschaulich halte ich die "Wertechronik" auf den 2 Fotos des o.g. Threads.


    Durch die Idee von Mike's "Käseknabber-Programm", für das ich vorhin kurz meinen Kode angepasst habe, hat sich aber noch ein 5. Kriterium herausgestellt:


    - Es sollte eine gewisse Anzahl von "Fehlversuchen" geben, bis wie in diesem Falle alle 1.000 Zeichen des Bildsschirms gefüllt. Wenn für exakt 1.000 Zeichen stets nur 1.000 Versuche nötig wären, wäre das genauso Käse, als wenn man 50.000 Versuche benötigen würde. Vielleicht ist ein guter Faktor irgendwo zwischen 4...16???



    Warum schreibt ihr eigentlich nicht mal ein paar 100.000 bis 10 Millionen Zufallszahlen im Bereich von 0-255 als Bytes in eine Datei und lasst die von Tools wie ent oder diehard analysieren?

    Weil ich z.B. solche Programme nicht kenne. Vorschlag: Ich sende dir eine Disk - auf jeder Seite eine fette Datei mit je 128 K Zufallszahlen von 0...255 - natürlich vom BAISC RND Befehl generiert. Du fütterst damit dann die entsprechenden Programme und gibst Bescheid, na?

  • Ich sagte dir ja schon, dass ich fachlich viel von dir halte, aber noch bin ich von meiner Zufallszahlentechnik überzeugt.

    Ich nicht. Was unter anderem daran liegen könnte, dass sie bislang nur nebulös als "RND, aber noch mit was extra" beschrieben wurde statt sie mal zu dokumentieren.


    Zitat

    Weil ich z.B. solche Programme nicht kenne.

    ent, dieharder


    Zitat

    Vorschlag: Ich sende dir eine Disk - auf jeder Seite eine fette Datei mit je 128 K Zufallszahlen von 0...255 - natürlich vom BAISC RND Befehl generiert. Du fütterst damit dann die entsprechenden Programme und gibst Bescheid, na?

    Mindestens bei dieharder werden damit ungefähr alle Tests versagen weil das grob um den Faktor 1000 zu wenig Daten sind.

  • 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)


    Der VICE arbeitet in dieser hinsicht exakt; das Rauschen des SID - das in der Tat mit einem 12Bit-LFSR generiert wird - wird dort 1:1 simuliert.
    Von dem LFSR sind dann 8 bestimmte Bits via Registerzugriff auslesbar.


    Die Wellenformen sind NICHT als Wavetable abgelegt!


    Ein Oszillator im SID ist im Grunde "nur" ein Zähler, dessen Wert um den Inhalt der beiden Freq-Register erhöht wird.
    Die obersten 12 Bits dieses Zählers werden dann, je nach eingestellter Wellenform, logisch miteinander verknüpft* und auf
    einen D/A-Wandler gegeben.



    So.. das ganze sehr vereinfacht:


    1. Bei Sawtooth wird nix verknüpft. Hier werden einfach nur die obersten bits des Zählers ausgegeben.
    2. Für die Pulsewaveform, wird der Wert aus Reg $2/3 auf die obersten 12Bit addiert und der Überlauf
    ausgegeben; d.h. entweder gibt der DAC 0x000 oder 0xFFF aus.
    3. Für Triangle wird das oberste Bit des Oszillators genommen und und - sofern gesetzt - die 11 bits darunter
    invertiert (oder so ähnlich... bin grad zu faul in den Plan zu schauen).
    4. Der Clock für das LFSR wird IIRC auch aus dem Zähler generiert... aber hier gilt auch: Bin grad zu faul.
    Notfalls in die VICE Sourcen schauen; da steht's ja auch mehr als genau drin. :prof:

  • zu wenig Daten

    Also um die 168.000 könnte ich dir noch anbieten, bei mehr muss ich leider passen. :(


    dokumentieren

    Wie anfangs kurz erwähnt, läuft der "Nachschub" für Zufallszahlen in der Hauptschleife um den IRQ nicht zu belasten. Immer wenn ein Flag gesetzt ist, werden neue Werte erzeugt, sobald der IRQ fertig ist - wie Multitasking im Taschenformat. :)


    Die angeforderten Werte können mit 0...255 definiert werden (diesen Wert im Akku, Y-Reg. = 0). Die Hauptschleife ruft letztendlich die BASIC ROM Routine $E0BE auf, das Ergebnis im FAC#1 wird kurz noch in ein 1-Byte Wert umgewandelt - das war's.


    Erfahrungsgemäß dauert die Beschaffung einer Zahl ca. 1/3 Frame. Aber ein Objekt, dass Merkmale aus Zufallszahlen besitzt, befindet sich i.d.R. deutlich länger auf dem Bildschirm, sodass sich die Hauptschleife meistens langweilt. :(


    Ansonsten habe ich die Technik auch für die Labyrintherzeugung oder die Spielkarten bei "Blackjack aka Twenty-One" benutzt. Wie gesagt, entsprechend den o.g. 4, bzw. 5 Kriterien hatte ich nie einen Grund zur Klage! :)


    Schade, dass bis jetzt niemand auf meine Frage wegen dem SID-Rauschen geantwortet hat. Es wäre für mich z.B. von entscheidender Bedeutung, ob man auch ein Wertespektrum vorgeben kann (bspw. 6 Werte von 0...5 oder so). Wenn ich vom SID immer nur eine feste Bandbreite von 0...255 bekomme, ist er für mich uninteressant.

  • Schade, dass bis jetzt niemand auf meine Frage wegen dem SID-Rauschen geantwortet hat. Es wäre für mich z.B. von entscheidender Bedeutung, ob man auch ein Wertespektrum vorgeben kann (bspw. 6 Werte von 0...5 oder so). Wenn ich vom SID immer nur eine feste Bandbreite von 0...255 bekomme, ist er für mich uninteressant.


    Steht doch alles ein Post drüber!?



    Und: Um einen Werte-Bereich zu erahlten, einfach MODULO-Operation ausführen.

  • Steht doch alles ein Post drüber

    Das nenn ich "Timing" - während ich meinen Thread schrieb, hast du deinen veröffentlicht! :)


    Aber gut zu wissen, ich werde mal in Kürze den "Zufalls Cahrt" aus dem anderen Thread umbauen und statt der RND Zahlen die vom SID nehmen. Das mit dem "hochzählen" könnte man evtl. sehen, aber ich lasse mich einfach mal überraschen - ohne vorher zu spekulieren. Mal gucken, welche chaotischer aussehen...

  • @astroSID: okay, ich hatte das wohl in den falschen Hals bekommen (hatte was mit hochauflösend im Hinterkopf im Zusammenhang mit den Oszillatoren des SID gehabt...). Nun ja, nun ist's richtig gerückt :)


    Für Interessierte und Anekdotensammler: Interview zum SID mit Bob Yannes

  • 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:


    Code
    1. 1 PRINT"{CLR}";:X=RND(-7621)
    2. 2 FORT=1TO100000:X=RND(1):NEXT
    3. 3 X=INT(RND(1)*40)
    4. 4 Y=INT(RND(1)*25)
    5. 5 POKE1024+40*Y+X,160
    6. 6 GOTO3

    Tja, das tun sie leider nicht.

    :thumbup:
    Ich hab das mal im Wiki nachgetragen.

  • warum so kompliziert mit x und y?
    warum nicht gleich eine zahl zwischen 0 und 1000 (999).


    also:


    z=INT(RND(1)*1000)
    poke 1024+z,160



    hmm... und das INT könnte man ja auch weglassen :)


    wenn man das ganze über 2 (x und y) werte macht, setzt man ja noch ein weitere voraussetzung ein, um den bildschirm komplett zu löschen. denn selbst wenn jede zahl eigentlich gleichverteilt vorkommen würde, wäre nun noch die reihenfolge wichtig.

  • Danke, Mac Bacon! ^^

    warum so kompliziert mit x und y?

    Ursprünglich wollte ich mit x- und y-Koordinaten auf den Grafik-Bildschirm plotten.


    Die paar hundert einsamen Punkte sehen dann noch erschreckender aus, ich wollte mich aber nicht auf eine mögliche Diskussion einlassen, daß das evtl. an BASIC V3.5/V7 oder der BASIC-Erweiterung liegen könnte. :whistling:

  • hier mal als bitmap version.
    im emulator mit warp speed sieht man auch was in annehmbarer zeit :)
    ergebnis finde ich garnicht mal so schlimm. wobei irgendwann scheinbar nichts mehr hinzukommt.
    da tauchen wohl einige werte nie auf. hmmm... rundungsprobleme, floatzahlprobleme, zu wenig bits in der rnd routine? oder fehler im code?


    Code
    1. 0 printchr$(147):x=rnd(-7621)
    2. 1 fort=1to1000:x=rnd(1):next
    3. 2 fort=0to8000:poke8192+t,0:next
    4. 3 poke53265,59:poke53272,24
    5. 4 z=int(rnd(1)*64000)
    6. 5 p=8192+z/8
    7. 6 pokep,peek(p)or2^((z-32768)and7)
    8. 7 goto 4