3. Mersenne Twister als RNG für random_shuffle

Mersenne Twister als RNG für random_shuffle

  • R

    314159265358979 schrieb:

    Liest du überhaupt, was SeppJ und ich schreiben?

    Den letzten Beitrag von SeppJ hab ich gerade erst gesehen, sorry.
    Wenn du sagst, ich soll srand() aufrufen, dann sagt mir das herzlich wenig, sorry.
    Ich hab jetzt mal geschaut, dass ich auf /dev/urandom bzw. /dev/random zugreife und dann srand((time(NULL)+seed)); aufrufe.

    Aber danke für dir Hilfe... Das man immer gleich geflamed wird...

    0
  • R

    SeppJ schrieb:

    edit: Und noch ein paar der schlimmeren Fehler und Ungenauigkeiten aus dem vom Threadersteller übernommenen Code entfernt.

    Und welche wären das?

    0
  • 3

    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.

    0
  • Mod

    railrun schrieb:

    SeppJ schrieb:

    edit: Und noch ein paar der schlimmeren Fehler und Ungenauigkeiten aus dem vom Threadersteller übernommenen Code entfernt.

    Und welche wären das?

    Zum Beispiel hast du nur 9 Elemente eingefügt, aber 10 ausgegeben.

    Das myrandom war nicht ganz so sinnvoll. Klar das hast du von mir, aber das war eigentlich nur ein Beispiel, wie so eine Funktion aussehen kann. Aber rand selbst zu kapseln bringt herzlich wenig, da es schon der Standard ist.

    Wenn du '\n' meinst, sag '\n', nicht endl, welches '\n' und flush entspricht.

    Der staitc_cast war total unnötig.

    Also (bis auf die Ausgabe über das Feldende hinaus) eher Kleinigkeiten. Der Unterschied zwischen 9 und 10 ist jedoch schon ein grober Fehler gewesen.

    0
  • V

    SeppJ schrieb:

    srand(time(0)*GET_PID);

    Sünde!
    + 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.

    0
  • 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
Anmelden zum Antworten