In der Tiefe: Validierungskonzept

[no sleep]

Da hast Du was falsch verstanden.

Gut, dass ich das auch nicht verstehen muss, weil ich mir "sowas" nie antun würde.
Aber euren Kunden solltet ihr soweit entgegenkommen, dass sie in der Lage sind, es zu verstehen, meinste nicht?

[enertegus]

Das ist eben die Frage.

Da hast Du was falsch verstanden.

[no sleep]

Was ist denn ein "bedingtes XOR"?

Das ist eben die Frage. Normalerweise sollte es sowas garnicht geben, aber wenn lt. Doku eine OR-Verknüpfung ihren Ausgang abhängig vom eigenen Zustand (eine Verknüpfung mit eigenem Zustand - hä?) und von der Änderung ihrer Eingangsgrössen ändert, es es eben keine logische ODER-Verknüpfung mehr sondern irgendwas anderes.

[Tessi]

Dass damit je nach Zustand ein "bedingtes XOR" gebaut wird, scheint keine Rolle zu spielen.

Was ist denn ein "bedingtes XOR"? Und warum sollte aus dem OR ein XOR werden, nur weil der Ausdruck nur bei Änderungen von mindestens einem seiner Teilausdrücke erneut ausgewertet wird? Habe ich da etwa eine weitere Nebenwirkung des VKs noch nicht erkannt?

[no sleep]

Der Text (im Bild) ist geeignet, einen Knoten im Hirn zu verursachen.

Genau das ging mir gestern schon durch den Kopf. Mir als "aussenstehendem Programmierer" fällt die Kinnlade runter wenn ich lese, dass eine klar definierte, logische ODER-Verknüpfung in Ihrer Funktion von der Zustandsänderung der mit ihr zu verknüpfenden Elemente abhängig ist. Dass damit je nach Zustand ein "bedingtes XOR" gebaut wird, scheint keine Rolle zu spielen.
In meiner Ausbildung hatten wir mal so ein "Spass-Logik-DINA4-Blatt" am Schrank in der Werkstatt hängen.
Dort waren fiktive logische Gatter in der Form "vielleicht", "warum nicht", "oder nicht", "doch" usw. vorhanden - jetzt weiss ich endlich, was damit gemeint war.

[saft6luck]

Nein, das ist sogar erwünscht!
Aber zu Deiner Frage:
a=a+1u08
etc. steht das ja schon explizit mit fast den gleichem Beispiel. Wenn da noch was unklar ist, so beziehe Dich halt darauf. Wir ergänzen gerne die Beispiele.

Bild siehe Posting oben!

Der Text (im Bild) ist geeignet, einen Knoten im Hirn zu verursachen.

Variablen:
- Im angegebenen Text vermutet man zuerst ein change() von x und y, 'da sich x und y im nächsten Zyklus nicht mehr ändert'. (Hast du wirklich konstante Variablen im Baum mit Abhängigkeiten???)
- Du versuchst einen Baum der Abhängigkeiten ohne jegliches Bild zu vermitteln, wobei du speziell auf Eigenschaften "vererbt sich", "von unten nach oben" und "invalidiert sich" etc. eingehst. Es mag ja sein, dass du das im Kopf hast, aber der Leser überließt das eher, oder macht sich u.U. ein falsches Bild. Später verwendest du dann auch noch diese Abhängigkeiten um das Verhalten in Spezialfällen zu beschreiben ...
- "da aber ODER bereits auf EIN steht"? Da kommt plötzlich auf, dass ODER auch ein Element im Baum ist oder sprichst du vom ODER Ausdruck?

Generell:
Beispiele, die solch einen Text erklären haben Markierungen, Nummern, Symbole oder irgend eine Form des näheren Bezuges zum Text.

[enertegus]

