Mersenne Twister als RNG für random_shuffle

[railrun]

314159265358979 schrieb:

Und was ist an meinen Antworten jetzt aus deiner Sicht nicht verständlich? Mein Vorschlag war, dass du srand() mit den Nanosekunden aufrufst, weil sich damit die Zeit zwischen deinen Programmstarts ändert. SeppJ's Vorschlag ist auch eine Möglichkeit.

Ja und wie rufe ich es jetzt genau auf?! Diese Info hat den gleichen Informationsgehalt wie der Post von vorhin (Indem du einfach srand() aufrufst?).

[314159265358979]

Den restlichen Informationsgehalt darfst du dir selbstverständlich zusammengoogeln.

[railrun]

314159265358979 schrieb:

Den restlichen Informationsgehalt darfst du dir selbstverständlich zusammengoogeln.

Danke
Was dann rauskommt, haben wir ja gesehen...

[314159265358979]

http://www.cplusplus.com/reference/clibrary/ctime/

[SeppJ]

314159265358979 schrieb:

http://www.cplusplus.com/reference/clibrary/ctime/

Ich fürchte mit dem kommst du aber auch nicht weit. Denk dran, dass das Programm sicherlich oftmals ziemlich genau gleich lang gelaufen ist, wenn srand (als meistens eine der ersten Anweisungen überhaupt) erreicht wird.

[314159265358979]

Er kann doch clock() nehmen und in Nanosekunden, Mikrosekunden, was auch immer umrechnen. Die Initialisierung des Vectors kann er vor schieben. Da lässt sich schon was machen

Edit: Natürlich gehts aber auch damit: http://www.boost.org/doc/libs/1_47_0/doc/html/date_time/posix_time.html#ptime_from_clock

[volkard]

314159265358979 schrieb:

Er kann doch clock() nehmen und in Nanosekunden,

uint64_t my_rdtsc(){
   //achtung, springt nur ca 18-mal pro Sekunde, aber dafür jedesmal um ca 208791209
   return clock()*3800000000/CLOCKS_PER_SEC;
}

[314159265358979]

Was willst du mir sagen volkard?

[SeppJ]

314159265358979 schrieb:

Er kann doch clock() nehmen und in Nanosekunden, Mikrosekunden, was auch immer umrechnen. Die Initialisierung des Vectors kann er vor schieben. Da lässt sich schon was machen

Eben nicht wirklich. Erstens ist auch clock recht ungenau und zweitens zählt clock vom Programmstart an. Und da es immer ziemlich genau gleich lange dauern wird bis srand erreicht wird, ist die Chance recht hoch, dass der gleiche Seed raus kommt. Wenn man hingegen das Betriebssystem nach Zufallszahlen aus dem globalen Generator fragt oder die PID mit der Zeit verwurstet^*, dann geht die Chance dafür so ungefähr gegen 1/RAND_MAX.

^*: zumindest wenn man es richtig macht. Siehe volkards Einwand und meinen Nachtrag.

[314159265358979]

Okay

[volkard]

Und daß man rdtsc in Erwägung ziehen sollte.

[Werner Salomon]

Mal 'ne ganz andere Möglichkeit. Wenn das Programm immer wieder gestartet wird, wäre es doch sinnvoll, den Zufallsgenerator einfach beim Programmende abzuspeichern und beim nächsten Programmstart wieder einzulesen.
Dann kann man sich zum einen die Suche nach einer Entropiequelle sparen und - viel wichtiger - man hätte eine vernünftige Zufallszahlenverteilung.
Sowohl boost.random als auch der Mersenne-Twister von Herrn Wagner bieten diese Möglichkeit an.

Gruß
Werner

[volkard]

Werner Salomon schrieb:

Mal 'ne ganz andere Möglichkeit. Wenn das Programm immer wieder gestartet wird, wäre es doch sinnvoll, den Zufallsgenerator einfach beim Programmende abzuspeichern und beim nächsten Programmstart wieder einzulesen.
Dann kann man sich zum einen die Suche nach einer Entropiequelle sparen und - viel wichtiger - man hätte eine vernünftige Zufallszahlenverteilung.
Sowohl boost.random als auch der Mersenne-Twister von Herrn Wagner bieten diese Möglichkeit an.

Gruß
Werner

Nicht einfach, wenn mehrere Instanzen parallel laufen könnten.