In der Tiefe: Validierungskonzept

[Tessi]

Ich halte das Ganze für ein Validierungsproblem. Damit wurde uns letztlich ein Bärendienst erwiesen weil es vielen von uns offenbar nicht mehr gelingt, das Verhalten vom Code sicher vorherzusagen. Eben weil nicht mehr klar ist, zu welchem Zeitpunkt eine Änderung als solche verarbeitet wird. Bei diesem Code:
[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.
Wird der obige Code aber umgeschrieben 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, denn nun kann die zweite Abfrage durchaus von der Aktion im ersten then-Zweig beeinflußt sein. Nur, sieht die zweite Abfrage das schon durch die erste Abfrage veränderte Ergebnis (das erwartet jeder "normale" Sprachen gewohnte Programmierer - im Gegensatz zum ersten Beispiel, wo er es eben nicht erwartet) oder sieht sie das erst im nächsten Durchlauf? Und wenn erst da, gilt der Wert dann als veränder oder nicht?

[highlight=epc]
a=0u08
if a>=10 then a=a+1 endif
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?
Ich würde jetzt einen in jedem Durchlauf inkrementierten Zähler erwarten...
[highlight=epc]
a=a+1u08
[/highlight]Endloszähler oder nicht? Wenn ja warum, wenn nein, warum nicht?
Hier meine ich mich daran erinnern zu können, das mal gesagt wurde, das dieses Statement nur einmal ausgeführt wird. Aber warum führt die Änderung von a im nächsten Durchlauf nicht zur erneuten Ausführung?

Warum werden die Statements in Code wie diesem dann aber doch mehrfach ausgeführt
[highlight=epc]
a=0u08
if xxx then a=a+1
b=a+1
c=b+1
d=c+1
[/highlight]Oder ändern sich b, c und d gar nicht mehr?

Irgendwie habe ich trotz (oder vielleicht gerade wegen?) aller Ausführungen keine klare Vorstellung (mehr) davon, wann eine Bedingung überhaupt geprüft wird und wann scheinbar unbedingte Statements wie
[highlight=epc]
b=a+1
[/highlight]überhaupt ausgeführt werden.

[enertegus]

[highlight=epc]
if change( Rollo_Sonnenaufgang_m_s ) then {
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08;
} endif;
write('0/0/1'u08,10);
} endif
[/highlight]
So, das Ganze ist echt ein Initialisierungsproblem: Die innere If-Abfrage hat beim Systemstart ein invalid-Flag und wird daher ausgewertet. Das Umzubauen ergibt ein größeres Problem - ob und wie wir das für das nächste Release ändern, ist noch nicht abzusehen.

Ein Workaround ist wie immer die Empfehlung, die Verschachtelung zu vermeiden (ich hör Euch schon aufheulen).
[highlight=epc]
if change( Rollo_Sonnenaufgang_m_s ) and ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08
} endif
[/highlight]

[saft6luck]

[highlight=epc]
Der obige Code kann direkt umgeschrieben werden in:

Um etwas präziser zu sein: Der Code wird direkt so umgeschrieben

Ich denke, jetzt ist klar, warum else nutzen eine schlechte Idee sein kann und warum ich der Meinung bin, das das verboten werden müßte.

Die Sache mit 'else' ist ja nun ein alter Hut. Allerdings sollte genau die Umschreibung nicht identisch mit der Funktionsweise von else sein. Wenn man es also verbieten sollte, dann weil es mit der Event-behafteten Funktion des IFs wenig Sinn macht (Hauptebene). Was soll auch ablaufen, wenn der Event nicht eintritt???

In allen Unterebenen (Verschachtelung) mach es jedoch durchaus Sinn, allerdings ist hier die zweifelhafte Umschreibung unglücklich.

Else muss ein richtiges 'entweder-oder' werden. Wer die momentane Bedeutung will, soll es auch entsprechend 'umschreiben'.

[saft6luck]

Also ein Aufruf der Art
[highlight=epc]
a=10u08
write_direct('9/2/0'u08, a, Testwert)
a=11u08
[/highlight]

ergibt bei Dir dann 11 und nicht 10?

Nicht nur bei mir!

PS: Im übrigen bin ich der Meinung das ELSE verboten werden müßte weil es Nebenwirkungen hat!

Nein, es gehört IMHO nur vernünftig implementiert.

[pio]

ELSE hat durchaus seine Berechtigung, man muss nur im Kopf behalten, dass auch Else nur dann ausgeführt wird, wenn die Abfragebedingung sich überhaupt geändert hat. Hat sich nix geändert, wird werde then noch else ausgeführt.

Ausnahme:
Bei inneren geschachtelten ifs wird imer geprüft, sofern die äussere if-Bedingung sich geändert und damit das äussere if überhaupt durchlaufen wird.

