IF-Abfrage

DocShoe

Außerdem ... wäre eine Addition auf der untersten Ebene sehr langsam.

Das ist eine bloße Vermutung, die ich so nicht unterschreiben würde. Compiler optimieren sehr gut und erkennen teilweise schon die Absicht des Programms. Es würde mich nicht wundern, wenn aktuelle Compiler für die XORund Addition sehr ähnlichen Code mit minimalen Laufzeitunterschieden produzieren. Sehr langsam ist das mit Sicherheit nicht.

wob

@DocShoe Genau. Clang 17.0.1 mit -O3 produziert sogar identischen Code!

Siehe https://gcc.godbolt.org/z/P89Gj5Mox

*john 0

Das ist doch eine typische Übungsaufgabe bei dem man mit Hilfe einer Wahrheitstabelle, und Nutzung der disjunktiven bzw. konjunktiven Normalform die entsprechende Logik ausrechen kann bzw. soll. Dazu sollte man die De-morganschen Gesetze kennen.

Die disjunktive Normalform erhält man, in dem man die für jedes wahre Ergebnis die Eingänge „und“ verknüpft, die konjuktive Normalform erhält für jedes „falsche“ Ergebnis die Eingänge oder verknüpft. Die einzelnen Terme werden bei der disjunktiven Normalform „oder“ verknüpft, und für die konjunktive Normalform „und“ verknüpft.

Ich habe das jetzt für die disjunktive Normalform einmal ausgeführt (englische Schreibweise).

A	B	C	D	Ergebnis	Min Term
0	0	0	0	0
0	0	0	1	1	$\bar{\mathrm{A}}\bar{\mathrm{B}}\bar{\mathrm{C}}\mathrm{D}$
0	0	1	0	1	$\bar{\mathrm{A}}\bar{\mathrm{B}}\mathrm{C}\bar{\mathrm{D}}$
0	0	1	1	0
0	1	0	0	1	$\bar{\mathrm{A}}\mathrm{B}\bar{\mathrm{C}}\bar{\mathrm{D}}$
0	1	0	1	0
0	1	1	0	0
0	1	1	1	1	$\bar{\mathrm{A}}\mathrm{B}\mathrm{C}\mathrm{D}$
1	0	0	0	1	$\mathrm{A}\bar{\mathrm{B}}\bar{\mathrm{C}}\bar{\mathrm{D}}$
1	0	0	1	0
1	0	1	0	0
1	0	1	1	1	$\mathrm{A}\bar{\mathrm{B}}\mathrm{C}\mathrm{D}$
1	1	0	0	0
1	1	0	1	1	$\mathrm{A}\mathrm{B}\bar{\mathrm{C}}\mathrm{D}$
1	1	1	0	1	$\mathrm{A}\mathrm{B}\mathrm{C}\bar{\mathrm{D}}$
1	1	1	1	0

Das ergibt dann für die disjunktive Normalform
$X=\bar{\mathrm{A}}\bar{\mathrm{B}}\bar{\mathrm{C}}\mathrm{D}+\bar{\mathrm{A}}\bar{\mathrm{B}}\mathrm{C}\bar{\mathrm{D}}+\bar{\mathrm{A}}\mathrm{B}\bar{\mathrm{C}}\bar{\mathrm{D}}+\bar{\mathrm{A}}\mathrm{B}\mathrm{C}\mathrm{D}+\mathrm{A}\bar{\mathrm{B}}\bar{\mathrm{C}}\bar{\mathrm{D}}+\mathrm{A}\bar{\mathrm{B}}\mathrm{C}\mathrm{D}+\mathrm{A}\mathrm{B}\bar{\mathrm{C}}\mathrm{D}+\mathrm{A}\mathrm{B}\mathrm{C}\bar{\mathrm{D}}$
Das ist nun mit Hilfe der Rechenregeln zu vereinfachen.

Quiche Lorraine

@john-0 sagte in IF-Abfrage:

Das ist nun mit Hilfe der Rechenregeln zu vereinfachen.

@tech-house schrieb:

Es dürfen nur drei Operatoren verwendet werden.

