Ankündigung

**saft6luck** · 10.02.2011, 12:58

Zitat von pio Beitrag anzeigen

Kein Widerspruch:

Sorry, aber das ist ein Widerspruch:

Laut Validierungsschema ist:

[highlight=epc]
if bla then ... else blub endif
[/highlight]

identisch zu

[highlight=epc]
if bla then ... endif
if !bla then blub endif
[/highlight]

Wenn also blah gleich eval(irgendwas) ist und laut Michael eval() immer entweder then oder else triggert, aber !eval() nicht bei AUS triggert, stimmt etwas nicht.

Ich warte auf die Erklärung von Michael.

**Tessi** · 10.02.2011, 13:32

Darüber bin ich noch gar nicht gestolpert...
Aber stimmt, so gesehen passt da was nicht...
Also was macht der Parser daraus wirklich?
Wird eval() da etwa als Sonderfall behandelt?

**enertegus** · 10.02.2011, 14:08

Zitat von Tessi Beitrag anzeigen

Darüber bin ich noch gar nicht gestolpert...
Aber stimmt, so gesehen passt da was nicht...
Also was macht der Parser daraus wirklich?
Wird eval() da etwa als Sonderfall behandelt?

Jein,
Der Parser löst
if A then x1 else x2 endif

auf in

if A then X1 endif
Not_if A then X2 endif

Das hätte daher bei eval() nicht die Konsequenz wie von saft6luck richtigerweise gefolgert, da Not_if die Negation selbst auswertet und nicht tatsächlich die Negation eingefüht wird.

**Tessi** · 10.02.2011, 17:08

Hm, einen Not_if Befehl habe ich im gesammten Handbuch nicht gefunden. Ist das so zu sagen nur eine interne Hilfskonstruktion des Parsers um das else vom then trennen zu können?
OK, ich kenne nur wenige Sprachen, die ein if mit integrierter Negation haben (mir fällt da jetzt nur Perl ein), aber wenn es denn schon mal vorhanden ist, könnte man das doch auch normal nutzen?

**enertegus** · 10.02.2011, 17:33

Zitat von Tessi Beitrag anzeigen

Hm, einen Not_if Befehl habe ich im gesammten Handbuch nicht gefunden. Ist das so zu sagen nur eine interne Hilfskonstruktion des Parsers um das else vom then trennen zu können?

Ja. Das kann man auch nicht einzeln ansprechen.

**pio** · 10.02.2011, 21:39

Zitat von saft6luck Beitrag anzeigen

Sorry, aber das ist ein Widerspruch:

Laut Validierungsschema ist:

[highlight=epc]
if bla then ... else blub endif
[/highlight]

identisch zu

[highlight=epc]
if bla then ... endif
if !bla then blub endif
[/highlight]

Wenn also blah gleich eval(irgendwas) ist und laut Michael eval() immer entweder then oder else triggert, aber !eval() nicht bei AUS triggert, stimmt etwas nicht.

Ich warte auf die Erklärung von Michael.

Für mich ist if bla then ... else blub endif nicht das gleiche wie der Zweizeiler, unabhängig von eval.

Wenn ich folgendes programmiere wird das deutlich:
Fall 1:

Code:

if bla then bla = ! bla else blob endif

Wenn sich im Zyklus N bla von EIN auf AUS verändert, wird im Zyklus N blob ausgeführt.
Wenn sich im Zyklus N bla von AUS auf ein ändert wird im GLEICHEN Zyklus N then ausgeführt und bla invertiert. Dann wird im NÄCHSTEN Zyklus N+1 einmalig blob ausgeführt, in den folgenden Zyklen passiert nix mehr.

Fall 2:

Code:

if bla then bla = ! bla endif
if !bla then blob endif

Wenn im Zyklus N bla auf EIN wechselt, wird im GLEICHEN Zyklus N then ausgeführt und bla invertiert. Dann wird im GLEICHEN Zyklus N einmalig blob ausgeführt, in den folgenden Zyklen passiert nix mehr.

Die Geschichte mit Eval() bzw. Not kann man sich vielleicht einfacher durch eine Erweiterung (wie bei der guten alten Integralgleichungslösungsgeschichte zur Vereinfachung) vorstellen.
Man muss sich das Not (also das ! ) als eine logische Verknüpfung zweier Ausdrücke vorstellen, so wie (a<10) and eval(Wohnen):

Substvar = 1
(Substvar<10) XOR eval(Wohnen)

ist das gleiche wie
! eval(Wohnen)

Das hilft zumindest beim Verständniss, auch wenn es im Parser letzlich so nicht umgesetzt ist (oder nur teilweise).

**saft6luck** · 10.02.2011, 23:23

@pio: Ich stimme dir zu, dass kein Mensch darauf kommen würde, dass if blah then ... else blub endif gleich dem Zweizeiler ist, außer Michael, denn er hat es so implementiert.

