Zitat:
Zitat von rene
Dieses Programm enthält ein beschreibbares Skript, worin die nächste (neue) Startzahl zur Generierung der "Zufallsabfolge" mittels Generators (Algorithmus) abgespeichert wird. Somit ist das Programm von der Maschine - sofern der Code für sie les- und ausführbar ist - weitgehend unabhängig. Mein hp-Taschenrechner z.B. speichert hierfür die neue Startzahl als definierte Variable ab und greift zur Berechnung der nächsten Zufallssequenz auf sie zu.
Grüsse, rene
|
Im wesentlichen erfolgte der Ablauf wie von dir beschrieben. Der Kern war dort ein steigender Seed-Wert nach eleganter Lösung. Ich gebe freihändig zu, meine Schlussfolgerung muss keinesfalls korrekt sein. Bei hochlaufendem Orientierungswert und Zwischenspeicherung mag das Result mit der Extern-Situation vergleichbar sein. Ein frei wirkender Random wird dabei gut simuliert. Der Kern bleibt aber eine Berechnung. Anders geht es ja nicht. Ein Nichtquantencomputer kann nur verarbeiten, was ihm eingegeben wurde. Überlagerung findet nicht statt. Ich habe auch noch von keinem Informatiker gehört, dass er dem PC einen echten Random zubilligen würde. Es kann nur möglichst gut simuliert werden.
Zitat:
|
Zitat von richy
Betrachte ich nur einen Programmstart des HP Taschenrechners von rene.
Die letzte gespeicherte Zahl haengt davon ab wie lange das Programm zuvor lief.
Und das bestimmte der User von ausserhalb.
Der gespeicherte Zwischenstand F(bisherige Gesamtlaufzeit) ist der physikalische Seed Wert.
Man koennte dazu genauso Datum+Uhrzeit nehmen. Prinzipiell kein Unterschied.
|
Ja. Eine Zwischenspeicherung, ein konkreter Wert kann keinen echten Random begründen. Soweit kann ich das schon mal nachvollziehen. dazu kommt, dass ein Programm nicht beliebig hochzählbar gebaut werden wird. Soll man auf der Basis von StrToGigantops() nach und nach den gesamten Heep zubuttern? Der Algor beinhaltet auch Rückrechnungen. Entscheidend ich basal der hohe Seed-Wert. Der Spielraum ist dann groß genug. Die Serienwahrscheinlichkeit reduziert sich stark.
Gruß Llano