guter zufall (multiply-with-carry prng)
-
Ich dachte du würdest mittlerweile einen anderen prng bevorzugen?
-
Hallo,
bei dem Algorithmus fehlt der, üblicherweise deutliche, Warnhinweis :
"Kein echter Zufall! Niemals in kritischen Systemen einsetzen!"
Es gibt viele Anwendungsfälle wo der Einsatz so eines Pseudo-Random-Number-Generator extrem fahrlässig ist.
Außerdem könnte dieser Algorithmus anfällig für schwache Seeds sein.
Grüße
Erik
-
erik.vikinger schrieb:
"Kein echter Zufall!
Nicht?
-
Hallo,
Tim schrieb:
Nicht?
Natürlich nicht. Woher den auch? In der gezeigten Klasse ist nichts zufälliges drin. Der Zufall muss vorher, als zufälliger Seed, rein kommen. Nach spätestens ein paar Werten aus diesem PRNG kann man auf den internen Zustand zurückrechnen und damit jeden weiteren kommenden Wert vorherberechnen. Etwas das man vorherberechnen kann ist kein Zufall.
Grüße
Erik
-
@erik.vikinger:
Dein Kommentar hier ist total sinnfrei. Ein Algorithmus kann nie echte Zufallszahlen generieren. Das liegt in der Natur der Sache. Wieso sollte man dann einen Warnhinweis anbringen?
-
Hallo,
hustbaer schrieb:
Wieso sollte man dann einen Warnhinweis anbringen?
Weil man sonst den Algorithmus komplett durcharbeiten und natürlich auch verstehen müsste um zu sehen das dort keine externen Dinge drin sind die eventuell doch echten Zufall reinbringen könnten. Wer tut das schon?
Grüße
Erik
-
Man muss garnix durcharbeiten, zumindest nicht bis zu dem Punkt wo man es versteht. Man muss bloss gucken, ob irgendwo auf irgendwelche Dinge wie /dev/rand oder ähnliches zugegriffen wird. Wenn nicht, können es keine echten Zufallszahlen sein.
Davon abgesehen: Alle RNGs die ich kenne sind reine PRNGs (ich meine fertige Implementierungen in diversen Libraries). Wieso also das mit einem Warnhinweis versehen, was der Normalfall ist?
Den Fall zu dokumentieren der von der Norm abweicht, d.h. in diesem Fall einen RNG der wirklich echte Zufallszahlen liefert, ist wohl vernünftiger.Vor allem da für die meisten Anwendungen ein PRNG, mit einem mehr oder weniger echt zufälligem Seed, vollkommen ausreichend ist.
-
Hallo,
hustbaer schrieb:
wie /dev/rand oder ähnliches
Gerade dieses "ähnliches" ist nicht für jeden erkennbar oder gar beurteilbar.
hustbaer schrieb:
Alle RNGs die ich kenne sind reine PRNGs
Und was ist mit "/dev/urandom"? Auf einem normalen PC (mit halbwegs aktuellem Linux o.ä.) liefert das schon recht ordentlichen Zufall (wenn auch nur wenig) und wenn dann noch ein moderner Intel-Chipsatz oder eine aktuelle VIA-CPU (beide mit Hardware-TRNG) dazu kommt hat man schon eine Rundum-Sorglos-Lösung zur Verfügung (mit bereits ordentlicher Menge).
hustbaer schrieb:
Wieso also das mit einem Warnhinweis versehen, was der Normalfall ist?
Das ist allerdings ein berechtigter Einwand. Wer sich die Mühe macht eine gute Zufalls-Quelle zu implementieren schreibt das auch möglichst dick drauf oder will gar Geld dafür. Trotzdem sollte man IMHO dem unbedarften Anfänger schon möglichst deutlich sagen das nicht überall wo Zufall drauf steht auch Zufall drin ist bzw. das es verschiedene Qualitätsstufen beim Zufall gibt. Ich finde diese PRNGs sollten nicht Zufalls-Generator sondern Sequenz-Generator heißen, einfach um den Unterschied deutlich zu machen.
EDIT : "/dev/random" liefert natürlich keinen echten Zufall, jedenfalls nicht immer
Grüße
Erik
-
hustbaer schrieb:
Vor allem da für die meisten Anwendungen ein PRNG, mit einem mehr oder weniger echt zufälligem Seed, vollkommen ausreichend ist.
naja, da musste schon unterscheiden. viele sind für irgendwelche simulationen ausreichend, aber für kryptografie z.b. sind sie nicht so toll.
-
erik.vikinger schrieb:
"Kein echter Zufall! Niemals in kritischen Systemen einsetzen!"
Du schreibst doch auch nicht auf einen Fernseher:
"Keine echte 3D Welt! Niemals hinein springen!"
Siehe Link
http://data.lustich.de/bilder/l/1120-in-den-fernseher-gesprungen.jpg
Tim schrieb:
Ich dachte du würdest mittlerweile einen anderen prng bevorzugen?
Welchen denn? Würde mich sehr interessieren
-
Tim schrieb:
Ich dachte du würdest mittlerweile einen anderen prng bevorzugen?
Ich kann mich nicht erinnern, das gesagt zu haben. Kürzlich drückte ich aus, daß ich den mersenne twister nicht mag (das hat sich in den letzten vier Jahren also nicht geändert).
-
Was hast du denn gegen den Mersenne Twister? Zu gross (zu viel State)?
-
@erik.vikinger:
Kurzfassung: es gibt Leute die wissen was sie tun, und es gibt Leute die haben keinen Tau. Wenn jemand weiss was er tut, wird er die Warnung nicht brauchen. Wenn er nicht weiss was er tut, wird er damit nichts anfangen können.
-
volkard schrieb:
Tim schrieb:
Ich dachte du würdest mittlerweile einen anderen prng bevorzugen?
Ich kann mich nicht erinnern, das gesagt zu haben. Kürzlich drückte ich aus, daß ich den mersenne twister nicht mag (das hat sich in den letzten vier Jahren also nicht geändert).
Ich finde den Thread leider nicht, aber das was du da sagtest interpretierte ich so. Naja, nicht wichtig.
-
hustbaer schrieb:
Was hast du denn gegen den Mersenne Twister? Zu gross (zu viel State)?
Ja, zu viel State. Ich brauche keine Periode von 10^6000, der Rechner hält nichtmal 10^18 Takte lang. Also zahle ich nicht dafür.
Außerdem waren die mords Geschwindigkeitsangaben auf deren Homepage (viermal schneller als rand()!) einfach nicht nachvollziehbar, sie waren falsch wie Messungen von Sun.
-
volkard schrieb:
Außerdem waren die mords Geschwindigkeitsangaben auf deren Homepage (viermal schneller als rand()!) einfach nicht nachvollziehbar, sie waren falsch wie Messungen von Sun.
Also bei mir kommt das ziemlich gut hin. Keine Ahnung, was Du da gemessen hast.
-
Zeitgleich mit mir hat einer an seiner Diplomarbeit gewurschtelt, der aus dem verstärkten weißen Rauschen eines Transistors Zufallszahlen erzeugen wollte. Eine einleuchtende Idee eigentlich.
Das ging aber nicht so leicht, weil die Verstärkerstufe ihre eigene Charakteristik einprägte. Er hat dann noch ewig mit digitalen und analogen Filtern rumgemurkst, um dann festzustellen, daß er sich dafür die Sprungantworten der Filterstufen einheimst, wenn mal ein µ- Meson o.Ä. (also kosmische und terrestrische Strahlung) in die Schaltung einschlägt.
Wie auch immer, die "Zufälligkeit" der damaligen prng hatte er nach drei Monaten noch immer nicht erreicht.
Leider weiß ich nicht, wie die Geschichte ausgegangen ist ..., aber wenn das Ding da schneller als rand() ist, nehme ich es dankbar an.
-
pointercrash() schrieb:
Zeitgleich mit mir hat einer an seiner Diplomarbeit gewurschtelt, der aus dem verstärkten weißen Rauschen eines Transistors Zufallszahlen erzeugen wollte. Eine einleuchtende Idee eigentlich.
Das ging aber nicht so leicht, weil die Verstärkerstufe ihre eigene Charakteristik einprägte. Er hat dann noch ewig mit digitalen und analogen Filtern rumgemurkst, um dann festzustellen, daß er sich dafür die Sprungantworten der Filterstufen einheimst, wenn mal ein µ- Meson o.Ä. (also kosmische und terrestrische Strahlung) in die Schaltung einschlägt.
Wie auch immer, die "Zufälligkeit" der damaligen prng hatte er nach drei Monaten noch immer nicht erreicht.Leider weiß ich nicht, wie die Geschichte ausgegangen ist ..., aber wenn das Ding da schneller als rand() ist, nehme ich es dankbar an.
Normalerweise sind Verfahren die echten physiklaischen Zufall nutzen viel zu langsam für Anwendungen im Computer und werden höchstens als seed eingesetzt. Es gibt auch ein paar sehr schnelle echte Zufallsgeneratoren (z.B. mit chaotischen Lasern) die sogar schneller Zufallszahlen erzeugen als ein PRNG, aber auch da hat man ein Problem: Wie bekommt man die Zufallszahlen vom externen Gerät schneller in den Prozessorkern(wo sie gebraucht werden) als dass sich der Prozessorkern selber eine PRN generiert? Da die Notwendigkeit echter Zufallszahlen eher selten ist, hat kein Hardwarehersteller Interesse an der Entwicklung einer schnellen Schnittstelle dafür. Das ist es, woran echter Zufall im Computer letztlich scheitert.
-
pointercrash() schrieb:
Zeitgleich mit mir hat einer an seiner Diplomarbeit gewurschtelt, der aus dem verstärkten weißen Rauschen eines Transistors Zufallszahlen erzeugen wollte. Eine einleuchtende Idee eigentlich.
das ist bestimmt seine webseite: http://true-random.com/
-
volkard schrieb:
hustbaer schrieb:
Was hast du denn gegen den Mersenne Twister? Zu gross (zu viel State)?
Ja, zu viel State. Ich brauche keine Periode von 10^6000, der Rechner hält nichtmal 10^18 Takte lang. Also zahle ich nicht dafür.
Außerdem waren die mords Geschwindigkeitsangaben auf deren Homepage (viermal schneller als rand()!) einfach nicht nachvollziehbar, sie waren falsch wie Messungen von Sun.Gut, der Speicherverbrauch. Ist natürlich ein Argument wenn die paar kB irgendwo abgehen. Aber doch kein Grund die Mersenne Twister Generatoren allgemein abzulehnen...?