Für mich ist das nur noch absurd ... jedoch hat Michael kürzlich auch noch geschrieben, dass der pseudo else-Zweig immer erst im nächsten Zyklus ausgeführt wird. Das fordert Programmierer mit ELO 2500 und mehr

Zusammenfassend würde ich in meiner plakativen Art sagen, dass beide deiner Annahmen für den eibPC unzutreffend sind, was Michael aber sicherlich noch kommentieren sollte.

**Tessi** · 11.02.2011, 10:54

Soviel zur Theorie, und was würde

Code:

if bla then bla = ! bla else blob endif

jetzt tatsächlich machen?

**Tessi** · 11.02.2011, 11:14

Zitat von pio Beitrag anzeigen

Fall 1:

Code:

if bla then bla = ! bla else blob endif

Wenn sich im Zyklus N bla von EIN auf AUS verändert, wird im Zyklus N blob ausgeführt.
Wenn sich im Zyklus N bla von AUS auf ein ändert wird im GLEICHEN Zyklus N then ausgeführt und bla invertiert. Dann wird im NÄCHSTEN Zyklus N+1 einmalig blob ausgeführt, in den folgenden Zyklen passiert nix mehr.

Fall 2:

Code:

if bla then bla = ! bla endif
if !bla then blob endif

Wenn im Zyklus N bla auf EIN wechselt, wird im GLEICHEN Zyklus N then ausgeführt und bla invertiert. Dann wird im GLEICHEN Zyklus N einmalig blob ausgeführt, in den folgenden Zyklen passiert nix mehr.

OK, falls das so ist, besteht der einzige Unterschied nur darin, das im Fall 2 Invertierung und blob im selben Zyklus ausgeführt werden, im Fall 1 die Inversierung in einem und blob im folgenden Zyklus. Unter der Annahme, das die Zykluszeit verglichen mit den Ereignissen in der "Außenwelt" doch recht kurz ist, dürfte der Unterschied in den meisten Fällen gar nicht relevant sein.
Abgesehen davon scheint es eine Menge Situationen zu geben, in denen User hier nicht genau wissen (können), welche Codeteile wann und damit in welcher Reihenfolge ausgeführt werden.
Wenn ich es nicht falsch interpretiere, soll Code für den EPC daher auch so geschrieben werden, das dies letzlich egal ist - wobei ich nicht sicher sagen kann, ob das auch in allen Fällen wirklich möglich ist.

**enertegus** · 11.02.2011, 12:12

Zitat von Tessi Beitrag anzeigen

Soviel zur Theorie, und was würde

Code:

if bla then bla = ! bla else blob endif

jetzt tatsächlich machen?

Wenn sich bla auf EIN ändert, wird es invalid und damit für die Verarbeitung der if-Funktion und des else. Eine Verzögerung findet hier nicht statt, d.h. else wird immer im gleichen Takt abgearbeitet. Nur change() verzögert die Auswertung. Bevor man mir wieder Dummheit im Kontext mit diesem Verhalten vorwirft

