Bug in ScritedElements?

[MrNo]

Oje, ja das war ein Denkfehler meinerseits. Sorry für den Aufwand den ich verursacht habe.
So kann das mit Script natürlich nicht gehen. Ich hatte versucht das Ganze gut reproduzierbar zu machen und mich nach mehreren Versuchen ohne Erfolg zu früh gefreut und zu wenig nachgedacht

Ich werde noch mal drangehen und wenn ich etwas Neues habe melde ich mich wieder.
LG

[MrNo]

Hallo hier bin ich wieder

so, noch ein Versuch...
Ich habe - glaube und hoffe ich zumindest - nun eine reproduzierbares Setup (s. Zip).
Die Scripts und Berechnungen sind zwar völlig sinnfrei, aber nur so habe ich es geschafft das Problem einigermaßen zu reproduzieren. Hoffentlich habe ich nicht wieder einen Denkfehler wie beim letztenmal...

Folgendes habe ich gemacht:
- Das Testnetz (testnet1.mbn) geladen und Lesson1 und Lesson2 geladen. Neterror Häkchen manuell auf Lesson 2 gesetzt (s. Screenshot)
- ScritedElements geladen. Multitreading eingeschaltet.
- RUN.as laufen lassen für ca. 10 bis 20 Durchläufe (Trainings), dann manuell abgebrochen
- ShowErrors.as laufen lassen (Ausgabe der Neterror im Trace-Fenster, zur Vereinfachung statt CTRL-U)
- Dann diese Ausgabe mit dem Stockmanager verglichen

Im Screenshot ist ein Beispiel (gelbe Markierungen) wo es Unterschiede im NetError gibt.
Manchmal gibt es bei 10 Durchläufen auch keinen Unterschied, aber es sollte hoffentlich bei mehreren Versuchen reproduzierbar sein.

Wie früher schon gesagt, hatte ich das Problem mit älteren Membrain-Versionen (vor Multithreading) nicht.

Falls noch Infos fehlen bitte melden

LG

[TJetter]

Ich habe mittlerweile in Vorbereitung des nächsten Releases eine Race Condition gefixt, die potenziell so ein Verhalten erzeugen könnte. Das würde auch zu der Beobachtung passen, dass es nur ab und zu auftritt (also Timing-abhängig und ggf. auch abhängig vom Rechner bzw. dessen Performance).
Ich konnte allerdings den Fehler weder mit dem aktuellen Release reproduzieren, noch mit dem Release, das gerade in Vorbereitung ist.
Vielleicht ist es ja möglich, den Test mit dem nächsten Release noch einmal zu wiederholen? Das wird voraussichtlich in ein paar Wochen sein.

Viele Grüße

