Diskussion:Mersenne-Twister/Archiv/1
Warum Source Code und nicht Link
Der Source Code ist nicht der original Code, sonderen ein code mit einigen Aenderungen (z.B. Initialisierung). Warum nicht den code loeschen und auf die frei verfuegbaren Implementierungen vom Entwickler des Algorithmus einfuegen: [1]
Beim Source Code, so wie er jetzt da steht, sehe ich nicht sofort ob er Werte in (0,1) oder [0,1] erzeugt.
- Er gibt "unsigned" zurück, gemeint ist wohl eine vorzeichenlose 32-bit-Ganzzahl. Also [0;4294967295]. --82.83.126.246 13:07, 18. Mai 2009 (CEST)
- Ich schlage vor - wie bereits in anderen Quellcodes und zum leichteren Verständnis - die Datentypen aus stdint.h zu nehmen, dann wäre auf den ersten Blick klar, um was es sich genau handelt. Hier würde das praktisch bedeuten (und so war es wohl vom Autor des Algorithmus gedacht), die unsigned Datentypen durch uint32_t zu ersetzen.
- Außerdem sollte zumindest noch das const int N in ein #define geändert werden.. Habs grade probiert und unter C99 funktioniert das nicht (siehe auch weiter unten). -- Plankton314 13:32, 18. Mär. 2011 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 22:41, 30. Mär. 2011 (CEST)
N oder 624?
Warum wird im Abschnitt Algorithmus die Variable N eingeführt? Besitzt sie jemals einen anderen Wert als 624? 92.105.83.190 08:56, 8. Jun. 2009 (CEST)
- was das CONST davor bedeutet, weißt du schon oder?
- Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 22:41, 30. Mär. 2011 (CEST)
Code funktionier nicht mit gcc
Der Code lässt sich nicht ohne weiteres im GCC kompilieren...
1. for(int i=,...) sollte zu int i; for(i=...) werden. 2. Die Variable Arraygrenzen sollten über # define eingefügt werden. (nicht signierter Beitrag von 85.181.182.79 (Diskussion | Beiträge) 21:38, 9. Jun. 2009 (CEST))
- Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 22:41, 30. Mär. 2011 (CEST)
Eigenschaften unlogisch
Einerseits wird behauptet: "Er ist schneller als jeder andere bekannte (hinreichend gute) Algorithmus", andererseits steht etwas später, es könne sich durch die große Datenmenge ein Geschwindigkeitsnachteil ergeben. Was stimmt denn nun? Es muß auf jeden Fall besser erläutert werden. --81.173.159.236 03:03, 24. Jan. 2009 (CET)
- Er hat - verglichen mit einfachereren Algorithmen - einen höheren Speicherbedarf (627 integer zu je 32 Bit). Auf Systemen mit sehr wenig RAM (wenige KByte) kann das eine Rolle spielen. Außerdem müssen diese Werte erst initialisiert werden. Wenn man nur wenige Zufallszahlen braucht, lohnt sich der Aufwand nicht.
- Benötigt man dagegen abertausende oder Millionen von Zufallszahlen, und erst dann ist ja die geringe Korrelation und die große Periodenlänge relevant, relativiert sich der Initialisierungsaufwand. Und im Vergleich zu anderen Algorithmen mit einer ähnlich großen Periodenlänge, z.B. kryptographisch sichereren Zufallszahlengeneratoren, ist er dann doch ein schneller Algorithmus.
- Soweit verständlich? --82.83.126.246 13:06, 18. Mai 2009 (CEST)
Zu Punkt 2) und 4): Die Eigenschaften implizieren sich gegenseitig bzw. das ist im im Grunde nur eine einzige Eigenschaft: Wenn die Bits der Ausgabesequenz gleichverteilt sind, dann ist es zwangsläufig auch jeder aus diesen Bits durch Ansammeln gewonnene Integer. Vorschlag: Punkt 4) in Punkt 2) untergliedern.
Zu Punkt 3): Der MT ist schnell, zweifelsohne - allerdings sind die von Marsaglia vorgeschlagenen RNGs (erheblich) schneller (CMWC etwa 15%, Xorshift etwa 40%) und haben hervorragende stochastische Eigenschaften (d. h. bestehen sowohl Dieharder als auch TestU01). Kurzum, dieser Punkt ist (inzwischen) falsch. Vorschlag: MT ist schnell.
Zu Initialisierung: Der im Beispielcode angegebene Mini-Zufallszahlengenerator umschifft einigermaßen das Problem der Aufwärmphase. Jedoch ist die angegebene Zahl von 10000 Aufrufen in meinen Augen vollkommen willkürlich genannt. Messungen zeigen, dass hier im schlechtesten Fall weit über 700 000 Aufrufe nötig sind. Der "Zweifelsfall" sollte also sicherheitshalber der schlechteste Fall sein. Vorschlag: 800 000 Aufrufe im Zweifels-/schlechtesten Fall. -- Plankton314 14:29, 18. Mär. 2011 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: Plankton314 21:43, 31. Mär. 2011 (CEST)
k. Überschrift
Im Gegensatz zu anderen Algorithmen ist der Mersenne-Twister in seiner Reinform nicht für kryptographische Anwendungen geeignet. Für viele andere Anwendungen wird er aber bereits erfolgreich verwendet.
Gibt es dazu eine Quelle oder Wenigstens eine Erklärung?
- Trotz des "tempering" spuckt der MT im Grunde genommen seinen internen Zustand direkt aus. Wenn man also aufeinanderfolgende Ausgabewerte analysiert, erhält man irgendwann (mit etwas Glück schon nach 624 Aufrufen) den kompletten internen Zustand des MT, womit man dann alle weiteren Ausgabewerte vorhersagen kann. Damit ist er nicht kryptographisch sicher.
In der englischen Version des Artikels wird erwähnt, dass der MT bei statistischen Testsuites sehr gut abschneidet. Das und seine Schnelligkeit machen ihn zu einem guten PRNG für alle Anwendungen in denen es auf die Verteilung und Unabhängigkeit der Werte, nicht aber auf deren Vorhersagbarkeit ankommt, z.B. in Simulationen. Wormbo 23:37, 5. Jan. 2009 (CET)
Woher kommt der hier stehende Algorithmus
Der unter der Sektion "Algorithmus" stehende Algorithmus ist kein offizieller oder vom Entwickler, woher kommt er also? (nicht signierter Beitrag von 83.78.128.73 (Diskussion | Beiträge) 17:15, 15. Apr. 2009 (CEST))