Aber natürlich könnte man auch in inneren ifs alles mit if BLA und if ! BLA erschlagen.

[bmx]

Welche denn?

[highlight=epc]
a=10u08

if a==10 then a=a+1 else a=a-2 endif
[/highlight]

Beim Programmstart ergibt sich für a nach dem ersten Durchlauf das a=9 ist.

Wenn Du im Debugger dann a=10 setzt, wird a=11.
Begründung:

Der obige Code kann direkt umgeschrieben werden in:

[highlight=epc]
a=10u08

if a==10 then a=a+1 endif
if a!=10 then a=a-2 endif; /* else */
[/highlight]

1.) a wird 10 zugewiesen
2.) a ist gleich 10 und wird damit um 1 erhöht -> a=11
3.) a ist nicht 10 und damit wird a um 2 dekrementiert -> a=9

Nun manuell a=10 über Debugger zuweisen:

1.) a=10
2.) da a sich geändert hat, greift das validierungsschema und für die erste Anweisung im If-Zweig aus also a um einen erhöhen -> a=11
3.) gegenüber der vorigen Situation im Durchlauf hat sich nichts geändert, da a nun gleich 11 und damit nicht 10 ist -> a bleibt 11

Ich denke, jetzt ist klar, warum else nutzen eine schlechte Idee sein kann und warum ich der Meinung bin, das das verboten werden müßte.

Gruß,
Bernd

[Tessi]

PS: Im übrigen bin ich der Meinung das ELSE verboten werden müßte weil es Nebenwirkungen hat!

Welche denn?

[bmx]

Das einzige, wie Du das umgehen kannst, ist für jeden kritischen write eine eigene Variable anzulegen und den zu schreibenden Wert vorher dieser Variable zuzuweisen.

So geht es eben leider nicht.

Folgendes geht jedenfalls nicht:

[highlight=epc]
//Inline-Makros
:begin write_direct(GA, Value, Name)
Name^temp = Value
:return Name^temp = Value; write(GA, convert( Name^temp, Value))
:end
[/highlight]

Also ein Aufruf der Art
[highlight=epc]
a=10u08
write_direct('9/2/0'u08, a, Testwert)
a=11u08
[/highlight]

ergibt bei Dir dann 11 und nicht 10?

Gruß,
Bernd

PS: Im übrigen bin ich der Meinung das ELSE verboten werden müßte weil es Nebenwirkungen hat!

[saft6luck]

Ist das real die "programmiererverständliche" Erklärung von "alles was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid"?

Tja, so erlebe ich das ...

[Tessi]

@Tessi:
Ich habe noch keinen Hinweis im Handbuch gefunden, dass die Reihenfolge im Code nicht der Ausführungsreihenfolge entspricht.

Ich auch nicht - aber auch keinen Hinweis auf das Gegenteil. Sehr wohl aber immer wieder Hinweise, das man den Code eben nicht wie C-, BASIC- oder Java-Code lesen darf.

Die angesprochene parallele Ausführung enthält auch hierzu keinen Anhaltspunkt (trägt eher zur Verwirrung bei). Wenn tatsächlich umsortiert wird, muss das entsprechend beschrieben werden oder soll die von Michael gerne zitierte Blondine sich da einen Reim drauf machen müssen???

Es wurde irgendwo angedeutet, das der Parser/Compiler da irgendwie Strukturen erzeugt, die die gegenseitigen Abhängigkeiten der Daten und Aktionen beschreiben. Das legt auch den Verdacht nahe, das dabei die Reihenfolge eben nicht (nur) vom Code abhängig ist und das dabei durchaus mal etwas ganz anderes herauskommt, als bei definiert sequenzieller Abarbeitung. Ich weiß es aber nicht, weil es eben nicht beschrieben wird. So werde ich also das ein ums andere Mal überascht, wenn etwas anderes geschied, als ich mir vorgestellt hatte.

Verschachtelungen sind beim eibPC leider notwendig, den nur auf der obersten Ebene gilt der vereinfachte Syntax (das Validierungsschema = Event-getrieben). Die nächsten Ebenen sind eigentlich normale Logik, auch wenn das im Handbuch stark verkompliziert ist.

Ist das real die "programmiererverständliche" Erklärung von "alles was innerhalb eines then- oder else-Zweiges steht wird vor Ausführung des Zweiges invalid"?

(Wo findest du denn den Hinweis, dass man Verschachtelungen vermeiden soll? Ich hab da nur else in Erinnerung?).

In der aktuell angebotenen Version - HandbuchEibPC-15.odt, 2010-07-23 - steht auf Seite 46

Wir empfehlen Anfängern die Vermeidung von verschachtelten if-Anweisungen.

