Deutsches Reaktor Forum

Annahme
Die Sequenz eines Randomize Modules (Primary-Pseudo-Random-Eventmodifikator) ist abhängig vom per Set Random Modul gesetzten Seed und - verglichen mit Sequenzen anderer Randomize Module - Modul spezifisch.
Problem
Bei dem Versuch einen Wert per Clock Osc mit einer gegebenen Wahrscheinlichkeit pro Tick zeitlich zu variieren, werden bei niedriger Wahrscheinlichkeit die ausgegebenen Werte stark eingeschränkt. Ob ein Clock-Tick zum Randomize Modul durchgelassen wird, wird mit einem weiteren Randomize Modul entschieden.
Ersetzt man eines der Randomize Module mit einer Core Cell werden die angestrebten Werte ausgegeben.
Ersetzt man beide Randomize Module mit Core Cells mit dem selben Seed werden ebenfalls die angestrebten Werte ausgegeben.
Nur bei Verwendung der zwei Primiary Module entspricht das Verhalten nicht mehr dem von mir erwarteten.

Obwohl ich eine Lösung gefunden habe, interessiert es mich ob ein Logik Fehler meinerseits vorliegt oder ob es sich um einen Bug handelt.

In dem angehängten Ensemble, kann zwischen den Primary und Core Randomize Modulen hin- und hergeschaltet werden und die Trigger Frequenz des Clock Oscs sowie die Wahrscheinlichkeit der Ticks eingestellt werden.

So wie es scheint, laufen die beiden Primary Randomizer synchron! Sie geben zum selben Zeitpunkt den selben Wert aus, wenn auch teilweise mit 1 subtrahiert.
Wegen des Separators im Probability Makro werden nur entsprechende Werte durchgelassen.
Hab mal den miniACEW drangehängt. Dann kann man es schön sehen.

Danke Mark. Da hatte ich mir die Werte wohl nicht genau genug angeschaut.
Konnte den Zusammenhang jetzt auch ohne den Wahrscheinlichkeits-Makro nachvollziehen.

Hatte zum einfachen Testen von synchron oder nicht-synchron zwei Randomizer mit den selben Werten, sprich zweimal den Wert 0 und den Bereich 1 gewählt.
Bei einem Randomizer mit dem Wert 0.5 und dem Bereich 0.5 und einem Randomizer mit 0 und 1 lässt sich die Synchronität besser erkennen.
Meine Annahme war also einfach falsch und die Sequenzen sind nicht einmalig pro Modul, sondern lediglich phasenverschoben, invertiert oä..
Dann wird es wohl auf die Core-Lösung rauslaufen..

Mir fiel es gerade wie Schuppen von den Augen:

Da die Primary Randomizer synchron gleiche Werte geben, obwohl der zweite R. seltener Events an seinem Input anliegen hat, müssen sie zwangsläufig ständig mit einer internen Clock und unabhängig vom Input Werte generieren. Und das wahrscheinlich mit Sample-Rate.

Deine Core Randomizer generieren nur dann Zufallswerte, wenn ein Event anliegt. Deshalb funktioniert die Core Variante.

grüße,
mark

Quietschboy hat geschrieben:Da die Primary Randomizer synchron gleiche Werte geben, obwohl der zweite R. seltener Events an seinem Input anliegen hat, müssen sie zwangsläufig ständig mit einer internen Clock und unabhängig vom Input Werte generieren. Und das wahrscheinlich mit Sample-Rate.

Sicher??? Hinten kommt jedenfalls nur bei Trigger EIN Event raus!
Wohingegen der andere Prim-Random nur mittels Switch zum Schweigen zu bewegen ist und wirklich unnütz CPU-Last verbrät.
Es wäre kompletter Irrsinn, das Ding intern ins Hamsterrad zu zwingen, aber wer weiss schon was NI in ihrer unendlichen Weisheit so veranstalten;)

Eventmanager hat geschrieben:Sicher???

nö, nicht explizit getestet. War nur meine Schlußfolgerung aus den Beobachtungen deines Ensembel.

Eventmanager hat geschrieben:Hinten kommt jedenfalls nur bei Trigger EIN Event raus!

Ja klar. Der aktuelle Zufallswert wird mit einem Event am Eingang abgefragt und auch nur dann augegeben.

Nochmal: Meine Behauptung ist, daß die Zufallswerte unabhängig von eintreffenden (Trigger-) Events, aber mit einer Clock ständig neu genereiert werden. Haben mehrere Randomizer Module den selben Startwert bei Init, so laufen sie synchron und liefern somit zu jeder Zeit den selben Wert.

QB

Quietschboy hat geschrieben: Nochmal: Meine Behauptung ist, daß die Zufallswerte unabhängig von eintreffenden (Trigger-) Events, aber mit einer Clock ständig neu genereiert werden. Haben mehrere Randomizer Module den selben Startwert bei Init, so laufen sie synchron und liefern somit zu jeder Zeit den selben Wert.

QB

Gut möglich das dem so ist. Aber wir spekulieren und meine Frage bleibt, warum um aller Welt, sollte NI sowas fabrizieren?
Sie tendieren eindeutig zu "Alles-ist-möglich, egal-was-es-kostet" aber hier macht das selbst für NI-Denke null Sinn. Es reicht doch das Ding nach Trigger aufzuwecken, mit einem Sample Versatz zum arbeiten zu bewegen und dann wieder zu anästisieren.
Selbst für NIs-Kack-auf-Ressourcen-Denke ist das starker Tobak.

Quietschboy hat geschrieben: Haben mehrere Randomizer Module den selben Startwert bei Init, so laufen sie synchron und liefern somit zu jeder Zeit den selben Wert.

QB

Das ist Zufall! Oder sie werden tatsächlich gleichzeitig schlafen gelegt und produzieren, da tatsächlich gleichzeitig aufgeweckt identische Ergebnisse. Computisierter "Zufall" ist auch nur ein Algorithmus und nicht wirklich zufällig.

Eventmanager hat geschrieben: Gut möglich das dem so ist. Aber wir spekulieren und meine Frage bleibt, warum um aller Welt, sollte NI sowas fabrizieren?
Sie tendieren eindeutig zu "Alles-ist-möglich, egal-was-es-kostet" aber hier macht das selbst für NI-Denke null Sinn. Es reicht doch das Ding nach Trigger aufzuwecken, mit einem Sample Versatz zum arbeiten zu bewegen und dann wieder zu anästisieren.
Selbst für NIs-Kack-auf-Ressourcen-Denke ist das starker Tobak.

Ruhig Blut, EventMan. Was ist denn schon Zufall. Fällt dir was ein? Schon gar in einem Computer?
Der Core Randomizer in Pavels Beispiel Ensemble entspricht doch dann deinen Vorstellungen, oder nicht? Er arbeitet und produziert nur dann einen Zufallswert, wenn ein Triggerevent ihn dazu bewegt. Richtig?
Blöderweise tut er das immer gleich. Nach jedem Ensemble-Neustart, Init (Repower) oder auch Re-Init (Switch). Beim ersten Trigger haste "Zufallswert" A, dann B und C und so weiter.
Also wie würdest du eine möglichst zufällige Zahl im Rechner produzieren wollen? Quantenverschränkung existiert nicht in deinem Algorythmus. Die gerade aktuelle Stellung von Andromeda zu Sirius ist in Reaktor nicht bekannt und noch nicht einmal die aktuelle Uhrzeit.
Was spricht also dagegen, gesetz daß jeder neue Trigger anhand irgendeiner mathematischen Formel eine völlig andere Zahl im angegebenen Bereich ausgibt, als "Zufallsquelle" die Anzahl irgendwelcher Clock-Ticks zu nutzen?
Wie hungrig ist denn das Randomizer Modul auf deinem Rechener? Ich denke der entsprechende Programmierer bei NI hat alles daran gesetzt, daß es diesbezüglich eben möglichst unauffällig arbeitet.

Quietschboy hat geschrieben: Wie hungrig ist denn das Randomizer Modul auf deinem Rechener?

Ich bin sehr zufrieden mit dem Teil, er ist äusserst effizient. Und genau deshalb habe ich Schwierigkeiten mit deiner Hypothese, das er permanent mit SR getriggert wird.