Quiche Lorraine

@john-0
BTW, warum denn eine Wahrheitstabelle nicht fest eincodieren? Ist ja relativ klein.

#include <iostream>

int main()
{
    static constexpr bool Table[2][2][2][2] = { 0, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0 };
    bool a = true;
    bool b = false;
    bool c = true;
    bool d = true;

    std::cout << Table[a][b][c][d] << std::endl;
    return 0;
}

*john 0

@Quiche-Lorraine sagte in IF-Abfrage:

@john-0
BTW, warum denn eine Wahrheitstabelle nicht fest eincodieren? Ist ja relativ klein.

Der Ansatz kommt aus der Digitalelektronik, d.h. man will die Schaltung mit NANDs oder NORs aufbauen bzw. mit VHDL o.ä. in einem FPGA umsetzen, weil man da nur Gatterlaufzeiten hat. Mit denselben Methoden kann man aber auch die Abfragen vereinfachen. Wenn man das nun nicht ausrechnen will, kann man das natürlich mit einer Tabelle umsetzen.

Quiche Lorraine

@john-0 sagte in IF-Abfrage:

Mit denselben Methoden kann man aber auch die Abfragen vereinfachen.

Und ich erinnere mich noch düster an die KV Diagramme

tech-house

Ihr habt alle recht. Ich möchte mir einen kleinen Computer selber basteln, und dafür brauche ich das.

