Hallo miteinander!
Ich möchte mit einem AtTiny13A möglichst einfach Zufallszahlen erzeugen.
Habe mir natürlich einige Threads und Tutorials durchgelesen.
Den Rauschgenerator kann ich schonmal ausschließen.
Als einfachste Lösung habe ich gesehen die Zeitspanne beim Drücken des
Tasters zu messen.
Dafür muss der zumindest entprellt werden & Co.
Was spricht dagegen die ganze Zeit den Timer laufen zu lassen und beim
Drücken den aktuellen Wert abzufragen?
1
#define F_CPU 1000000UL // 1MHz
2
3
#include<avr/io.h>
4
#include<util/delay.h>
5
#include"dicelib.h"
6
7
intmain(void)
8
{
9
initDice();
10
11
// Timer on by prescaler = 1024
12
TCCR0B|=(1<<CS02)|(1<<CS00);
13
14
while(1)
15
{
16
if(isButton())
17
{
18
bytenumber=(TCNT0%6)+1;
19
showDice(number);
20
_delay_ms(1000);
21
}
22
}
23
}
Kennt sich jemand mit Stochastik aus?
Im Anhang meine Ergebnisse.
Ist das zufällig genug?
Sollte für Kinder und einfache Brettspiele dienen.
Oder liefert rand() so viel bessere Werte?
(AtmelStudio 6.1)
1. Die Verteilung ist nicht wirklich gut. Siehe Spalte "Total". Bei
einem "Laplace-Würfel" sollte jede Zahl gleich oft vorkommen. Aber
siehe:
2. 3x20 würfeln ist sehr wenig zum Testen der Qualität eines
Zufallsgenerators. Bei 1e6 wird es schon etwas aussagekräftiger.
Allerdings bräuchtest du dafür wenigstens einen 2. uC oder UART, damit
die Auswertung leichter geht.
3. schau mal in die Numerical Recipes, dort gibt es eigentlich
Vorschläge für Zufallsgeneratoren.
4. rand ist wohl nicht so gut. Allerdings stellt sich die Frage, wie
sehr das bei einem einfachen Würfel eine Rolle spielt.
5. bei Conrads gab es mal einen Lötbausatz mit einem elektronischen
Würfel. Da ist nach meiner Erinnerung ein Zufallsgenerator-IC verbaut.
Der ist zwar auch nicht perfekt (er geht irgendwann in eine Schleife)
aber das wird man bei einem Spiel sicherlich nicht merken.
> Dafür muss der zumindest entprellt werden
Nö, aber egal.
> Was spricht dagegen die ganze Zeit den Timer laufen zu lassen und beim> Drücken den aktuellen Wert abzufragen?
Nichts wenn man vom timer nur die letzten bits nimmt.
Du kannst auch beim Programmstart (uC einschalten) irgendeinen Timer
starten und immer rum zählen lassen und wenn du eine Zufallszahl
brauchst, eben dessen Wert nehmen.
So lange da eine Benutzeraktion zwischenliegt die erheblich länger
dauert als die verwendeten bits vom Zähle, wird das zufällig.
Brauchst du mehrere Zahlen ohne Benutzeraktion, solltest du sie
zumindest mit einem PRNG weiterzählen.
Falls du Zufallszahlen brauchst die statistisch unabhängig sind,
beispielsweise zur Normalenverteilungsberechnung, reicht der natürlich
nicht.
Der Pollin Würfel verwendet den internen Oszilator und zählt die
Drückdauer des Tasters.
Meine Neffen spielen seit Weihnachten damit ohne Beschwerde das die
Würfel bescheißen... .
Ist bei dem Minimalaufwand die sicherste Methode.
Einen wirklich sauberen Zufallszahlengenerator kannst Du mit einen
ATtiny 13 gar nicht aufbauen... .
Grüße Löti
Lothar S. schrieb:> Der Pollin Würfel verwendet den internen Oszilator und zählt die> Drückdauer des Tasters.> Meine Neffen spielen seit Weihnachten damit ohne Beschwerde das die> Würfel bescheißen... .> Ist bei dem Minimalaufwand die sicherste Methode.> Einen wirklich sauberen Zufallszahlengenerator kannst Du mit einen> ATtiny 13 gar nicht aufbauen... .>> Grüße Löti
Aber sicher doch. Dazu genügt es, einen kryptographisch sicheren PRNG in
Software zu implementieren, für welchen man als Seed eine Zufallszahl
aus einem TRNG verwendet.
Lothar S. schrieb:> Einen wirklich sauberen Zufallszahlengenerator kannst Du mit einen> ATtiny 13 gar nicht aufbauen... .
Doch, kann man ganz einfach. Einfach immer von 1 bis 6 zählen und beim
Tastendruck anhalten und die entsprechende Zahl nehmen. Wenn ein Mensch
diesen Taster drückt und der Tiny z.b. mit 1MHz läuft ist das zufällig.
Und zwar echter Zufall.
> Und zwar echter Zufall.
Da gibt's welche die sind anderer Meinung... .
Aber wie schon erwähnt der Würfel von Pollin macht's genau so... .
Und meine Neffen haben keinen Grund zur Beschwerde... .
Grüße Löti
Lothar S. schrieb:> Da gibt's welche die sind anderer Meinung... .
Ich sehe keinen Grund, was daran nicht zufällig sein soll..
Wenn jede Zahl für die exakt gleiche Zeitspanne gültig ist, dann ist die
Eintrittswahrscheinlichkeit jeder Zahl gleich groß.
Wenn dann das "Ziehen", also der Augenblick, wann auf diese Zahl
"geschaut" wird, vollkommen unabhängig von dieser Zahl zu einem
beliebigen, zufälligen zeitpunkt geschieht, dann wüsste ich nicht, wie
zufälliger der Zufall noch sein sollte :-)
Kannst Du so machen, wenn's "zufälliger" werden soll pack einfach den
aktuellen Timerwert beim Tastendruck ins OCR0A, Anfangswert =
Timerwert-vorherigerZufallswert und CTC verwenden.
Oder Du nimmst den ADC und packst da eine Antenne dran die
"Umgebungsverschmutzung" sammelt, weißes Rauschen wäre auch noch eine
Möglichkeit usw. usf. ...
> Ich sehe keinen Grund, was daran nicht zufällig sein soll..
Da gibt's ernsthafte Untersuchungen* d'rüber das Das so zufällig gar
nicht ist, vor allem wenn immer der selbe Mensch das "Knöpfchen" drückt.
Dershalb haben kommerzielle Spielautomaten auch immer
personenunabhängige Zufallszahlengeneratoren.
Grüße Löti
*Der US-amerikanischen Glücksspielindustrie.
> Dershalb haben kommerzielle Spielautomaten auch immer> personenunabhängige Zufallszahlengeneratoren.
Nicht deswegen, sondern weil die Spielergebnisse vorherbestimmt sein
müssen, damit nachgewiesen werden kann daß die Rückspielquote (und
Gewinnquote) den gesetzlichen Vorgaben entspricht.
Also darf ein Glücksspielautomat nicht zufällig sein, und Glück hat der
davor Sitzende sowieso nie, der ist einfach nur dumm und hat im
Matheunterricht nicht aufgepasst, denn es ist vollkommen egal, ob er
irgendwelche "Stop" Tasten drückt, der Automat weiss schon vorher, wie
das Spiel ausgeht.
Lothar S. schrieb:> das Das so zufällig gar> nicht ist, vor allem wenn immer der selbe Mensch das "Knöpfchen" drückt.
Dann erkläre mal, was daran nicht zufällig sein soll?
Wenn der Zähler so schnell rennt, dass er Faktoren schneller ist, als
die zeitliche Auflösung eines Gehirns, dann ist es meines Erachtens
schon absolut zufällig.
Auf jeden Fall aber zufällig genug für einen Spielwürfel.
Und hinter einer US-Amerikanischen Studie stekckt meist auch die Angst
vor Übersinnlichem, Aliens, Verschwörungstheorien oder Zombies ;-)
> Dann erkläre mal, was daran nicht zufällig sein soll?
Eine Erklärung dafür hab ich auch nicht, nur Forschungen im Auftrag der
US... .
Grüße Löti
P.S. Die Forscher auch nicht... .
Hallo Nikolai,
für deine Zwecke ist es wohl ausreichend, den Timerwert beim Tastendruck
auszugeben. Allerdings solltest du den Timer beim erreichen einer durch
6 teilbaren Zahl zurücksetzen (lassen): In deinem Beispiel zählt der
Timer von 0 bis 255. Dabei entspricht 252 = 0 (mod 6), 253 = 1 (mod 6),
254 = 2 (mod 6), 255 = 3 (mod 6). Statistisch gesehen treten damit die
Werte 1 bis 4 mit einer minimal höheren Wahrscheinlichkeit auf
(Wahrscheinlichkeit von 1,2,3,4 ist jeweils 44/256, Wahrscheinlichkeit
von 5,6 ist jeweils 43/256).
Allgemein zum Thema Statistik: Zufall lässt sich praktisch nicht anhand
von Werten in einer Tabelle bewerten. Hätte dein Gerät nur Einsen
ausgegeben, hätte ich gesagt "Kann sein, dass es Zufallszahlen
produziert." Das ist eben Zufall...
Deine Methode ist theoretisch auch nicht zufällig, die ausgegebene Zahl
ist komplett determiniert durch den Zeitpunkt des Tastendrucks.
Pseudo random number generators sind noch weniger zufällig. Je nach Wahl
des Verfahrens (z.B. lineare Kongruenzgeneratoren) und der Startwerte
kann es sein, dass man sehr kurze Perioden erhält.
Grüße
scus
Für die Bewertung der Qualität von Zufallszahlengeneratoren gibt es
entsprechende Evaluierungsverfahren, u.a. nach BSI AIS20 oder NIST
SP800-22. Da braucht niemand seine Finger in irgendwelche Speichen
halten.
scus schrieb:> Hallo Nikolai,> für deine Zwecke ist es wohl ausreichend, den Timerwert beim Tastendruck> auszugeben. Allerdings solltest du den Timer beim erreichen einer durch> 6 teilbaren Zahl zurücksetzen (lassen): In deinem Beispiel zählt der> Timer von 0 bis 255. Dabei entspricht 252 = 0 (mod 6), 253 = 1 (mod 6),> 254 = 2 (mod 6), 255 = 3 (mod 6). Statistisch gesehen treten damit die> Werte 1 bis 4 mit einer minimal höheren Wahrscheinlichkeit auf> (Wahrscheinlichkeit von 1,2,3,4 ist jeweils 44/256, Wahrscheinlichkeit> von 5,6 ist jeweils 43/256).
Machs doch nicht so kompliziert.
Der Timer des Tiny13 beherrscht CTC Modus.
Den stellst du auf 5 ein, damit liefert der Timer nur noch die Werte von
0 bis 5 und du kannst dir diese ganze Betrachtung sparen.
Karl Heinz Buchegger schrieb:> Machs doch nicht so kompliziert.> Der Timer des Tiny13 beherrscht CTC Modus.> Den stellst du auf 5 ein, damit liefert der Timer nur noch die Werte von> 0 bis 5 und du kannst dir diese ganze Betrachtung sparen.
So sieht´s aus.. Das Rad hat sechs Speichen und gut ist.. gg
Vorausgesetzt, da macht nicht einer ne Wissenschaft draus.
Aber vielleicht kann Daniel ja mal bewerten, wie gut der Zufall ist.
Für einzelnes Drücken ist es zufällig, allerdings kann ein Mensch sehr
regelmäßige Rythmen erzeugen. Dann wäre so ein Verfahren nicht mehr
absolut zufällig (man drückt im bestimten Rythmus). Wenn es aber schnell
zählt, zB mit 1 MHz, dürfte das statistisch nicht nachweisbar sein.
Karl Otto schrieb:> Wenn es aber schnell> zählt, zB mit 1 MHz, dürfte das statistisch nicht nachweisbar sein.
Genau darum geht es ja.. wenn die Zählfrequenz >> als die Auflösung des
Gehirns ist, dann ist es ausgeschlossen, dass die Periodizität des
Drückens Auswirkung auf das Ergebnis hat.
Kein Mensch kann auf 1µs genau reproduzierbar ein Ereignis auslösen.
Und genau DA liegt der Zufall..
Karl Heinz Buchegger schrieb:> Machs doch nicht so kompliziert.> Der Timer des Tiny13 beherrscht CTC Modus.> Den stellst du auf 5 ein, damit liefert der Timer nur noch die Werte von> 0 bis 5 und du kannst dir diese ganze Betrachtung sparen.
Ich weiß nicht, ob du dir den Text mit Verstand durchgelesen hast, aber
genau das habe ich vorgeschlagen. Meine Erläuterung sollte dem
Threadersteller nur dazu dienen, zu verstehen, warum man den CTC nutzen
sollte.
scus schrieb:> Karl Heinz Buchegger schrieb:>> Machs doch nicht so kompliziert.>> Der Timer des Tiny13 beherrscht CTC Modus.>> Den stellst du auf 5 ein, damit liefert der Timer nur noch die Werte von>> 0 bis 5 und du kannst dir diese ganze Betrachtung sparen.>> Ich weiß nicht, ob du dir den Text mit Verstand durchgelesen hast, aber> genau das habe ich vorgeschlagen. Meine Erläuterung sollte dem> Threadersteller nur dazu dienen, zu verstehen, warum man den CTC nutzen> sollte.
Ach du meinst das in Klammern gesetzte 'lassen' in
> Allerdings solltest du den Timer beim erreichen einer durch> 6 teilbaren Zahl zurücksetzen (lassen):
Ja, ok. Wenn man weiß, dass du den CTC Modus gemeint hast, dann kann man
das auch so interpretieren.
Lothar S. schrieb:> Einen wirklich sauberen Zufallszahlengenerator kannst Du mit einen> ATtiny 13 gar nicht aufbauen... .
Warum nicht? Kannst du das begründen? Was ist ein "wirklich sauberen
Zufallszahlengenerator"?
Davis schrieb:> Lothar S. schrieb:>>> Einen wirklich sauberen Zufallszahlengenerator kannst Du mit einen>> ATtiny 13 gar nicht aufbauen... .>> Warum nicht? Kannst du das begründen? Was ist ein "wirklich sauberen> Zufallszahlengenerator"?
Irgendwas mit Quanten ;-)
Aber ein kleiner Rauschgenerator + ADC sollte auch sehr gut sein.
Wobei ich ebenfalls zur Lösung mittels Tastendruckdauer tendieren würde,
da komplett in SW. Und reicht ganz einfach aus. Auch wenn eben, u.a.
wegen dem Schleifenrücksprung, nicht alle Zahlen gleich lange gültig
sind und somit manche Zahlen wahrscheinlicher sind. Da könnte man
abhelfen in dem man die Schleife sehr lange macht und den Zähler sehr
groß. 100% wird's halt nie.
gruß cyblord
Karl Otto schrieb:> Wenn es aber schnell> zählt, zB mit 1 MHz, dürfte das statistisch nicht nachweisbar sein.
Das hängt sicher auch noch vond er Entprellmethode ab. Wenn die z.B.
auch noch an einem Interrupt hängt (ist ja nicht so unüblich) dann kann
es eben dazu kommen, dass die Entprellung in gewissen "Rhytmen" die
Werte ausgibt und es so zu Häufungen kommen kann. Müsste man überlegen
wie man die entprellung so vornimmt dass diese stochstisch unabhängig
ist.
rgds
cyblord ---- schrieb:> Davis schrieb:>> Lothar S. schrieb:>>>>> Einen wirklich sauberen Zufallszahlengenerator kannst Du mit einen>>> ATtiny 13 gar nicht aufbauen... .>>>> Warum nicht? Kannst du das begründen? Was ist ein "wirklich sauberen>> Zufallszahlengenerator"?>> Irgendwas mit Quanten ;-)
Was haben deine Füße damit zu tun und was sagt Lothar dazu?
Ansonsten ist ein ständig mitlaufender Timer ein perfekter
Zufallsgenerator, was man leicht überprüfen kann (siehe oben).
Davis schrieb:> Ansonsten ist ein ständig mitlaufender Timer ein perfekter> Zufallsgenerator, was man leicht überprüfen kann (siehe oben).
Das ist richtig.
Es geht um das "wie ziehe ich aus dem Timer" - ist das unabhängig vom
Timer oder gar von der Taktquelle selbst?. Wenn dabei mit Interrupts
zwischenquantisiert wird dürfte das nicht mehr unabhängig sein.
rgds
Davis schrieb:> Ansonsten ist ein ständig mitlaufender Timer ein perfekter> Zufallsgenerator, was man leicht überprüfen kann (siehe oben).
Würde ich so nicht sagen. Der Zufallsgenerator ist in dem Fall eher der
Mensch welcher es bei einem schnell laufenden Timer nicht schafft immer
gezielt so zu drücken, dass die gleiche Zahl erzeugt wird.
Karl Heinz Buchegger schrieb:> Ach du meinst das in Klammern gesetzte 'lassen' in>> Allerdings solltest du den Timer beim erreichen einer durch>> 6 teilbaren Zahl zurücksetzen (lassen):> Ja, ok. Wenn man weiß, dass du den CTC Modus gemeint hast, dann kann man> das auch so interpretieren.
Ich war mir nicht sicher, ob der Attiny13 CTC unterstützt, daher in
Klammern, ansonsten hätte man den Timer "manuell" im Code zurücksetzen
können.
Grüße
scus
6A66 schrieb:> Karl Otto schrieb:>> Wenn es aber schnell>> zählt, zB mit 1 MHz, dürfte das statistisch nicht nachweisbar sein.>> Das hängt sicher auch noch vond er Entprellmethode ab.
Wozu brauchst du da Entprellen?
Wenn stört es, wenn der Würfel nach dem Drücken der Taste in 10
Millisekunden gegebenenfalls noch 3 Sprünge macht?
Taster nicht gedrückt - Würfel steht
Taster gedrückt - Würfel läuft
Taster wieder losgelassen - Würfel steht wieder mit einer anderen Zahl
Das ganze ist doch nicht mehr als ein durchlaufender CTC Timer, eine
Flankenabfrage - Timerwert holen und aufdröseln in die LEDs eines
Würfels.
> Was haben deine Füße damit zu tun und was sagt Lothar dazu?
Stimmt schon mit den Quanten, soll meinen Quantenphysik.
Eine in Sperrichtung gepolte Diode ist die klassische Anwendung für
diesen Zweck.
Grüße Löti
Bolter schrieb:> Davis schrieb:>> Ansonsten ist ein ständig mitlaufender Timer ein perfekter>> Zufallsgenerator, was man leicht überprüfen kann (siehe oben).> Würde ich so nicht sagen. Der Zufallsgenerator ist in dem Fall eher der> Mensch welcher es bei einem schnell laufenden Timer nicht schafft immer> gezielt so zu drücken, dass die gleiche Zahl erzeugt wird.
Richtig: Es ist der Mensch, der die Zufallszahlt "würfelt".
scus schrieb:>> Ja, ok. Wenn man weiß, dass du den CTC Modus gemeint hast, dann kann man>> das auch so interpretieren.>> Ich war mir nicht sicher, ob der Attiny13 CTC unterstützt
Das war ich mir auch nicht. Drum hab ich mir das Datenblatt geholt und
hab nachgesehen. Das ist eben der Unterschied.
> Klammern, ansonsten hätte man den Timer "manuell" im Code zurücksetzen> können.
Das möchte ich sehen, wie die in der Hauptschleife einen mit Vorteiler 1
laufenden Timer gezielt bei einer Zahl zurücksetzt.
Davis schrieb:> Bolter schrieb:>>> Davis schrieb:>>> Ansonsten ist ein ständig mitlaufender Timer ein perfekter>>> Zufallsgenerator, was man leicht überprüfen kann (siehe oben).>>> Würde ich so nicht sagen. Der Zufallsgenerator ist in dem Fall eher der>> Mensch welcher es bei einem schnell laufenden Timer nicht schafft immer>> gezielt so zu drücken, dass die gleiche Zahl erzeugt wird.>> Richtig: Es ist der Mensch, der die Zufallszahlt "würfelt".
Wie beim echten Würfel halt auch... So zufällig ist der ja nun auch
nicht. Gleich geworfen auf die selbe Stelle, mit der selben
"Startstellung", bringt dasselbe Ergebnis. Wir können nur nicht alle
Parameter vorrausehen und beeinflussen. Insofern approximiert die
Timer-Methode ziemlich gut einen echten Würfel, wenn auch nicht echten
Zufall.
gruß cyblord
Der Timer geht sehr gut als Zufall.
Anbei mal mein Programm mit 8051.
Damit es realistischer wirkt, mit sichtbarem Rollen und Ausrollen.
Der Tastendruck weckt den MC aus dem Power-Down. Man braucht also keinen
Ausschalter.
Karl Heinz Buchegger schrieb:> scus schrieb:>>>> Ja, ok. Wenn man weiß, dass du den CTC Modus gemeint hast, dann kann man>>> das auch so interpretieren.>>>> Ich war mir nicht sicher, ob der Attiny13 CTC unterstützt>> Das war ich mir auch nicht. Drum hab ich mir das Datenblatt geholt und> hab nachgesehen. Das ist eben der Unterschied.
Der Unterschied wozu?
Um das Datenblatt herauszukramen hatte ich Nachts nunmal keine Lust
mehr... Außerdem kann man dem Threadersteller ja auch den Spaß gönnen,
sich selbst zu überlegen, wie er das ganze implementiert.
>>> Klammern, ansonsten hätte man den Timer "manuell" im Code zurücksetzen>> können.>> Das möchte ich sehen, wie die in der Hauptschleife einen mit Vorteiler 1> laufenden Timer gezielt bei einer Zahl zurücksetzt.
Vllt. etwas unschön ausgedrückt. Man könnte auch einen eigenen Zähler
implementieren, der mittels Timer overflow interrupt hochgezählt wird
und diesen dann beim erreichen einer bestimmten Schwelle zurücksetzen.
PS. Ich würde eher den Würfel kontinuierlich zählen lassen und bei
Tastendruck den Wert abfragen. Tendenziell ist das wahrscheinlich noch
etwas schwerer zu beeinflussen als die Dauer, die eine Taste gedrückt
ist. Je nach Taktrate macht es wahrscheinlich kaum einen Unterschied
aus, aber wenn man auf Nummer sicher gehen möchte...
> Wie beim echten Würfel halt auch... So zufällig ist der ja nun auch> nicht. Gleich geworfen auf die selbe Stelle, mit der selben> "Startstellung", bringt dasselbe Ergebnis.
Richtig, der Würfel an sich macht auch nicht den Zufall, sondern der
Mensch, der ihn wirft.
Der Würfel ermöglicht nur eine gleichverteilte Wahrscheinlichkeit einer
Zahl zwischen 1 und 6. Welche davon eintritt, hängt von einem Ereignis
ab, welches entweder deterministisch ist (wenn du den Würfel ganz exakt
von einem Roboter unter immer gleichen Bedingungen werfen lässt), oder
es ist eben zufällig, wenn du den Wurf von einem Menschen durchführen
lässt, der nicht imstande ist, bei jedem Wurf exakt die gleichen
Bedingungen zu gewährleisten.
Genauso ist es bei der Lösung mit dem rundlaufenden Timer.
Karl Heinz Buchegger schrieb:> Das ganze ist doch nicht mehr als ein durchlaufender CTC Timer, eine> Flankenabfrage
Jou, wenn immer nur die Flanke abholt und nicht entprellt wird müsste es
stochastisch unabhängig sein. So hat es mal ein Gutes NICHT zu
entprellen :))
rgds
> Jou, wenn immer nur die Flanke abholt und nicht entprellt wird müsste es> stochastisch unabhängig sein.
Sorry: Njet, die Taster prellen immer ähnlich!
Grüße Löti
Die Lösung mit dem Rund laufenden Timer ist schon gut. Eine kleine Tücke
gibt es ggf. bei der Umrechnung in Zahlen von 1 - 6. Ein gerne gemachter
Fehler (so wie im ersten Code) ist es hier einfach den Rest beider
Division durch 6 zu nutzen - das gibt aber ein Problem, wenn der Zähler
überläuft - so dass dann einige Werte etwas Wahrscheinlicher sind - bei
einem 8 Bit Timer wäre das ggf. noch merklich. Man kann 256 halt nicht
ohne Rest durch 6 Teilen.
Eine Möglich Abhilfe wäre den Timer nur ein vielfaches von 6 Schritten
machen zu lassen, also z.B. über den CTC Modus.
Beim Auslösen durch einen Interrupt muss man ggf. auch noch etwas
aufpassen: der µC macht immer noch einen Befehl zu Ende, so dass es ggf.
noch ein paar Zyklen dauert bis der Interrupt ausgelöst wird. Wenn man
Pech hat, braucht die Schleife im Hauptprogramm gerade ein vielfaches
von 6 Zyklen - es kann dann über dem Umweg der Reaktionszeiten abhängig
von der Codestelle doch wieder zu einer Ungleichverteilung kommen. Der
Extremfall wäre eine Aktive Warteschleife die zufällig gerade 6 Zyklen
braucht und dann natürlich nur Zeiten liefert, die ein vielfaches von 6
sind.
Ein Möglich Lösung wäre es den µC vor dem Tastendruck in den Idel mode
zu schicken (per Sleep Komando) - so hat man eine konstante Verzögerung
bis zum auslösen eines Interrupts und Auslesen des Timers. Alternativ
würde es auch schon reichen wenn die Länge der Warteschleife kein
vielfaches von 2 oder 3 Zyklen lang ist.
Lothar S. schrieb:> Sorry: Njet, die Taster prellen immer ähnlich!
Das ist aber hier doch völlig egal! Es wird einfach zu einem Zuflligem
Zeitpunkt der Wert ausgelesen. Ob da nun noch Konstante 10ms oder
zufällige (je nach "Druckstärke") Jitter draufkommen ist völlig egal.
Bei verwendung des internen RC wird es sogar noch etwas
Temperaturabhängig... so what?
Der Timer läuft einfach wie schon beschrieben von 0...5 und dann wird
noch eins draufaddiert für das Ergebnis beim Auslesen des Registers.
Ganz ohne Divisionen... Auch Interrupts sind hier völlig unnötig und
müssen nicht betrachtet werden.
Solange man den absoluten Zeitpunkt auswertet (je Tastendruck eine
Zufallszahl) ist das Tastenprellen kein Problem - wenn man aber wie
anfangs vorgeschlagen nur die Länge des Impulses auswertet kann das
Tastenprellen ein Problem werden, weil es da dann relativ gut
reproduzierbare Pulse von vielleicht 0,2 ms gibt aus denen sich nicht
gut eine Zufallszahl erzeugen lässt.
Wenn die Abfrage ohne Interrupt gemacht wird, also so wie oben in einer
aktiven Warteschleife, gibt es ein gewisse Chance (vielfaches von 2 oder
3 als Zyklenzahl) damit ein schlechtes Ergebnis zu bekommen - ggf. sogar
so schlecht das es gar nicht geht (im Extremfall immer das selbe).
Besser wäre in dem Fall einfach in der Schleife eine 32 Bit (ggf. auch
16 Bit) Variabel hoch zu zählen und dann wie oben zu teilen - also ganz
ohne Timer. Das ist zwar nicht perfekt, aber der Fehler ist klein.
Die Benutzung von Idel Mode und Interrupt wäre eine Möglichkeit das
Problem zu umgehen. Eine passende Länge der Schleife würde auch gehen -
ist aber vom Compiler (ggf. auch Version) abhängig oder bräuchte etwas
ASM.
Also wenn Du mit dem ersten Impuls des Tasters Deinen Ringzähler
ausliest is' es egal. Aber dann is' entprellt oder nicht auch egal.
Wenn Du die Preller zählst is' es nicht egal, Das ist nicht zufällig
sondern Taster geprägt.
Die beste Methode mit so 'nen kleinen uC ist tatsächlich der Ringzähler.
Aber echter Zufall ist das nicht.
Grüße Löti
Ulrich schrieb:> Solange man den absoluten Zeitpunkt auswertet
Welchen Zeitpunkt? Der Timer liefert doch shcon die Fertige Zahl, "Zeit"
spielt da eine untergeordnete Rolle, solange der Timer ausreichend
schnell läuft.
Lothar S. schrieb:> Aber echter Zufall ist das nicht
Du bist uns immer noch die Begründung schuldig warum der Zufall nicht
"echt" ist, er ist auf jedenfall vergleichbar "echt" wie der eines
"normalen" Spielwürfels, wenn nicht sogar besser (kein "brennen",
runterfallen, ...)
Lothar S. schrieb:> mit so 'nen kleinen uC
Das Programm wird in ASM im einfachstem Fall keine 100bytes verbraten...
was die "Größe" des uC jetzt auf den Zufall für einen Einfluss haben
soll ist auch ein ungeklärtes Mysterium.
> Lothar S. schrieb:>> Aber echter Zufall ist das nicht>> Du bist uns immer noch die Begründung schuldig warum der Zufall nicht> "echt" ist, er ist auf jedenfall vergleichbar "echt" wie der eines> "normalen" Spielwürfels, wenn nicht sogar besser (kein "brennen",> runterfallen, ...)
Das würde ich auch gerne wissen, was daran nicht "echt" ist, bzw. wie
der Zufall sein muss, dass er "echt" ist. Aber mehr als diese nicht
untermauerte These konnten wir leider noch nicht von Lothar S. in
Erfahrung bringen.
Ich bleibe bei der Aussage, dass dieser Zufall "echt" ist. Das Ergebnis
ist weder vorhersehbar, noch weißt es eine gewisse Periodizität auf,
noch ist es "durch den Menschen" reproduzierbar..
Was daran nicht "echt" sein soll, verstehe ich nicht. Aber ich bin
gespannt auf Lothars Erklärung.
Zitat Wikipedia (Zufall):
Ein Ereignis geschieht, bei dem man zwar die Einflussfaktoren kennt, sie
aber nicht messen oder steuern kann, so dass das Ergebnis nicht
vorhersehbar ist („empirisch-pragmatischer Zufall“[2]).
In unserem Fall wären die Einflussfaktoren bekannt, aber man kann sie
nicht steuern, da der Mensch nicht in der Lage ist, bei derart hohen
Zählfrequenzen reproduzierbar oder vorhersehbar das System bei einem
bestimmten Zustand anzuhalten.
> Du bist uns immer noch die Begründung schuldig warum der Zufall nicht> "echt" ist, er ist auf jedenfall vergleichbar "echt" wie der eines> "normalen" Spielwürfels
Dafür gibt's mehrere, die für einen "Digitalo" am leichtesten
verständliche ist das der Ringzähler in der Realität nicht absolut
"rund" läuft.
Das geprüfte Spielwürfel auch keinen "absolut echten" Zufall erzeugen
ist aber richtig.
Grüße Löti
P.S. Ich sag' ja, die beste Lösung ist der Ringzähler... .
Lothar S. schrieb:> Das geprüfte Spielwürfel auch keinen "absolut echten" Zufall erzeugen> ist aber richtig.
Nö.
Lothar S. schrieb:> am leichtesten> verständliche ist das der Ringzähler in der Realität nicht absolut> "rund" läuft.
Nö.
Hör endlich auf Unsinn zu erzählen.
Lothar S. vermischt hier zwei Dinge, die erstmal nichts miteinander zu
tun haben.
Den Zufälligkeit und die Eintrittswahrscheinlichkeit eines Ereignisses.
Wenn ich aus einer Dose mit 99 grünen und einem roten Zettel blind
ziehe, ist es absolut zufällig, welche Farbe ich ziehe, da ich die Augen
zu habe, die Zettel gemischt sind und ich somit auf das Ergebnis keinen
Einfluss nehmen kann.
Die Wahrscheinlichkeit, dass ich aber einen grünen Zettel ziehe, ist
recht hoch.
Und wenn jetzt der vielfach zitierte Zähler nicht auf jeder möglichen
Zahl 100%ig gleich lange verweilt, weil er z.B. für den Überlauf einen
Prozessortakt länger braucht, dann ist statistisch die
Eintrittswahrscheinlichkeit für das Auftreten der möglichen Zahlen nicht
exakt gleich verteilt, ABER welche Zahl ich duch das zufällige Ereignis
des "Taster drückens" erwische, ist meines Erachtens reiner Zufall.
Ich weiss nicht, ob ein CTC-Timer im Atmega absolut rund läuft. Falls
dies nicht der Fall sein sollte, dann kann der Fehler in der
Eintrittswahrscheinlichkeit minimiert werden, wenn man den Timer mit
einem Vorteiler etwas langsamer laufen lässt, so dass die konstante
Prozessorzeit für den Reload weniger in´s Gewicht fällt.
Schlumpf schrieb:> Ich weiss nicht, ob ein CTC-Timer im Atmega absolut rund läuft.
So rund wie der zugrundeliegende Quarz- oder RC-Oszillator (der
Zählerüberlauf kostet keine zusätzliche Zeit). Da der Jitter des
Oszillators nicht mit der Periode des Zählers korreliert, hängt die
Qualität des damit realisierten elektronischen Würfels nur von der
Qualität des Tastendrückers ab. Die Ergebnisse düften bei einer
Zählfrequenz im MHz-Bereich auf jeden Fall mindestens so gut sein wie
bei einem manuell geworfenen mechanischen Würfel.
Yalu X. schrieb:> So rund wie der zugrundeliegende Quarz- oder RC-Oszillator (der> Zählerüberlauf kostet keine zusätzliche Zeit). Da der Jitter des> Oszillator nicht mit der Periode des Zählers korreliert, hängt die> Qualität des damit realisierten elektronischen Würfels nur von der> Qualität des Tastendrückers ab. Die Ergebnisse düften bei einer> Zählfrequenz im MHz-Bereich auf jeden Fall mindestens so gut sein wie> bei einem manuell geworfenen mechanischen Würfel.
Dann fällt mir wirklich nichts mehr ein, das erklären könnte, warum
Lothar betont, dass diese Methode nicht zufällig sei. Aber vielleicht
klärt er uns ja noch auf.
Schlumpf schrieb:> Dann fällt mir wirklich nichts mehr ein, das erklären könnte, warum> Lothar betont, dass diese Methode nicht zufällig sei.
Vielleicht gibt es ja gar keinen echten Zufall. Aber diese Frage führt
wohl eher ins Philosophische oder Religiöse :)
Yalu X. schrieb:> Vielleicht gibt es ja gar keinen echten Zufall. Aber diese Frage führt> wohl eher ins Philosophische oder Religiöse :)
Wieso? Nimm die Definition von Zufall, erfüllt die Definition von Zufall
den Zufall, dann ist der Zufall der Zufall.
Religion & Philosophie sind Larifari und sollten in einem anständigen
Forum nichts zu suchen haben.
Davis schrieb:> Nimm die Definition von Zufall, erfüllt die Definition von Zufall den> Zufall, dann ist der Zufall der Zufall.
Klingt gut, nur: Welche Definition von Zufall sollte man
geschickterweise verwenden, damit's nicht
> Larifari
wird?
Nicht dass wir uns falsch verstehen: Ich bin wie du der Meinung, dass
die Methode mit dem Zähler für die hier diskutierte Anwendung maximal
zufällig arbeitet.
Bis auf den Daniel habt Ihr alle wohl nicht die geringste Ahnung wie man
Zufall überhaupt definiert und bewertet.
Also, wenn Ihr meint, dann bleibt Ihr halt bei Eurer (Irr-)Meinung.
Not my fail .
Es ist nicht meine Aufgabe Unwissende zu Wissen zu zwingen, auch nicht
in diesen Forum.
Wer von Euch tatsächlich mehr wissen will, im Beitrag vom Daniel findet
ihr weiterführende Stichwörter.
So long Löti
Lothar S. schrieb:> Es ist nicht meine Aufgabe Unwissende zu Wissen zu zwingen, auch nicht> in diesen Forum.
Da hast du mir dir selbst bestimmt schon mehr als genug zu tun.
> Da hast du mir dir selbst bestimmt schon mehr als genug zu tun.
Da täuscht Du, ich halt's mit Sokrates: Ich weis Das ich Nichts weis !
Und Du: Mußt noch viel lernen !
Grüße Löti
Lothar S. schrieb:> Und Du: Mußt noch viel lernen !Lothar S. schrieb:> Es ist nicht meine Aufgabe Unwissende zu Wissen zu zwingen, auch nicht> in diesen Forum.
Was soll man dem noch hinzufügen..?
Der Einzige, der im gesamten Thread nur mit Phrasen um sich schmeißt
entpuppt sich am Ende als der Zufalls-Guru und lässt uns nicht an seinem
großen Wissen teilhaben.. ich bin untröstlich...
Was ich wirklich denke, schreibe ich hier besser nicht ;-)
Vielen Dank erstmal für die rege Teilnahme!
Stimmt, weil der Timer 8-bit ist, kommt es zur folgenden Verteilung (s.
scus):
1-4: 43x
5-6: 42x
Aber ich denke, dass es sich verschmerzen lässt.
Zumal ein vernünftiger Würfel eher ungern eine 6 anzeigt ^^
Danke für den Tipp zum CTC.
Wie im ersten Post schon zu entnehmen war, wollte ich beileibe keinen
Tiefeinstieg in Stochastik (sigma reicht) oder gar Philosophie.
Bitte nicht mit Kanonen auf Spatzen schießen.
Frage erledigt.
Ich hab zwar mal gelernt, dass man bei Zufallszahlen sehr sehr
vorsichtig sein muss. Ich kann allerdings auch nicht erkennen, wie man
als Mensch einen derart schnell durchlaufenden Zähler zu seinem Vorteil
ausnutzen kann. Die Analogie scheint mir der Versuch zu sein, einen
realen Würfel mit immer der gleichen Handhaltung im immer gleichen Wurf
zu werfen. Was man zwar versuchen kann, was aber in der Praxis nicht
klappen wird.
Genauso auch hier: Klar, wenn ich es als Mensch schaffen würde, die
Tastendrückdauer bis auf ein paar µC kontrollieren zu können, dann kann
ich diesen elektronischen Würfel überlisten. Aber der springende Punkt
ist doch, dass ich genau das nicht kann. Und ja, so gesehen ist es der
Mensch, der eigentlich für die zufälllige Komponente in diesem Ansatz
sorgt. Ein anderer µC, der den Tastereingang direkt kontrolliert könnte
bescheissen. Aber den Fall haben wir nicht. Von daher ist es müssig
darüber zu spekulieren bzw. dafür Vorkehrungen zu treffen oder den
Aufwand hochzutreiben.
Um zum TO zurückzukommen:
Deine Statistik aus dem Eingangsposting ist zwar super und auch der
richtige Ansatz um systematische Fehler in der Verteilung zu finden. Nur
sind 60 Stichproben etwas wenig um die Qualität der Verteilung zu
beurteilen. Auch bei einem realen Würfel ist bei 60 Würfen noch keine
annähernde Gleichverteilung zu erwarten.
Karl Heinz Buchegger schrieb:> Klar, wenn ich es als Mensch schaffen würde, die> Tastendrückdauer bis auf ein paar µC kontrollieren zu können, dann kann> ich diesen elektronischen Würfel überlisten.
Ein paar µC. Mikrocoulomb oder Mikrocontroller? ;-)
Die Zeit reicht ja noch nicht. Er müsste auch noch mit der gleichen
Geschwindigkeit oder Kraft drücken. Drückt er langsamer, dauert es
länger, bis der Druckpunkt erreicht ist. Aber das ist sowieso nur
theoretisch.
Genau betrachtet haben bestimmte Zahlen eine höhere Wahrscheinlichkeit.
Irgendwann startet der Zähler mit einen festen Startwert, normalerweise
0. Dann läuft er durch und wird irgenwann gestoppt. Beim letzten
Durchlauf, in dem der Zähler gestoppt wird, wird die 0 immer erreicht,
die 5 aber nur in manchen Fällen. Dadurch haben die niedrigeren Zahlen
eine höhere Wahrscheinlichkeit.
Da der Zähler aber mindestens mehrere tausend Male durchgelaufen ist,
bevor er gestoppt wird, macht das im schlimmsten Fall einen
Promillebruchteil aus.
spess53 schrieb:>>Beim letzten Durchlauf, in dem der Zähler gestoppt wird,>> Wer redet denn davon, den Timer zu stoppen?
Ja gut, wenn der Wert ausgelesen wird.
Nikolai W. schrieb:> Aber ich denke, dass es sich verschmerzen lässt
Wieso nicht die CTC Variante? Zu einfach? Ich versteh nicht wieso hier
mit aller Gewalt die komplexere Lösung (incl. Division/Modulo) genutzt
werden soll wenn die einfachere Variante auch noch "fairer" ist...
Läubi .. schrieb:> Nikolai W. schrieb:>> Aber ich denke, dass es sich verschmerzen lässt>> Wieso nicht die CTC Variante? Zu einfach? Ich versteh nicht wieso hier> mit aller Gewalt die komplexere Lösung (incl. Division/Modulo) genutzt> werden soll wenn die einfachere Variante auch noch "fairer" ist...
Ich verstehe das auch nicht.. aber vermutlich gilt das Motto: Je
komplizierter, desto besser. Auch wenn es unter´m Strich sogar
schlechter ist.
Dussel schrieb:> spess53 schrieb:>>>Beim letzten Durchlauf, in dem der Zähler gestoppt wird,>>>> Wer redet denn davon, den Timer zu stoppen?> Ja gut, wenn der Wert ausgelesen wird.
Deswegen wird der Timer ja nicht auf 0 zurück gestellt.
Wenn man so will, dann kann man sagen, dass der nächste Durchgang dann
eben nicht damit beginnt, dass der Timer bei 0 zu laufen beginnt,
sondern bei der letzten Zahl die ausgelesen wurde. Womit das hier
> Dadurch haben die niedrigeren Zahlen eine höhere Wahrscheinlichkeit.
nicht stimmt.
Läubi .. schrieb:> Wieso nicht die CTC Variante? Zu einfach? Ich versteh nicht wieso ...
Dogma
* Timer müssen immer auf 0 zurückgestellt werden, nachdem man etwas mit
ihnen gemacht hat.
* Timer dürfen auf keinen Fall im Hintergrund einfach die ganze Zeit
durchlaufen.
So sind wir das gewohnt.
Schliesslich muss jede noch so billige Stoppuhr ja auch wieder auf 0
zurückgestellt werden. Dass man eine Aufgabenstellung auch mit einer
normalen Uhr mit Sekundenzeiger und Vergleich der unterschiedlichen
Zeigerstellungen erreichen kann, dieses Wissen scheint schön langsam
verloren zu gehen.
Ganz früher hat man sowas mit einem 4017, der im Kreis lief und ein
bisschen Logik (im einfachsten Falle Wired-Or) drumrum gemacht.
Heute braucht man dazu einen µC mit einem Timer, den man partout nicht
im Kreis laufen lassen will, sondern lieber über Modulo-Operationen und
statistischen Betrachtungen versucht, einer murksigen Lösung wenigstens
ansatzweise eine gewisse Gleichverteilung beizubiegen.
Tja Karl Heinz, so ändern sich die Zeiten ;-)
Ein Problem das Ulrich schon angesprochen hat sollte man nicht unter den
Tisch fallen lassen, nämlich dass der ganze Ansatz schief geht, wenn die
Periode der Hauptschleife ein Vielfaches der Zählerperiode ist. Um das
auszuschließen könnte man die Input Capture-Funktion des Timers
verwenden.
Andreas Schwarz schrieb:> nämlich dass der ganze Ansatz schief geht, wenn die> Periode der Hauptschleife ein Vielfaches der Zählerperiode ist.
Deshalb ist mein Ansatz, ich lasse den Timerinterrupt mit einer Primzahl
als Vorteiler laufen und darin zähle ich dann 0..5.
Und der sichtbare Würfel im Main benutzt eine andere Primzahl als
Zeitbasis.
Die Abweichungen der Warscheinlichkeiten der 6 Werte sind also extrem
klein.
Wenn man keine Interrupts verwendet, sondern einfach eine Schleife, wäre
es fast einfacher in der Schleife zu zählen. Man muss dann nur etwas
aufpassen mit den Weiterzählen: um direkt 1,2,3,4,5,6,1 ... zu zählen
wäre die Methode der Wahl da wohl eine Tabelle aus der man den nächsten
Wert abließt: also nicht zählen sondern in der Tabelle nachsehen, etwa
als n = tab(n);
Mit Interrupt für die Taste wäre der Sleep Mode die eleganteste Lösung.
Die ICP Funktion würde im Prinzip auch gut gehen, aber der Tiny13
unterstützt die nicht.
Wenn einem der Zufall noch nicht zufällig genug ist, könnte man auch die
nicht ganz zufällige Zahl aus der Zeitmessung mit einer
Pseudozufallszahl (z.B. Funktion rnd() des C-Compilers) kombinieren.
Falls dann wider erwarten die Zeiten nicht ganz gleich sind, verteilt
die Pseudozufallsfunktion die Fehler dann recht gleichmäßig, so dass
Fehler nicht mehr so sehr Auffallen. Die Zufallszahl aus der Zeitmessung
muss dann auch nicht von 1 bis 6 gehen. Elegant ist da z.B. der Weg je
nach Zeitmessung die 1. 2. 3. oder 4. Pseudozufallszahl zu nehmen. In
einer einfachen Ausführung z.B. als:
do
n = rnd()
while (! key_pressed)
Ulrich schrieb:> Elegant ist da z.B. der Weg
Warum? Was soll das bewirken?
Ulrich schrieb:> Man muss dann nur etwas aufpassen mit den Weiterzählen> [...]> da wohl eine Tabelle aus der man den nächsten Wert abließ
Warum? Was soll das bringen? Da der AVR im Zahlenraum von 0x00-0xFFFF
addieren mit Konstanter Zyklenzahl kann, die Schleife ausreichend klein
ist und der Schleifenzähler ebenfalls kann man das sehr schön
symmetrisch machen
1
wuerfeln:
2
one:
3
ldi r16, 1
4
sibc PORTA, PIN1
5
ret
6
rjmp two
7
two:
8
ldi r16, 2
9
sibc PORTA, PIN1
10
ret
11
rjmp three
12
13
...
14
15
ten:
16
ldi r16, 6
17
sibc PORTA, PIN1
18
ret
19
rjmp one
Immer wenn also eine neue Würfelzahl benötigt wird wird 'wuerfeln'
aufgerufen, in r16 steht dann beim loslassen eine Zufallszahl zwischen
1-6 (wenn der Taster nach GND schaltet). Wenn man unbedingt wollte
könnte man sogar am Anfang noch zum "alten" Wert springen, das ist aber
bei ausreichend hohem AVR Takt egal.
Thread beobachten
Seitenaufteilung abschalten