PS: Wenn man die Schleife im Code "ShowErrors.as" geringfügig ändert, dann werden die Fehler in der selben Reihenfolge ausgegeben wie im Stock Manager, das erleichtert den Vergleich
-->
for (i=stockSize; i>=1; i--)
{
if (!LoadNetFromStock(i))
{
...

[TJetter]

Hallo nochmal,

mit ein wenig Script-Erweiterung (siehe Anhang) kann ich das Problem nun doch reproduzieren.
Das Script bereitet alles vor und führt den Test selbständig durch. Es bricht beim Erkennen eines Problems mit einer entspr. Fehlermeldung im Trace Fenster ab. Einzige Einstellung, die manuell vorzunehmen ist: Checkbox "Use normalized values" bei der Konfiguration der Net Error Berechnung deaktivieren. Das lässt sich aktuell (noch) nicht per Script durchführen.

--> Das Problem scheint nur aufzutreten, wenn das sogenannte "Lesson-based Multi Threadings" aktiviert ist. Manchmal tritt es sehr schnell auf, manchmal erst nach weit über 100 Testiterationen.

Ich werde der Sache nachgehen und mich hier bei Neuigkeiten wieder melden.

Viele Grüße und Danke nochmal für die Mühe!

[TJetter]

OK, hier folgt nun die Analyse:
- Es handelt sich nicht um einen Bug
- Die Erklärung liegt in der bei Flotaing-Point Arithmetik inhärenten Ungenauigkeit und damit einhergehenden Effekten wie z.B. der Nicht-Gültigkeit von mathematischen Gesetzen (z.B. Assoziativ- und Distributivgesetze, vgl. https://de.wikipedia.org/wiki/Gleitkommazahl)

Der Effekt ist folgender:
- Während des Trainings mit "Lesson-based Multithreading" wird die Netzfehlerberechnung (genauer: Die Aufsummierung darin) durch die Aufteilung der Net Error Lesson wie folgt durchgeführt (hier ein Beispiel mit zwei Threads und 6 Summanden):
S = (S1 + S2 + S3) + (S4 + S5 + S6)
- Bei der Berechnung des Netzfehlers außerhalb des Trainings ("Evaluate Net Error") wird die Summation wie folgt durchgeführt:
S = S1 + S2 + S3 + S4 + S5 + S6
--> Das ist mathematisch natürlich das Selbe. Bei Anwendung von Gleitkommaarithmetik treten aber unvermeidlich Unterschiede auf, da jede Zwischensumme auf eine Gleitkomma-Abbildung passen muss und es nicht unendlich viele Gleitkomma-Zahlen gibt (bei endlicher Auflösung). MemBrain arbeitet mit 64 Bit Gleitkomma-Arithmetik. Das bedeutet Ungenauigkeiten in der Größenordnung der 16. signifikanten Dezimalstelle.
Ein Test-Script, das die Abweichungen berechnet und ausgibt, zeigt, dass der Fehler immer (auch bei tausenden von Durchläufen) in dieser Größenordnung bleibt.
In der vorliegenden Implementierung der "Scripted Elements" werden diese winzigen Fehler künstlich vergrößert (z.B. mit Vergleichen mit Schwellwerten). Dadurch werden sie sichtbar. Im Rahmen der natürlichen Fehlereffekte bei Gleitkommaarithmetik ist aber alles technisch in Ordnung.

Viele Grüße

[MrNo]

Hallo,

so, nach etwas längerer Zeit habe ich mal wieder in das Forum geschaut.
Daaanke für das Nachforschen, bestimmt war es recht zeitaufwendig. Die Erklärung kann ich nachvollziehen.
An Gleitkommaungenauigkeiten hatte ich auch schon mal gedacht, da es früher dieses Verhalten nicht gab, dann aber nicht weiter betrachtet.

Also, ich verstehe es jetzt so:
1. Die Anzeige im Stock Manager kann falsch sein, wenn man das Netz aber später mit Ctrl-U nachberechnet ist der Wert richtig.
2. Der Stockmanager speichert aufgrund der Problematik ggf. nicht das beste Netz weg.

Vielen Dank noch einmal, jetzt weiß man was passiert und kann damit entsprechend umgehen.
LG

P.S. gibt es eigentlich eine Möglichkeit das Trace-Fenster zu vergrößern?

[TJetter]

Hallo,

1. Die Anzeige im Stock Manager kann falsch sein, wenn man das Netz aber später mit Ctrl-U nachberechnet ist der Wert richtig.

Das Verständnis ist technisch richtig, aber der Begriff "falsch" stimmt nicht. Ich würde einfach sagen "anders". Bei beiden Werten handelt es sich um Zahlen, die im Rahmen der verwendeten 64 Bit Gleitkommaarithmetik übliche Fehler aufweisen (ca. 16. signifikante Stelle). Man kann nicht wirklich sagen, dass der eine Wert "richtig" ist und der andere "falsch". Korrekt ist aber die Aussage: "Ctrl + U liefert den Wert, den MemBrain ohne Multi threading liefert. Bei Anwendung von Multi threading können die Gleitkommafehler im Rahmen der normalen Ungenauigkeiten anders ausfallen als mit Ctrl + U.

Der Stockmanager speichert aufgrund der Problematik ggf. nicht das beste Netz weg.

Auch hier ist das Verständnis technisch korrekt. Aber man kann nicht sagen, welches Netz "besser" ist, da sich alles im Rahmen der Rechenungenauigkeit bewegt und der eine Netzfehler nicht "richtiger" ist als der andere.

P.S. gibt es eigentlich eine Möglichkeit das Trace-Fenster zu vergrößern?

Nein, aktuell nicht und es stört mich immer wieder selbst bei der Arbeit Ich habe das deshalb jetzt mal auf die Liste der Verbesserungsvorschläge genommen!

[MrNo]

okay, Danke. Ich hatte mich ein wenig "salopp" ausgedrückt. Das Verständnis ist schon das gleiche.
LG

[TJetter]

P.S. gibt es eigentlich eine Möglichkeit das Trace-Fenster zu vergrößern?

Gerade ist MemBrain 12.00.00.00 online gegangen. Dort ist diese Möglichkeit gegeben.

Viele Grüße