, zum Hintergrund: Wäre es anders, d.h. change würde nicht erst im folgenden Verarbeitungszyklus ein Flag setzen, wäre dies
[highlight=epc]
if change(a) then a=!a endif
[/highlight]
eine Endlosschleife pro Verarbeitungszyklus. Da die Verarbeitung im in Echtzeitsthreads abläuft, würde der EibPC quasi nicht mehr ansprechbar sein. Ok, wir haben hierfür nun eine max. Verarbeitungszahl eingebaut (der ominöse Wert 65000 oder max 500000 bei der 1.911), um zumindest nicht den Reset bedienen zu müssen.
Durch das Verhalten von change, wird dies verhindert und es ist m.E. brauchbarer: Der genannte Code nur von einer zur anderen Verarbeitungsschleife aktiv und funktioniert auch intuitiv (ich weiss, dass das nicht jeder hier so sieht aber:"Wenn sich a änderte, zähle es nochmals eins hoch" geht damit auf diese Weise. Und so lese ich die Syntax.
Dass es für einen anderen Ausdruck
[highlight=epc]
if change(a) then b=!a endif
[/highlight]
eine "Verzögerung" um eine Verarbeitungszyklus (ms) ergibt, stört nicht.

Im Fall ohne change, also hier
[highlight=epc]
if a then a=!a else a=!a endif
[/highlight]
wird dies deutlich: a wird invertiert, dann wird der else zweig aktiv, sofort ist aber wieder then aktiv usw., also eine Endlosschleife innerhalb einer Verarbeitungsschleife - ich sehe hier dann

Code:

Event: !a" , Eventtype: PROC_REPETITIONS {2011-02-11 12:03:50})

Zurück zum Beispiel: Da der ELSE-Zweig im gleichen Zyklus aktiv ist, wird blob wird im gleichen Zyklus aktiviert. Daher ist

Code:

if bla then bla = ! bla else blob endif

gleich zu:

Code:

if bla then bla = ! bla endif 
if !bla then blob endif

Vewendet man eval, dann wie bereits oben gesagt;

Code:

if eval(bla) then bla = ! bla else blob endif

dann ist dazu äquivalent

Code:

if eval(bla) then bla = ! bla endif 
if eval(!bla) then blob endif

nicht aber

Code:

if eval(bla) then bla = ! bla endif 
if !eval(bla) then blob endif

**pio** · 11.02.2011, 17:32

Zitat von saft6luck Beitrag anzeigen

.. jedoch hat Michael kürzlich auch noch geschrieben, dass der pseudo else-Zweig immer erst im nächsten Zyklus ausgeführt wird.

wo denn das?

**pio** · 11.02.2011, 17:42

Zitat von enertegus Beitrag anzeigen

Wenn sich bla auf EIN ändert, wird es invalid und damit für die Verarbeitung der if-Funktion und des else. Eine Verzögerung findet hier nicht statt, d.h. else wird immer im gleichen Takt abgearbeitet.

... ah, hier! Also im gleichen Takt!

D.h. bei Änderung von a von AUS auf EIN wird bei diesem Konstrukt

if a then a = !a else blob endif

im gleichen Zyklus zuerst a im Then-Zweig wieder auf AUS gesetzt, und dann auch noch blob im Else-Teil ausgeführt!
Uff .....

**saft6luck** · 11.02.2011, 22:30

Zitat von pio Beitrag anzeigen

wo denn das?

https://knx-user-forum.de/eibpc/1080...tml#post140890, bevor er es heute geändert hat (siehe zitat: https://knx-user-forum.de/eibpc/1080...tml#post141018).

Immerhin ist es jetzt aber wieder klarer.

**saft6luck** · 11.02.2011, 22:53

Zitat von enertegus Beitrag anzeigen

... folgenden Verarbeitungszyklus ein Flag setzen, wäre dies
[highlight=epc]
if change(a) then a=!a endif
[/highlight]
eine Endlosschleife pro Verarbeitungszyklus.

Du sagst also, dass der Ausdruck des if nach der Änderung erneut berechnet würde, wenn nicht change() erst im nächsten Zyklus die Änderung erkennt?

Durch das Verhalten von change, wird dies verhindert und es ist m.E. brauchbarer: Der genannte Code nur von einer zur anderen Verarbeitungsschleife aktiv und funktioniert auch intuitiv (ich weiss, dass das nicht jeder hier so sieht aber:"Wenn sich a änderte, zähle es nochmals eins hoch" geht damit auf diese Weise. Und so lese ich die Syntax.

Erstens fände ich es intuitiv, wenn die Funktion change() macht, was sie vorgibt, nämlich eine Änderung zu erkennen.
Zweitens sollte die Anleitung bzgl. der Leseart des Syntax erweitert werden.

Dass es für einen anderen Ausdruck
[highlight=epc]
if change(a) then b=!a endif
[/highlight]
eine "Verzögerung" um eine Verarbeitungszyklus (ms) ergibt, stört nicht.

Dass das nicht nur eine Verzögerung bedeutet, sondern dass nicht nur darauf folgender Code sondern auch der gesamte darüber stehende Code auch noch ausgeführt wird, ist für dich kein Problem?

Im Fall ohne change, also hier
[highlight=epc]
if a then a=!a else a=!a endif
[/highlight]
wird dies deutlich: a wird invertiert, dann wird der else zweig aktiv, sofort ist aber wieder then aktiv usw., also eine Endlosschleife innerhalb einer Verarbeitungsschleife - ich sehe hier dann

Code:

Event: !a" , Eventtype: PROC_REPETITIONS {2011-02-11 12:03:50})

Zurück zum Beispiel: Da der ELSE-Zweig im gleichen Zyklus aktiv ist, wird blob wird im gleichen Zyklus aktiviert.

D.h. Codezeilen werden innerhalb eines Verarbeitungszyklus mehrfach ausgeführt?
Du fragst doch immer nach Beispielen: Hast du auch ein Beispiel, wo das Sinn macht? Und eines für das else?

**pio** · 12.02.2011, 01:17

Zitat von saft6luck Beitrag anzeigen

..............
Dass das nicht nur eine Verzögerung bedeutet, sondern dass nicht nur darauf folgender Code sondern auch der gesamte darüber stehende Code auch noch ausgeführt wird, ist für dich kein Problem?

Ich weiss, das ist jetzt Krümelka....ei, aber Frage an Enertex:
Gibt es einen Unterschied zwischen

Code:

if a then a=a+1 else blub endif

und

Code:

if a then {
  a=a+1
} else {
  blub
} endif

?????
Sprich, spielt es da eine Rolle in welcher Zeile was steht?

Ankündigung

Frage zum Validierungsschema bei EVAL

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar