Verschachtelte IFs ohne Redundanz möglich?

[Christian M. (Gast)]

Eigentlich ein allgemeines Programmierproblem. Habe gerade folgenden 
Code:

If analog_richtung Then
  If analog_pwm Then
    Low IN1
  Else
    High IN1
  Endif
Else
  If analog_pwm Then
    Low IN2
  Else
    High IN2
  Endif
Endif

Wie man sieht, unterscheiden sich die beiden Zweige minimal. Kann man 
das verschönern und die Redundanz rausnehmen? Da es sich hier um 
konkreten Mikrocontroller-Code (Oshonsoft Basic für PIC16) handelt wäre 
noch die Frage, was für eine Variante kleiner, schneller oder schöner 
ist.

Hier soll er schnell sein, weil in der INT.

Dieses Beispiel ist jetzt einfach, vielleicht zu einfach um es zu 
vereinfachen, zeigt aber die Problematik auf. Ich hatte schon 
(Windows-)Programme geschrieben, die hatten riesen Redundanz im Code 
wegen paar Kleinigkeiten.

Man kann das Problem sogar noch erweitern auf z.B. Datenblätter. Die 
habe ich einmal in einem Ordner mit allen DBs, aber auch im Ordner eines 
Projekts. OK, beim heutigen Speicherplatz kein Problem, ist aber nicht 
schön. Und Photos, wo mache ich die rein? In den Projektordner oder zu 
den Photos? Sind Hardlinks die Lösung?

Gruss Chregu

[A. S. (Gast)]

Switch Case, wenn Du die 2 unabhängigen binären zustande zu einem 
zusammenfassen kannst.

Ansonsten je nach Komplexität der Körper auch Funktionen, Datenarrays 
etc.

[... (Gast)]

Die ist doch nur code-redundanz, aber in jedem Ausführungspfad sind 
genau nur so viele IFs wie nötig. Egal, wie irgendein IF ausgeht, es 
sind zum Schluss nur 2 Sprünge die gemacht werden. Die Schönheit des 
Codes hat hier nichts mit der Geschwindigkeit zu tun.

[Zoidberg (Gast)]

If analog_richtung Then
 pin = IN1
Else
 pin = IN2
Endif


If analog_pwm
 Low pin
Else
 High pin
Endif


Finde ich gut lesbar. Ich persönlich würde pin wahrscheinlich immer 
vorhalten und nur umschalten wenn von ein Richtungswechsel passiert.

[Peter D. (peda)]

Eleganter ist es, beide Bedingungen EXOR zu verknüpfen. Das erspart dann 
das 2-malige Hinschreiben und Lesen.
Schneller ist es aber nicht.

[Klaus R. (klara)]

Zoidberg schrieb:
> Finde ich gut lesbar.

Man sollte den Source immer möglichst gut lesbar gestalten, so daß man 
ihn auch noch nach zwei oder drei Jahren wieder schnell und sicher 
versteht.
mfg Klaus

[A. S. (Gast)]

Peter D. schrieb:
> Eleganter ist es, beide Bedingungen EXOR zu verknüpfen. Das erspart dann
> das 2-malige Hinschreiben und Lesen.
> Schneller ist es aber nicht.

Der TO hat ja genau keine Redundanz: Er hat 2 "Pins" (IN1, IN2) und je 2 
Zustände. Also genau 4 Aktionen, getriggert durch 2*2 Eingangszustände.

[Christian M. (Gast)]

A. S. schrieb:
> Der TO hat ja genau keine Redundanz

Ja hast schon Recht. Sehen wir es so an: In der zweiten Ebene sind beide 
Male die genau gleichen Abfragen, sie wären austauschbar mit den 
Aeusseren. Es ist zweidimensional! Eine Tabelle.

+---------+--------------+--------------+
¦         ¦ richtung = 1 ¦ richtung = 0 ¦
+---------+--------------+--------------+
¦ pwm = 1 ¦ Low IN1      ¦ High IN1     ¦
+---------+--------------+--------------+
¦ pwm = 0 ¦ Low IN2      ¦ High IN2     ¦
+---------+--------------+--------------+

Man könnte auch die Y-Achse als äussere Abfrage nehmen. Die Tabelle kann 
viel grösser sein, oder sogar mehr als zwei Dimensionen haben. Ich meine 
nur dass sich die inneren Abfragen immer wiederholen!

Gruss Chregu

[Peter D. (peda)]

A. S. schrieb:
> Der TO hat ja genau keine Redundanz:

Stimmt, es sind 4 Fälle.
Damit man nicht eine Bedingung mehrfach hinschreiben muß, kann man beide 
in eine Variable kombinieren und per switch/case auswerten.
In C würde das so aussehen:

  uint8_t i = !!analog_richtung;
  if (analog_pwm)
    i |= 2;
  switch (i){
    case 0: High_IN2(); break;
    case 1: High_IN1(); break;
    case 2: Low_IN2(); break;
    case 3: Low_IN1(); break;
  }