Nein, das ist sogar erwünscht!
Aber zu Deiner Frage:
a=a+1u08
etc. steht das ja schon explizit mit fast den gleichem Beispiel. Wenn da noch was unklar ist, so beziehe Dich halt darauf. Wir ergänzen gerne die Beispiele.

Im Betaforum hat mir ein User noch einen Tipp gegeben, wo Dein Problem
if a==10 then a=a+1 else a=a-2
iegen könnte. Ich werde das morgen ins Handbuch einpflegen und hoffe die Sache wird allen klarer.

[enertegus]

Ich möchte das System EPC einfach richtig und vollständig verstehen, das ist doch nicht zu viel verlangt?

Nein, das ist sogar erwünscht!
Aber zu Deiner Frage:
a=a+1u08
etc. steht das ja schon explizit mit fast den gleichem Beispiel. Wenn da noch was unklar ist, so beziehe Dich halt darauf. Wir ergänzen gerne die Beispiele.

[Tessi]

Obige Beispiele haben keine gültige Syntax, der EibParser übersetzt sie nicht, und daher brauch ich nicht erklären, warum Sie nicht funktionieren, da sie einfach gar nicht funktionieren.

Es geht um grundsätzliche Prinzipien und die Fragen werden wegen Formfehler abgewiesen.

OK, ich habe mich - schreibfaul wie ich bin - nicht an die ganz korrekte Schreibweise gehalten, aber um die ging es mir auch noch nicht - die ist dokumentiert und wird vom Parser überwacht. Mir geht es um die logischen Fallstricke im Code, die Dinge, die nicht vom Parser bemängelt werden aber ggf. sich nicht so verhalten, wie ich mir das vorstelle, weil ich beim Entwurf irgendeine Eigenheit des EPCs nicht bedacht habe - weil ich das nicht aus der Dokumentation so herausgelesen habe.
Mir geht es momentan um das grundsätzliche Verständnis - was genau machen Parser und EPC tatsächlich aus dem Code - vor allem verglichen mit dem, was man abweichend davon als "normaler" Programmierer erwarten würde.
Darum bleibt die Frage: Welches Beispiel wäre auch bei korrekter Einhaltung der Syntax denn generell nicht zulässig. Und mit welchem Code statt des fehlerhaften würde ich dann das erwartete/vermutete Verhalten beim EPC bekommen?

Ich habe keinen noch keinen Code, der nicht tut was ich möchte - die paar bisherigen Supersimpellogiken funktionieren - sondern ich habe einen Menge Wünsche/Probleme deren Lösung noch codiert werden muß. Leider habe ich kein zweites Gebäude als "Labor" und am lebenden Objekt (eben dem eigenen Heim) verträgt der FAF (Family Acceptance Factor) keine ausgiebigen Try-and-Error-Sessions. Wenn da mal richtig was schief geht, brauche ich den Code hier nicht mehr analysieren zu lassen, dann hat meine Familie den EPC schneller als unzumutbare Störquelle entsorgt als irgend jemand hier antworten kann!
Deshalb möchte ich möglichst viel schon vorher klären. Deshalb suche ich nach grundsätzlichen Prinzipien und allen Ausnahmen davon. Und es ist nicht nur anstregend, sie diese aus einer Hand voll Beispielen ableiten zu müssen - es ist schlicht nicht möglich, da diese auch alle zusammen eben nicht alle möglichen Eventualitäten abdecken.
Ich kann mich statt dessen auch ein paar Wochen lang hinsetzen und ewig lange Listen von Anforderungen schreiben, diese hier veröffentlichen und darauf hoffen/warten, das man mir dann diese ganz genauen "Beispiele" in funktionierenden Code umsetzt - aber so ist das ja wohl nicht wirklich gemeint, oder?
Ich möchte das System EPC einfach richtig und vollständig verstehen, das ist doch nicht zu viel verlangt?

[enertegus]

Ich verstehe ja auch, wenn Fragen mit beantwortet werden.
Aber dazu muß die Dokumentation auch tatsächlich alles vollständig abdecken. Das ist aus meiner Sicht bei der EPC-Doku noch nicht der Fall.

