Hallo zusammen,
ich nutze den Zufallsgenerator random() aus der stdlib, um Zufallszahlen
von 0 bis 42 zu erzeugen (Das Resultat der random-Funktion wird mit
Modulo zurechtskaliert).
Nun ist es aber so, dass diese Funktion immer dieselbe Zahlenfolge
rauslässt...
Wie könnte man das biegen, dass das ein bisschen variiert?
Das Ganze läuft auf einem ATmega32. Müsste man wohl das EEPROM zu Rate
ziehen und da erst kürzlich aufgerufene Startwerte ablegen, und dann die
random()-Funktion ein paar mal laufen lassen, bis man etwas Neues hat?
Oder geht das irgendwie einfacher?
Gruss
Mario
Hängt vom Prozessor ab. srand() mit einem Wert aus dem EEPROM, dass man
bei jedem Start ändert (z.B. mit dem Ergebnis von rand() ) wäre ein Weg.
Hat dein Prozessor Zugriff auf eine (gepufferte) Real Time Clock, könnte
man auch daraus einen Seed-Wert generieren.
Hmm, Okee, das schaut schon vielversprechend aus.
Sehe ich das richtig, dass der Unterschied zwischen rand() und srand()
darin besteht, dass man bei srand() einen seed-wert vorgeben kann,
wohingegen rand() immer den gleichen Anfangswert hat?
Gruss und Danke
Mario
korrekt.
rand() ist quasi ein buch mit vielen seiten voll von zufallszahlen.
mit srand(time(NULL)) z.b. gibst du mit der systemzeit eine seite vor,
wo die zufallszahl dann gezogen wird. ohne srand fängt rand immer bei
seite 1 an.
@Muraer,
falls du nicht sehr anspruchsvolle Zufälligkeit brauchst, kannst du
den Modulo-Operator verwenden; ist quasi ein Abschneiden der höheren
Bits. Falls du aber die Qualität der rand()/srand()-Funktionen nicht
einschränken willst, solltest du z.B. rand()*41/RAND_MAX für Werte
zwischen 0..41 verwenden.
Gruss
Jörg
Hmm, die "Qualität" der Zufallsergebnisse spielt nicht so eine grosse
Rolle, Hauptsache, es kommt nicht immer dieselbe Folge raus.
Aber hab unterdessen eine Lösung gefunden (Roboternetz-Idee)
Gruss und Danke
Mario
" ... buch mit vielen seiten voll von zufallszahlen ... "
glaube ich nicht, würde ja massig Speicher kosten. Die Dinger werden
errechnet mit XOR-Vergleichen, dann geschoben usw., so wie man auch in
Assembler eben Zufallszahlen erzeugen würde. Das heißt aber eben, es
sind immer, wenn auch zufällig wirkend, die gleichen Folgen von Zahlen.
Müsste mal in den header-Dateien nachsehen ....
Jens_E. wrote:
> " ... buch mit vielen seiten voll von zufallszahlen ... ">> glaube ich nicht, würde ja massig Speicher kosten. Die Dinger werden> errechnet mit XOR-Vergleichen, dann geschoben usw., so wie man auch in> Assembler eben Zufallszahlen erzeugen würde. Das heißt aber eben, es> sind immer, wenn auch zufällig wirkend, die gleichen Folgen von Zahlen.
Das war auch eigentlich nur übertragen gemeint, so wie ich das verstehe.
Der Standard C-rand hat aber nichts mit XOR zu tun:
Dazu lassen sich relativ viele Seiten im Internet finden, mir fehlt aber
gerade der geeignete Suchbegriff. Standardmäßig benutzt man Additionen
und Modulo-Operationen mit Primzahlen.
EDIT: Hier: http://en.wikipedia.org/wiki/Linear_congruential_generator
Simon K. wrote:
>> Dazu lassen sich relativ viele Seiten im Internet finden, mir fehlt aber> gerade der geeignete Suchbegriff. Standardmäßig benutzt man Additionen> und Modulo-Operationen mit Primzahlen.>> EDIT: Hier: http://en.wikipedia.org/wiki/Linear_congruential_generator
Häufig zu finden, ja. Aber gerade dort, wo Division recht teuer ist
(etwa auf AVR), gibt es eine recht einfache Alternative. Man arbeitet
dann nicht auf einem endlichen Körper modulo Prinzahl, sondern auf einem
endlichen Körper modulo Zweierpotenz. Das hat den Vorteil, daß die
verwendeten Operationen alle sehr einfach auf Rechenwerken
implementierbar sind: Addition zweier Werte ist zum Beispiel einfach ein
XOR (wegen 1+1=0).
Als Beispiel hier eine Implementierung, wie ich sie verwende (Libs
benutzen kann ja jeder ;-))
1
// Ein irreduzibles Polynom vom Grad 15 über F_2, F_2 = Z mod 2Z