[MaWin (Gast)]

Peter D. schrieb:
> In C würde das so aussehen:

Echt super als Anfang für den Obfuscated C Contest.

[Zoidberg (Gast)]

Die Eingangsgrößen als bits in einem Decoder-Wort zu sehen ist doch gar 
nicht so schlecht als Idee.
Lesbarer finde ich (zumindest bei den zwei Werten) aber immer noch 
meinen obigen Vorschlag.

uint8_t decode = analog_richtung + 2*analog_pwm; //ggf. + 4* analog_gimmick; 

  switch (i){
    case 0: High_IN2(); break;
    case 1: High_IN1(); break;
    case 2: Low_IN2(); break;
    case 3: Low_IN1(); break;
    //(...)
  }

Muss nur sichergestellt werden, dass decode korrekt zusammengebaut wird, 
also der Wertebereich der Eingangsgrößen immer 0/1 ist. (Oder halt 
anders schieben)
Und man kann die Logiktabelle noch in den Code kommentieren.

[Christian M. (Gast)]

Zoidberg schrieb:
> switch (i){

Du meinst

switch (decode){

Oder ich fände noch praktisch:

uint8_t decode = analog_richtung + %00000010*analog_pwm; //ggf. + %00000100* analog_gimmick; 

  switch (decode){
    case %00000000: High_IN2(); break;
    case %00000001: High_IN1(); break;
    case %00000010: Low_IN2(); break;
    case %00000011: Low_IN1(); break;
    //(...)
  }

Gruss Chregu

[Sven K. (quotschmacher)]

Zoidberg schrieb:
> also der Wertebereich der Eingangsgrößen immer 0/1 ist

dafür ist ja die doppelte negierung da

Peter D. schrieb:
> uint8_t i = !!analog_richtung;

[Eric B. (beric)]

Zoidberg schrieb:
> uint8_t decode = analog_richtung + 2*analog_pwm; //ggf. + 4*
> analog_gimmick;
>
>   switch (i){
>     case 0: High_IN2(); break;
>     case 1: High_IN1(); break;
>     case 2: Low_IN2(); break;
>     case 3: Low_IN1(); break;
>     //(...)
>   }

Dann vielleicht sogar

#define DIR_HI  0x00
#define DIR_LO  0x02
#define PWM_2   0x00
#define PWM_1   0x01

switch(analog_richtung | (analog_pwm << 1)) {
  case DIR_HI | PWM_2: High_IN2(); break;
  case DIR_HI | PWM_1: High_IN1(); break;
  case DIR_LO | PWM_2: Low_IN2(); break;
  case DIR_LO | PWM_1: Low_IN1(); break;
}

EDITH sagt: aber am besten mag ich immer noch den Origonal-Code vom TO!

[Wilhelm M. (wimalopaan)]

Christian M. schrieb:
> Wie man sieht, unterscheiden sich die beiden Zweige minimal. Kann man
> das verschönern und die Redundanz rausnehmen?

Immer wenn man strukturell identischen Code hat (Redundanz), ist das ein 
Indiz, dass man diese Redundanz durch generischen Code herausnehmen 
kann.

In einer Sprache, die das generische Paradigma unterstützt, wie etwa 
C++, könnte man folgendes formulieren:

#include <iostream>
#include <type_traits>

// das folgende wäre im echten Leben eine Pin-Klasse, die eh schon da ist.
template<bool B> using ActiveHigh = std::integral_constant<bool, B>;

template<typename ActiveHigh> 
struct In {
    inline static void activate(bool b) {
        if (b ^ ActiveHigh::value) {
            // whatever todo for high()            
        }    
        else {
            // whatever todo for low()
        }
    }
};

// der tatsächlich benötigte Code

using In1 = In<ActiveHigh<true>>;
using In2 = In<ActiveHigh<false>>;

int main() {
    bool analogRichtung{};
    bool analogPwm{};
 
    if (analogRichtung) {
        In1::activate(analogPwm);
    }
    else {
        In2::activate(analogPwm);
    }
}

[Sven K. (quotschmacher)]

Wilhelm M. schrieb:
> könnte man folgendes formulieren:

wenn man das zusammenfasst sind es aber noch immer die zwei 
if-statements vom anfang. nur anders geschrieben.

[Wilhelm M. (wimalopaan)]

Sven K. schrieb:
> wenn man das zusammenfasst sind es aber noch immer die zwei
> if-statements vom anfang. nur anders geschrieben.

Tja, 4 Alternativen.

[Zoidberg (Gast)]

>dafür ist ja die doppelte negierung da


Ja, schon klar, allerdings hat der Poster einen Basic Dialekt und MaWin 
regte eine offensichtlichere Schreibweise an.