Dabei muß "Anfänger" wohl bezüglich EPC gesehen werden. Programmiererfahrung mit "normalen" Sprachen scheint eher verwirrend als hilfreich zu sein.

Ansonsten gebe ich dir Recht, ob ein Kommando ausgeführt wird, oder nicht definiert sich laufend neu

Das wird Enertex so wohl nicht widerspuchslos im Raum stehen lassen wollen, aber subjektiv kommt es einem schon manchmal so vor, wenn man immer wieder umlernen muß, weil das Validierungsschema vereinzelt eben nicht das macht, was man jetzt erwartet hätte und man sich das zunächst einfach nicht erklären kann.

[saft6luck]

So wie ich das sehe, wird's wahrscheinlich einen Compilerfehler geben wegen dem mehrfachen a=a+1.

Hm, das wird wohl komplizierter, aber man darf sich das als beliebige Änderung von a vorstellen.

Das einzige, wie Du das umgehen kannst, ist für jeden kritischen write eine eigene Variable anzulegen und den zu schreibenden Wert vorher dieser Variable zuzuweisen.

Das ist der Grund für die Frage. So geht es eben leider nicht.

Im Falle eines Makros mußt Du dann eben mit einer lokalen variable arbeiten um sicherzustellen, das jeweils pro write eine andere Variable zuständig ist.

Folgendes geht jedenfalls nicht:
[highlight=epc]
//Inline-Makros
:begin write_direct(GA, Value, Name)
Name^temp = Value
:return Name^temp = Value; write(GA, convert( Name^temp, Value))
:end
[/highlight]

[bmx]

So wie ich das verstehe, wird bei allen writes doch der gleiche Wert ausgegeben, oder?

So wie ich das sehe, wird's wahrscheinlich einen Compilerfehler geben wegen dem mehrfachen a=a+1.

Das einzige, wie Du das umgehen kannst, ist für jeden kritischen write eine eigene Variable anzulegen und den zu schreibenden Wert vorher dieser Variable zuzuweisen.
Im Falle eines Makros mußt Du dann eben mit einer lokalen variable arbeiten um sicherzustellen, das jeweils pro write eine andere Variable zuständig ist.

Gruß,
Bernd

[saft6luck]

1. Könnte man nicht ein write_direct() Kommando einführen, dass den aktuellen Wert von Variablen in den Puffer schreibt?

Wie sieht das eigentlich mit Variablen aus?
z.B.
[highlight=epc]
a=1u08
b=a
if systemstart() then write(GA,a); write(GA,b) endif
a=a+1
c=a
if systemstart() then write(GA,c) endif
a=a+1
d=a
if systemstart() then write(GA,d) endif
[/highlight]
So wie ich das verstehe, wird bei allen writes doch der gleiche Wert ausgegeben, oder? Wie sieht es mit b,c,d aus? Sind die nach dem Zyklus auch alle gleich?

2. Kann die Darstellung von else nicht doch geändert werden? Es gibt wohl nur sehr wenige Leute, die bei einem else die sofortige Ausführung des alternativen Codes erwarten, oder? Und wenn man das brauch, kann man ja die Variante mit dem ! einbauen, oder?
Bei mir führt die eigenwillige Ausführung jedenfalls regelmäßig zu extrem umständlichen Konstrukten.

[enertegus]

Mein ganz persönliches Problem ist, das ich trotzt aller bislang gelesenen Erklärungen in vielen Fällen immer noch nicht sicher vorhersagen kann, was ein gegebener Code tatsächlich tun wird, da ich nicht weiß, was der Compiler tatsächlich daraus macht und was da zur Laufzeit dann passiert.

Für die meisten Funktionen ist recht genau erklärt, was sie tun. Aber wann sie es tun, dafür wir immer auf das Validierungsschema verwiesen und genau dieses hat sich mir immer noch nicht lückenlos erschlossen.
Ich glaube vorhersagen zu können, was ein Statement machen wird, wenn es abgearbeitet wird, aber ich kann einfach immer noch nicht sicher sagen, wann ein Statement abgearbeitet wird, und wann nicht. Geht mir das jetzt allein so oder habe ich da noch Leidensgenossen?

Ich helfe gerne, wenn es konkreter wird. saft6luck und pio mit dem SPS Konzept (Zustandsautomat) haben da recht (aber jeder nur ein Stein, und nicht bevor ich es sage).
Also frage, damit ich antworten kann.

[enertegus]

Oder hab ich da etwas im Handbuch (ok, ich hab noch v15) überlesen? Sollte ansonsten vielleicht klar beschrieben werden.

Das steht im Handbuch 16 der Betaversion oder hier
https://knx-user-forum.de/attachment...skonzept-5.pdf