Dann frag doch ganz konkret mit einem Beispiel, welches sich anders verhält, als Du Dir es denkst.
Obige Beispiele haben keine gültige Syntax, der EibParser übersetzt sie nicht, und daher brauch ich nicht erklären, warum Sie nicht funktionieren, da sie einfach gar nicht funktionieren. Wenn es um das Thema "if a>10 then a=a+1 endif" geht, bin ich zwar der Meinung, dass es schon beschrieben ist, aber ich kann gerne nochmals ausholen (und werde das Manual ggf. erweitern).

[Tessi]

Schau doch noch mal in Ruhe das PDF dieses Threads durch. Da ist das genau mit Beispielen erläutertet.

Die Crux mit Beispielen ist, das diese immer nur einen begrenzten Teil darstellen können. Daher gelingt es auch nicht, daraus die zugrunde liegende Logik eindeutig zu rekonstruieren und somit Rückschlüsse auf mein jeweiliges Problem ziehen zu können. Aber das sollte auch gar nicht nötig sein, denn den jeweiligen Entwicklern muß die Logik doch vollständig bekannt sein. Da sollte es nicht all zu schwer sein, sie auch komplett formal zu beschreiben.

Die If-Abfrage invaldiert "ihren" then Zweig, so dass dieser im Falle einer wahren Bedingung auch ausgeführt wird. Somit hängt der then Zweig natürlich nicht mehr unmittelbar von der Validierung der Variablen im then-Zweig ab, sondern von der Validierung der if-Abfrage.

Diese "Antwort" wiederholt doch die Passage, die ich hinterfragt habe, das hilft mir nicht weiter...

Ist das jetzt ein 'ja' oder 'nein' oder 'ja, aber mit ein paar Ausnahmen' oder 'nein, denn ... '?

Das war und ist auch immer noch auch meine Frage...


Ich verstehe ja auch, wenn Fragen mit beantwortet werden.
Aber dazu muß die Dokumentation auch tatsächlich alles vollständig abdecken. Das ist aus meiner Sicht bei der EPC-Doku noch nicht der Fall.

[saft6luck]

Die If-Abfrage invaldiert "ihren" then Zweig, so dass dieser im Falle einer wahren Bedingung auch ausgeführt wird. Somit hängt der then Zweig natürlich nicht mehr unmittelbar von der Validierung der Variablen im then-Zweig ab, sondern von der Validierung der if-Abfrage.

Ist das jetzt ein 'ja' oder 'nein' oder 'ja, aber mit ein paar Ausnahmen' oder 'nein, denn ... '?

Für mich persönlich ist deine Aussage wenig hilfreich, genauso wie das ewige "invlaidieren" etc. wenn man überhaupt nicht sagen kann, wer wann und wie ausgeführt wird und man diese Flags auch nirgends sehen oder beeinfussen, geschweige denn debuggen kann.

Was soll den eine Aussage wie: "Tun sie auch nicht, sondern eben von einem auf den nächsten Zyklus." wenn die ganze Zeit klar ist/war (siehe auch dein Beispiel in deinem angeführten Dokument), dass der else-Zweig sofort zusätzlich ausgeführt werden kann?

Soll ich jetzt auch noch bedenken, dass im nächsten Zyklus der else-Zweig abgearbeitet werden kann und sich die entsprechende Bedingung schon längst geändert haben kann? Ist das deine Art von Determinismus?

Für mich steht ein Neuanfang an, so oder so!

[enertegus]

Ist es richtig, das alles, was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid wird und somit alle inneren Statements sich so verhalten, wie man das als Programmierer von anderen Sprachen gewohnt ist - also immer ausgewertet werden, egal ob sich ein Parameter geändert hat - also quasi das Validierungsschema hier nicht zur Anwendung kommt? Unterliegt - vereinfacht ausgedrückt - also nur die äußerste Bedingung einer verschachtelten Struktur dem Validierungsschema, die inneren dann nicht mehr?

