3. Mersenne Twister als RNG für random_shuffle

Mersenne Twister als RNG für random_shuffle

  • 3

    volkard schrieb:

    SeppJ schrieb:

    srand(time(0)*GET_PID);

    Sünde!
    Das Ergebnis der Plutimikation hat so viele Nullen am Ende wie beide Faktoren zusammen.

    😃 👍

    0
  • R

    314159265358979 schrieb:

    314159265358979 schrieb:

    Öhm ja, verlesen. Dann nimm doch einen anderen Seed, zum Beispiel die Nanosekunden.

    Und sag bloß nicht, du hast den Post auch überlesen. Du hast sogar darauf geantwortet.

    Da hätte ich auf eine etwas ausführlichere Erklärung gehofft...

    Ich hab dich gefragt,

    Und wie bring ich es dem random_shuffle bei?!

    Deine Antwort darauf:

    Indem du einfach srand() aufrufst?

    Da ich damit nicht weiterkam, hab ich im Netz geschaut und es in meinem Code eingebaut...
    Gegenfrage: Hast du es dir durchgelesen?!

    @SeppJ
    Zum Fehler... In der Tat... 🤡 Die Schleife hab ich mir aus einem anderen Programm schnell rauskopiert, wo ich eine 2D-Vektor hatte. Danke für den Hinweis (das ist ehrlich gemeint!)
    Static cast hatte ich aus einem Beispiel im Internet (siehe oben, meine Frage wie ich srand() aufrufen soll).

    0
  • Mod

    volkard schrieb:

    + oder ^ waren doch voll in Ordnung (aber zu langweilig?).
    Das Ergebnis der Plutimikation hat so viele Nullen am Ende wie beide Faktoren zusammen. Das heißt, mit * ballerst Du Dir die teuer besorgten Entropiebits einfach wieder raus.

    Oh, stimmt. War ohne viel Nachdenken. Da mein RAND_MAX 2^31 ist, hat's sogar funktioniert und ist nicht aufgefallen.

    Frei nach Knuth ist dies ein guter Seed, falls man nicht urandom & Co nehmen kann:

    const uint64_t golden_ratio = 0x9e3779b97f4a7c13LL;
seed = getpid();
seed *= ratio;
seed ^= time(0);
seed *= ratio;

    Aber solche Zahlenmagie mag ich nicht sehr, weil ich nie verstehe was da genau hinter steckt. Für mich sieht das wie gut geraten aus.

    0
  • 3

    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.

    0
  • R

    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?).

    0
  • 3

    Den restlichen Informationsgehalt darfst du dir selbstverständlich zusammengoogeln.

    0
  • R

    314159265358979 schrieb:

    Den restlichen Informationsgehalt darfst du dir selbstverständlich zusammengoogeln.

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

    0
  • 3

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

    0
  • Mod

    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.

    0
  • 3

    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

    0
  • V

    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;
}
    0
  • 3

    Was willst du mir sagen volkard?

    0
  • Mod

    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.

    0
  • 3

    Okay 😉

    0
  • V

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

    0
  • W

    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

    0
  • V

    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.

    0
Anmelden zum Antworten