Das XOR war schon ganz schön anstrengend (https://de.wikipedia.org/wiki/Exklusiv-Oder-Gatter#Synthese).

PS. Den KV-Würfel verstehe ich nicht.

*john 0

@Quiche-Lorraine sagte in IF-Abfrage:

Und ich erinnere mich noch düster an die KV Diagramme

Darauf bin ich vorhin als ich das alte Uni-Skript aus dem Regal holte auch gestoßen. Die disjunktive Normalform war mir noch im Gedächtnis, die KV-Diagramme nicht mehr.

Finnegan

@john-0 sagte in IF-Abfrage:

$X=\bar{\mathrm{A}}\bar{\mathrm{B}}\bar{\mathrm{C}}\mathrm{D}+\bar{\mathrm{A}}\bar{\mathrm{B}}\mathrm{C}\bar{\mathrm{D}}+\bar{\mathrm{A}}\mathrm{B}\bar{\mathrm{C}}\bar{\mathrm{D}}+\bar{\mathrm{A}}\mathrm{B}\mathrm{C}\mathrm{D}+\mathrm{A}\bar{\mathrm{B}}\bar{\mathrm{C}}\bar{\mathrm{D}}+\mathrm{A}\bar{\mathrm{B}}\mathrm{C}\mathrm{D}+\mathrm{A}\mathrm{B}\bar{\mathrm{C}}\mathrm{D}+\mathrm{A}\mathrm{B}\mathrm{C}\bar{\mathrm{D}}$

Danke, dass du die Notation verwendet hast, ich finde die immer extrem gut lesbar. Die ist irgendwie bei den Elektrotechnikern beliebt, aber die Mathematiker wollten damals nix davon wissen und haben auf dieses unsägliche $\land$ / $\lor$ -Hütchenspiel bestanden, bei dem man Flimmern vor den Augen bekommt (ich zumindest).... aber ich kann das schon verstehen - man muss schliesslich mit beidem klar kommen. Ich war aber bei viele Zeilen langen Ausdrücken nie so schnell und hab so wenig Fehler gemacht, wie mit dieser Digitaltechnik-Notation

Edit: Dein Audruck da oben könnte auch so aussehen, wenn ich mich nicht vertippt hab (grusel!):

$X=\lnot A \land \lnot B \land \lnot C \land D \lor \lnot A \land \lnot B \land C \land \lnot D \lor \lnot A \land B \land \lnot C \land \lnot D \lor \lnot A \land B \land C \land D$
$\lor A \land \lnot B \land \lnot C \land \lnot D \lor A \land \lnot B \land C \land D \lor A \land B \land \lnot C \land D \lor A \land B \land C \land \lnot D$

tech-house

@Finnegan sagte in IF-Abfrage:

Dein Audruck da oben könnte auch so aussehen, wenn ich mich nicht vertippt hab (grusel!)

Eii, das Forum/der Browser scheint damit Darstellungsprobleme zu haben.^^

Edit: Man darf aber auch Klammern setzen, falls es sonst zu unübersichtlich wird ...

Finnegan

@tech-house sagte in IF-Abfrage:

@Finnegan sagte in IF-Abfrage:

Dein Audruck da oben könnte auch so aussehen, wenn ich mich nicht vertippt hab (grusel!)

Eii, das Forum/der Browser scheint damit Darstellungsprobleme zu haben.^^

Ja, ich habs grad noch auf 2 Zeilen aufgesplittet, der Latex-Renderer scheint einfach abzuschneiden, wenns zu lang wird (zumindest mit $latex$). Bei mir siehts jetzt richtig aus ... und es ist schon ein Zeichen für eine bessere Notation, wenn man es auch ohne die eigentlich nicht notwendigen Klammern gut lesen kann.

tech-house

@Finnegan sagte in IF-Abfrage:

Bei mir siehts jetzt richtig aus

Bei mir auch. Noch mal BTT.: Ich muss sagen, dass mir die E-Techniker-Schreibweise (also das hoch- bzw. übergestellte - für Not und das seltsame + für Oder und das implizite Und, welches gar nicht mehr auftaucht) "tendenziell eher etwas weniger gut" gefällt.

Finnegan

@tech-house sagte in IF-Abfrage:

@Finnegan sagte in IF-Abfrage:

Bei mir siehts jetzt richtig aus

Bei mir auch. Noch mal BTT.: Ich muss sagen, dass mir die E-Techniker-Schreibweise (also das hoch- bzw. übergestellte - für Not und das seltsame + für Oder und das implizite Und, welches gar nicht mehr auftaucht) "tendenziell eher etwas weniger gut" gefällt.

Man macht sich halt u.a. auch die algebraische Analogie zwischen $\land$ / $\lor$ und $\cdot/+$ zunutze. Letzteres lernt man bereits sehr früh und hat es dementsprechend gut drauf, so dass mans meist intuitiv richtig macht. Gerade auch was Umstellen und Vereinfachen von Ausdrücken angeht.

*john 0

@Finnegan sagte in IF-Abfrage:

Ja, ich habs grad noch auf 2 Zeilen aufgesplittet, der Latex-Renderer scheint einfach abzuschneiden, wenns zu lang wird (zumindest mit $latex$). Bei mir siehts jetzt richtig aus ... und es ist schon ein Zeichen für eine bessere Notation, wenn man es auch ohne die eigentlich nicht notwendigen Klammern gut lesen kann.

Was mich stört, dass der LaTeX Renderer nicht die übliche align bzw. alignat Umgebung bietet. Mit dieser lassen sich längere Formeln besser umbrechen.

hustbaer

@tech-house sagte in IF-Abfrage:

Ich dachte, das logische XOR wäre in C++ !=, und das ^ gäbe es gar nicht...

Es gibt in C++ kein logisches XOR.

^ ist "bitwise" XOR.
Und != ist "ungleich".

So lange man aber ausschliesslich mit bool Inputs arbeitet, und das Ergebnis dann als bool interpretiert, bekommt man mit beiden das selbe raus.

tech-house

Aber das ist für bools dann doch äquivalent zu einem logischen XOR! Demnach gibt es dies.

Finnegan

@tech-house sagte in IF-Abfrage:

Aber das ist für bools dann doch äquivalent zu einem logischen XOR! Demnach gibt es dies.

~~Ne, != ist nur die halbe Miete. Für XOR muss auch noch einer der beiden Ausdrücke wahr sein ... also sowas wie (A != B) && (A || B)~~

Edit: Äh, Moment mal. Stimmt, die können ja nur ungleich sein, wenn einer wahr und einer falsch ist. Ich glaube du hast doch recht, oder verpeil ich hier auch was? != ist tatsächlich wie ein logisches XOR ... hatt ich auch nicht auf dem Schirm, klingt erstmal so falsch

So mal ganz doof:

A | B | !=
----------
0 | 0 | 0
0 | 1 | 1
1 | 0 | 1
1 | 1 | 0

A | B | XOR
------------
0 | 0 | 0
0 | 1 | 1
1 | 0 | 1
1 | 1 | 0

... aber es stimmt schon, man nennt es eben nicht "logisches XOR" und es macht auch etwas mehr, da es eben im Vergleich zu || und && nicht nur bool-Inputs akzeptiert, bzw. die Operanden nicht implizit nach bool konvertiert. Aber das ist im Prinzip das, was @hustbaer ja auch geschrieben hat.

tech-house

Nein, mir ging es um Folgendes:

^ ist das arithmetische XOR in C/C++ ...
^ ist für bools aber nicht definiert => Kompilierfehler.
Deshalb nimmt man für bool types den !=-Operator.
Der !=-Operator verhält sich für bool types logisch äquivalent zum logischen XOR.
Deshalb wäre es für mich naheliegend, bei bool types und dem !=-Operator auch vom logischen XOR zu sprechen.
Dass der !=-Operator für andere types auch "noch mehr kann" als eine reine XOR-Verknüpfung, und er so gesehen sozusagen überladen wäre, spielt in erster Linie doch keine Rolle.
Auf unterster Ebene liegt für zwei bool-Werte ein XOR vor (siehe Analyse von @wob) ...
Daher würde ich "!= ist "ungleich"" und "ein logisches XOR gibt es in C/C++ nicht" widersprechen, da ungenau ... eher würde ich sagen, != ist "vielgestaltig" in C/C++.

Selbstverständlich ist das etwas Korinthenkacka, aber ich bin an der Stelle lieber etwas genauer als "zu ungenau falsch". Das ist doch hoffentlich verständlich?

hustbaer

@tech-house
^ ist arithmetische XOR, soweit richtig.
Es ist auch richtig dass es für bool nicht definiert ist. Genaugenommen ist es für keinen Typ definiert der formal kleiner als int ist. Genau so wie +, - etc.

Das bedeutet aber nicht dass du einen Kompilierfehler bekommst. Es bedeutet dass "integral promotions" auf beiden Seiten gemacht werden. Konkret wird dabei jeder Typ der formal kleiner als int ist zu int oder unsigned int konvertiert. Siehe https://en.cppreference.com/w/cpp/language/implicit_conversion#Integral_promotion

D.h. bei folgendem Code:

    bool b1;
    bool b2;
    auto x = b1 ^ b2;

Macht der Compiler das daraus:

  bool b1;
  bool b2;
  int x = static_cast<int>(b1) ^ static_cast<int>(b2);

Siehe https://cppinsights.io

Deshalb wäre es für mich naheliegend, bei bool types und dem !=-Operator auch vom logischen XOR zu sprechen.

Die Operatoren die in C++ als logische Operatoren bezeichnet werden konvertieren ihre Argumente zwingend nach bool. Daher ergibt 1 && 2 als Ergebnis true - wohingegen 1 & 2 als Ergebnis 0 hat -- was dann zu false wird wenn man es nach bool konvertiert.

Und != verhält sich hier wie &, nicht wie &&. Denn 1 != 2 ist true, wohingegen 1 LOGICAL_XOR 2 als Ergebnis false haben müsste. Daher wäre es sehr irreführend es als "logisches XOR" zu bezeichnen.

Daher würde ich "!= ist "ungleich"" und "ein logisches XOR gibt es in C/C++ nicht" widersprechen, da ungenau ... eher würde ich sagen, != ist "vielgestaltig" in C/C++.
Selbstverständlich ist das etwas Korinthenkacka, aber ich bin an der Stelle lieber etwas genauer als "zu ungenau falsch". Das ist doch hoffentlich verständlich?

Nein. Du bist zu ungenau. Der eingebaute != Operator ist immer "ungleich" und der eingebaute ^ Operator ist immer bitweise XOR. Und logisch XOR gibt es nicht. Das ist genau.