Gibt es echten Zufall.
-
Oder nimmst race-condition:
n > 2 Threads gleichzeitig greifen auf das gleiche Megabyte Speicher zu und inkrementieren jede einzelne Zelle oder machen bitweises xor zur letzten Zelle . Es sollte mindestens 256 Durchläufe sein.
-
echten zufall gibt es nichtmal im echten leben, wir nennen es zufall ab der stelle wo wir es nicht mehr vorhersehen koennen.
Nein! Das ist falsch, wenn man die Quantenmechanik als wahr akzeptiert.
Kann man, um beim Lotto zu bleiben, nicht vielleicht aus vorhigen ergebnissen eine neue Zahgelnreihe berechnen.
Das waere immer noch nicht zufaellig, da das Ergebnis vom vorherigen abhaengig ist.
Oder nimmst race-condition
Ist immer noch deterministisch. Auch wird es unpraktisch, wenn man viele Zufallszahlen braucht.
Zu echtem Zufall: In der c't gab es mal einen Artikel, wie man aus dem thermischen Rauschen der Webcam Zufallszahlen generiert.
-
-
Besitzen die von rand() produzierten Werte überhaupt annähernd Zufallszahlen-Eigenschaften? (Es gibt da doch diese Gesetze, mit durchschnittlichem Auftreten von Wert/Zeitraum etc).
Wenn ich das Prinzip von rand richtig verstanden habe, wird doch nur aus einem Seed-Wert der nächste Seed gezogen und dabei jeweils ein Wert produziert.
Das heisst es gibt max so viele Kombinationen wie der Seed-Datentyp zulässt und jeder Seed produziert die selbe Zufallszahl. Das klingt für mich jetzt erstmal ziemlich "unzufällig"
-
Was Du hier vorbringst ist kein Kriterium für "Zufall".
Bei einer Münze weißt Du ja auch vorher, daß nur Kopf oder Zahl kommen kann... inwiefern also das Modulo mit "Zufall" unverträglich sein soll, ist mir nicht schlüssig.
-
Cpp_Junky schrieb:
und jeder Seed produziert die selbe Zufallszahl.
genau das kann aber manchmal gewünscht sein
-
Bei Linux verwende entweder /dev/random oder /dev/urandom Userinput um damit nen Entropiepool zu füllen. Genauer kanns ichs auch nicht sagen, aber da kannst du mal nachsehen.
-
Marc++us schrieb:
Was Du hier vorbringst ist kein Kriterium für "Zufall".
Bei einer Münze weißt Du ja auch vorher, daß nur Kopf oder Zahl kommen kann... inwiefern also das Modulo mit "Zufall" unverträglich sein soll, ist mir nicht schlüssig.
Ich meinte die endliche Sequenz der Zufallszahlen aus rand(). Wenn ich eine Münze werfe, wiederholen sich nach dem 4294967296ten Wurf die Werte nicht wieder
(edit)
Nee das ist Quatsch. natürlich ist die Sequenz aus rand() (pseudo)unendlich, es gibt aber "nur" 2^32 verschiedene Startpunkte für den Seed
-
rapso schrieb:
es reicht also in den allermeisten faellen wenn du den zufallsgenerator mit der aktuellen zeit initialisierst.
siehe http://www.cplusplus.com/reference/clibrary/cstdlib/srand/
Aber vorsicht! Bei sicherheitsrelevanten Programmen kann das eine Schwachstelle öffnen. Beispiel: Eine Angreiferin kommt an ein Log eines Servers, in dem die Startzeit steht (oder forciert einen Neustart durch eine bekannte Sicherheitslücke). Dann kennt sie ziemlich genau den Startwert des Zufallsgenerators, und mit einem Messwert wie dem Aufbauen einer sicheren Verbindung und genug brute-force-Ausprobieren kann sie den genauen Startwert bestimmen. Das kann sie dann, je nach Anwendung, mehr oder weniger weitreichend ausnutzen.
Irgendwo habe ich auch einen reellen proof-of-concept dafür gelesen, kann ihn jedoch nicht mehr wiederfinden.
Aus denselben Gründen kann man bei der Generierung eines privaten Schlüssels nicht die Zeit benutzen, sondern braucht möglichst viel Entropie aus Userinteraktion, Interrupts etc.
Für wissenschaftliche Anwendungen (z.B. Biophysik mit Monte-Carlo-Methoden) sollen die Pseudozufalls-Generatoren viel besser sein als die physikalischen, die auf Thermischem Rauschen, Photonennachweis oder anderen Effekten beruhen. Einerseits weil man die Reproduzierbarkeit braucht. Andererseits sollen die physikalischen Generatoren vor einiger Zeit noch statistische Schwächen aufgezeigt haben, näheres weiß ich darüber leider nicht.
Das heisst es gibt max so viele Kombinationen wie der Seed-Datentyp zulässt und jeder Seed produziert die selbe Zufallszahl. Das klingt für mich jetzt erstmal ziemlich "unzufällig"
Ja, durch den Determinismus hast du genau so viele Sequenzen wie der Seed-Datentyp speichern kann. Auch die Wiederkehr-Zeit ist höchstens so groß wie die Anzahl der Elemente im Zufalls-Datentyp. Deswegen benutzt man auch shift-register, Mersenne-Twister etc., die einen viel größeren Zustandsraum haben.
Zusätzlich kommt hinzu, dass die rand()-Implementierung oft suboptimal ist.
Für manche Anwendungen ist es dennoch geeignet -- das hängt von den Aufgaben ab, die man erledigen möchte.
-
spot-o-matic schrieb:
Andererseits sollen die physikalischen Generatoren vor einiger Zeit noch statistische Schwächen aufgezeigt haben, näheres weiß ich darüber leider nicht.
Da fängt man sich teilweise andere Fallen ein... z.B. beim thermischen Rauschen als Quelle für Zufallszahlen, die Verteilung verschiebt sich nämlich mit der Temperatur. Da kannst Du den Seed sozusagen mit einer Heizung setzen.
-
echten zufall gibt es nichtmal im echten leben, wir nennen es zufall ab der stelle wo wir es nicht mehr vorhersehen koennen.
Laut dem Eisenhauer'schen Ungleichheitsprinzip gibt es sehr wohl ZUfall.
-
Eisenhauer
Falls du Eisenhower meinst, der war Praesident der Vereinigten Staaten von Amerika.
-
Icematix schrieb:
echten zufall gibt es nichtmal im echten leben, wir nennen es zufall ab der stelle wo wir es nicht mehr vorhersehen koennen.
Laut dem Eisenhauer'schen Ungleichheitsprinzip gibt es sehr wohl ZUfall.
Was ist denn das? Meinst du http://de.wikipedia.org/wiki/Heisenbergsche_Unschärferelation ?
-
Argh, so endet es nachdem man Physik abgelegt hat.
Hab irgendetwas im Kopf durcheinander gebracht, aber ja, den meinte ich (peinlich, peinlich .. )