Warum bekomme ich in der gleichen Reihenfolge für jeden Lauf mit std::random_device mit mingw gcc4.8.1?
Verwende ich folgenden code zum testen c++ <random>
Bibliothek.
Warum erhalte ich die exakt gleiche Sequenz für jedes ausführen der kompilierten ausführbaren Datei? Ist rd()
deterministische nach dem compilieren? Wie bekomme ich verschiedene Ausgabeformate für jeden Lauf?
GCC 4.8.1 unter Windows 7 64bit. Unter Verwendung von MinGW Verteilung von http://nuwen.net/mingw.html
EDIT: getestet habe ich das gleiche Stück code mit Visual Studio. Es ist kein problem. Die Ausgänge sind nicht deterministisch. Dies könnte ein bug in der mingw gcc 4.8.1 die ich verwendet habe.
#include <iostream>
#include <random>
using namespace std;
int main(){
random_device rd;
mt19937 mt(rd());
uniform_int_distribution<int> dist(0,99);
for (int i = 0; i< 16; ++i){
cout<<dist(mt)<<" ";
}
cout <<endl;
}
Plattform-und compiler-bitte. Dies sollte definitiv nicht passieren, auch mit
Nein, das ist nicht, wie
Könnte man dem compiler drucken Sie den Inhalt des Makros
Bug ist immer noch vorhanden in mingw-w64 mit gcc 4.9.2
Hat jemand versucht, einen bug-Report an die GCC so kann es behoben werden? Oder ist das zu viel verlangt?
entropy() == 0
. Wenn es funktioniert, das ist ein bug.Nein, das ist nicht, wie
random_device
funktioniert.Könnte man dem compiler drucken Sie den Inhalt des Makros
_GLIBCXX_USE_RANDOM_TR1
bitte? Wenn es 0 ist, dann ist es mit mt19937 mit einem festen Samen als fallback.Bug ist immer noch vorhanden in mingw-w64 mit gcc 4.9.2
Hat jemand versucht, einen bug-Report an die GCC so kann es behoben werden? Oder ist das zu viel verlangt?
InformationsquelleAutor ahala | 2013-09-18
Du musst angemeldet sein, um einen Kommentar abzugeben.
Vom http://en.cppreference.com/w/cpp/numeric/random/random_device:
Ich würde erwarten, dass eine anständige Umsetzung zu mindestens Samen der RNG aber.
Edit: ich vermute, Sie bewusst zu liefern, die der gleichen Reihenfolge jedes mal, machen offensichtlich, dass die Tatsache, dass der stream war nicht so zufällig, wie versprochen.
Das eigentliche Versagen ist, haben diese pseudo-random-fallback in den ersten Platz.
der standard hat damit etwas zu tun, um den Fall abzudecken, eine C++ - Implementierung, die auf einer deterministischen Plattform. Aber zu tun, dass auf einer realen Plattform ist eine umfangreiche quality-of-Implementierung Problem. Siehe auch Wie kurz und bündig, tragbar und gründlich Saatgut der mt19937 PRNG?.
großartige Ressource!
InformationsquelleAutor Mark Ransom
Bekam ich eine bestätigte Antwort von STL von MSFT:
Im Gegensatz zu VC, GCC noch nicht implementiert random_device nondeterministically auf Windows. Boost hat, so können Sie die Verwendung von Boost.Random.
InformationsquelleAutor ahala
Müssen Sie möglicherweise übergeben Sie einen parameter an den Konstruktor übergeben:
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/libstdc++/api/a00899.html
InformationsquelleAutor user877329
GCC nicht implementiert rd.Entropie() richtig - es gibt immer 0 zurück (zumindest auf Mac OS X).
Leider scheint es keine Möglichkeit zu mischen zusätzliche Entropie in random_device, welche Fragen, da es meist/oft (Blick auf Linux /dev/random und /dev/urandom, und auf die Intel RDRAND Umsetzung) implementiert eine pseudo-random number generator unter der Haube. Ich möchte in der Lage sein zur Verbesserung seiner Ausgabe durch Einspritzen von etwas, was ich als random mit zu mischen was auch immer die Entropie-Quelle produziert. Wieder, da dieses Gerät (bzw. kernel Modul) intern implementiert einen kryptografischen Algorithmus für die Bearbeitung der Entropie-bits erhält Sie zum generieren der Ausgabe, ich möchte in der Lage sein zu "randomize", dass der Prozess mehr durch Einspritzen von meinen eigenen Daten zu mischen mit dem, was Entropie, das Gerät greift.
Betrachten Sie zum Beispiel Java SecureRandom(). Es nicht zulassen, dass Sie set die Samen (die in der Tat umwandeln würde es PRNG), aber würde es gerne mischen, was Sie mit dem, was Sie nutzt, um "zufällig" Ihren Ausgang sogar noch mehr.
Ich persönlich bevorzuge RDRAND. Eine kleine assembly-Bibliothek mit einer kompakten C-Schnittstelle. Hier sind die Referenzen:
David Johnson von Intel erklärt RDRAND auf Stackoverflow
Stackoverflow Zeiger auf RDRAND Bibliothek source für Windows, Linux und Mac OS X
Intel blog auf RDRAND Bibliothek, sowie einen download-link
random_device
. Falls es erforderlich ist, einen Samen, dann ist es ein pseudo-random generator, nicht ein true random number generator, das ist, wasrandom_device
werden soll."Samen" war ein unglücklicher Ausdruck. Sie nicht den "Samen" einer "echten" random_device. Aber da zufällige Geräte wie vorgesehen, von Linux (und auch RDRAND, dass die firmware implementiert) beinhalten software-algorithmen, die zwischen Ihre Entropie Quellen und deren Ausgabe zur Verfügung, um Benutzer, mischen in der Zufälligkeit/Entropie aus anderen Quellen können nicht Schaden, das Ergebnis, und manchmal kann es verbessern. Ich denke, Sie sollten sich zurückziehen und Ihre downvote, wenn Sie ehrlich sind.
Ich denke, die Antwort ist verwirrend geschrieben, wenn Sie das schreiben, dann könnte ich zurückziehen meine downvote. Es gibt einen Unterschied zwischen Pseudo-generation und Zufälligkeit Extraktion. Theoretisch funktioniert es so. Angesichts einer schwach zufälligen Quelle, z.B. vielleicht 1000 bits mit nur 100 bit Entropie in Ihnen, ersten Sie möchten, verwenden Sie einen Abzieher zu bekommen ~ 50 bits mit ~ 50 bit Entropie. In der Praxis verwendet eine kryptographische hash-Funktion. Dann kann das Ergebnis verwendet werden, wie ein samenkorn zu einem generator, der sich die 50 bits auf viele viele weitere bits für den Einsatz in Ihrer Anwendung. (Zahlen aus.)
Schön. Ich war nicht bewusst, dass man schreiben
/dev/random
. Jetzt weiß ich es besser: fügen Sie eine Datei als Entropie-Quelle und warum schreiben auf /dev/random.... XORing die zusätzliche Entropie in der Folge ist eine gute und effiziente Art und Weise - mit dem Nachteil, dass das explizite.Ich denke, dass das Java-Modell ist die beste, weil es kann den rest der das Programm nutzt
SecureRandom
werden nicht über all jene details und Verbesserungen, und nutzen Sie einfach die standard-Schnittstelle von der standard-Klasse. Ein weiterer Vorteil der Java SecureRandom-API ist, dass es widerstandsfähig gegen Beschädigung durch "schlechte" Zufälligkeit Eingabe durch den Benutzer. Die SecureRandom-Ausgang kann nur besser werden (oder bleiben in der gleichen Qualität) mit zusätzlichem Eingang.InformationsquelleAutor Mouse