Schau doch noch mal in Ruhe das PDF dieses Threads durch. Da ist das genau mit Beispielen erläutertet.
Die If-Abfrage invaldiert "ihren" then Zweig, so dass dieser im Falle einer wahren Bedingung auch ausgeführt wird. Somit hängt der then Zweig natürlich nicht mehr unmittelbar von der Validierung der Variablen im then-Zweig ab, sondern von der Validierung der if-Abfrage.

[Tessi]

[highlight=epc]
a=10u08
if a==10 then a=a+1 else a=a-2 endif
[/highlight]Im ersten Zyklus wird also a=11. Damit hat sich a geändert, ist ungleich 10 und so wird im nächsten Zyklus a=9. Damit hat sich a wieder geändert, ist ungleich 10 und so wird im folgenden Zyklus a=7. Und so weiter? Da a auch nach Unterlauf immer ungerade bleiben wird, hätte ich so eine Art Endlosschleife gebaut - hier nicht sonderlich tragisch, aber falls gesendet werden würde...
Ich meine irgendwo gelesen zu haben, das genau das nicht passiert, aber warum sollte das so sein?

Wird der obige Code aber intern umgesetzt in:
[highlight=epc]
if a==10 then a=a+1 endif
if a!=10 then a=a-2 endif; /* else */
[/highlight]dann ändert das die Situation vom Verständnis her, dann frage ich mich, ob die zweite Abfrage den schon veränderten Wert gleich sieht, oder erst im nächsten Durchlauf, oder erst einmal gar nicht und a muß "von außen" erneut verändert werden, damit die beiden Abfragen überhaupt erneut ausgewertet werden...

Das letzte Beispiel:
[highlight=epc]
a=0u08
if a>=10 then a=a+1 endif
[/highlight]enthält leider einen Copy&paste-Fehler. Es sollte so aussehen:
[highlight=epc]
a=0u08
if a>=0 then a=a+1 endif
[/highlight]Vergleichbar dem ersten Beispiel: Ist es jetzt ein Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?

Wie sieht es mit diesem Code aus:
[highlight=epc]
a=0u08
if xxx then a=a+1
b=a+1u08
c=b+1u08
d=c+1u08
[/highlight] Ist der OK und werden b, c und d angepasst wenn a sich ändert? Wenn ja, schon im gleichen Zyklus oder erst im jeweils folgenden, wenn nicht, warum nicht? Oder wird
[highlight=epc]
b=a+1u08
[/highlight]ebensowenig vom Parser akzeptiert wie
[highlight=epc]
a=a+1u08
[/highlight]
?

Ist es richtig, das alles, was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid wird und somit alle inneren Statements sich so verhalten, wie man das als Programmierer von anderen Sprachen gewohnt ist - also immer ausgewertet werden, egal ob sich ein Parameter geändert hat - also quasi das Validierungsschema hier nicht zur Anwendung kommt? Unterliegt - vereinfacht ausgedrückt - also nur die äußerste Bedingung einer verschachtelten Struktur dem Validierungsschema, die inneren dann nicht mehr?

[enertegus]

[highlight=epc]
if a==10 then a=a+1 else a=a-2 endif
[/highlight]dachte ich, wenn sich a ändert, dann wird entweder then oder else ausgeführt, aber egal was dabei passiert, garantiert nie beide zusammen.

Tun sie auch nicht. EDIT: Im Beispiel kann das aber schon passieren, da ja im then/else-Zweig direkt die Variable verändert wird.

[highlight=epc]
a=0u08
if a>=10 then a=a+1 endif
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?

Nein, a ist kleiner 10?

[highlight=epc]
a=a+1u08
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?

Weil es vom Eibparser nicht akzeptiert wird.