PB4 Interpretation bool'scher Ausdrücke

uweb · Beitrag von **uweb** » 15.04.2006 10:12

Ich verstehe das Problem nicht. Vielleicht liegt es ja an der Definition bzw. Nicht-Definition von TRUE.
Nach meinem Verständnis ist Null FALSE und alles andere ist TRUE.

Das erscheint mir schon deshalb logisch weil es in PB keine bool'schen Variablen gibt.

Wozu auch ?
Mein PC arbeitet intern sowieso mit 32 Bit.
Speicher zu sparen indem man bool'sche Variablen in Bits speichert wäre unsinnig, da die interne Umsetzung sehr langsam wäre.

Selbst in den Sprachen in denen es bool'sche Variablen gibt werden die kaum genutzt und statt dessen andere mit ungleich Null abgefragt.
Und, da wo sie genutzt werden sehe ich keinen Vorteil darin.

Aber das Thema lautet ja auch nicht "Sollte es in PB bool'schen Variablen geben ?".

Daß es in PB keine bool'schen Variablen gibt ist eine Tatsache (und kein Fehler).

Mit anderen Worten : Es gibt in PB keinen Variablentyp der nur 2 verschiedene Werte annehmen kann.

Also kann man auch nicht blind darauf vertrauen, daß eine Variable nur einen von zwei möglichen Werten enthält.

Wenn 0 FALSE und nur -1 TRUE sein soll - was ist dann 42 ?

Code: Alles auswählen

Debug #True

Muß ja irgend etwas ausgeben. Und, daß dabei eine Konstante verwendt wird ist naheliegend.
Der Wert der Konstante muß nach meinem Verstandnis aber nicht -1 sein. Jeder Wert ungleich Null ist korrekt.
Das hat nichts mit PB zu tun.

In anderen Sprachen gibt es z.B. auch Funktionen die einen ErrorCode zurück liefern.
Bei Null (Error=FALSE) ging alles glatt. Bei ungleich Null (Error=TRUE)ist ein Fehler aufgetreten. Dabei kann der ErrorCode dann auch verschiedene Werte ungleich Null annehmen.

Es ist sogar weit verbreitet einen nicht-bool'schen Wert als solchen zu gebrauchen.

Anders als in einigen anderen Sprachen ist diese "trickreiche Vermischung" von arithmetischen und Bool'schen Werten in PB aber NICHT überall sinnvoll.

Mit

Code: Alles auswählen

 If Len(String$)

kann man zwar feststellen ob ein String bereits einen Inhalt hat.

Wenn FileSize() tatsächlich immer nur die Dateigröße liefern würde könnte man auch da mit

Code: Alles auswählen

If FileSize(DateiName$)

feststellen ob eine Datei bereits einen Inhalt hat. Der Nachteil wäre dann aber, daß man eben immer nur diese Information bekommt.

Natürlich kann man mit OpenFile() feststellen ob sich eine Datei öffnen lässt.
In PB kann man aber vorher mit FileSize() schon feststellen ob es sie schon gibt (-1: Datei wurde nicht gefunden. -2: Datei ist ein Verzeichnis.).

Diesen Vorteil erkauft man sich durch einen kleinen Nachteil :
Die "trickreiche Vermischung" von arithmetischen und Bool'schen Werten klappt hier nicht, da z.B. -1 (ungleich Null) TRUE ergibt.

Man muß also um festzustellen ob eine Datei bereits einen Inhalt hat

Code: Alles auswählen

If FileSize(DateiName$) > 0

statt

Code: Alles auswählen

If FileSize(DateiName$)

schreiben. Dafür spart man sich aber mindestens ein If.

Mit anderen Worten : It's not a bug, it's a feature!

jear · Beitrag von **jear** » 15.04.2006 10:47

@uweb
Bitte lies doch noch mal die Überschrift.
Es geht nicht um Bool'sche Variable sondern um die korrekte Interpretation Bool'scher Ausdrücke.

Es geht lediglich darum, dass

Code: Alles auswählen

(a > 60)

dann zu #True aufgelöst wird, wenn a größer als 60 ist. Diese geschieht ja schließlich auch bei

Code: Alles auswählen

If (a > 60)...

Nichts anderes wird erwartet und nichts anderes ist richtig.

Die Auflösung des Ausdrucks (a > 60) mit dem Wert 60 und zwar ohne Rücksicht darauf, welchen Wert a tatsächlich hat, das ist schlicht falsch und kann kein "Feature" sein.

So wird PB nie zu einer erwachsenen Programmiersprache sondern bleibt Kinderkram.

Welchen Wert die Konstante #True hat, das ist bei dieser Betrachtung völlig schnuppe.

mk-soft · Beitrag von **mk-soft** » 15.04.2006 11:42

Ich habe mich gestern auch noch einmal damit beschäftigt und bin auch der Meinung das sich da noch was tuen sollte.

@jear, die aussage "So wird PB nie zu einer erwachsenen Programmiersprache sondern bleibt Kinderkram." finde ich übertrieben.
PB hat stärken die andere Sprachen nicht hat.

Habe aber erstmal eine lösung geschrieben für PB4

Code: Alles auswählen

Macro IsTrue(Ext)
  (#False Or(Ext))
EndMacro

Macro IsFalse(Ext)
  (#False Or Not(Ext))
EndMacro

a = 60
Debug IsTrue(a > 65)

b = 10 + IsTrue(a>65) * 20
Debug b

b = 10 + IsFalse(a>65) * 20
Debug b

Kenne ich noch aus PowerBasic

FF

Froggerprogger · Beitrag von **Froggerprogger** » 15.04.2006 11:49

Dass z.B. 4 + (2 > 54) kein gültiger PB-Ausdruck ist, wurde schon mal vor Ewigkeiten durchdiskutiert und als Ergebnis blieb, dass diese Ausdrücke von PB nunmal nicht unterstützt werden.

Das einzige Problem, das PB im Zusammenhang mit booleschen Ausdrücken innerhalb arithmetischer Ausdrücke hat ist, dass der Compiler keine Fehlermeldung schmeisst, obwohl es laut Spezifikation ein ungültiger Ausdruck ist.

uweb · Beitrag von **uweb** » 15.04.2006 11:57

@jear

Entschuldige bitte ich habe nicht nur Deinen Beitrag gelesen und auch nicht nur Dir geantwortet.

=> #True = NOT 0 = alle bits gesetzt = -1

Alles auf sich zu beziehen und trotzig zu reagieren statt zu erkennen wenn jemand einem helfen will kenne ich sonst nur von Kindern.

Ist das Problem wirklich, daß PureBasic nicht erwachsen werden will?

@uweb
Bitte lies doch noch mal die Überschrift.
Es geht nicht um Bool'sche Variable sondern um die korrekte Interpretation Bool'scher Ausdrücke.

Bitte ließ Du doch mal meinen Beitrag.

Aber das Thema lautet ja auch nicht "Sollte es in PB bool'schen Variablen geben ?".

dann wirst Du erkennen das der Hinweis unnötig war.

ohne Rücksicht darauf, welchen Wert a tatsächlich hat

Da gebe ich Dir Recht. Aber davon war bisher noch nicht die Rede.
Wenn Du in Deinem Beispiel für a einen Wert kleiner 60 gewählt hättest wäre es auch so klar gewesen.

mk-soft · Beitrag von **mk-soft** » 15.04.2006 12:09

Ich habe das jetzt mal in PowerBasic ausprobiert und für der ausdruck
"a = 10 + (2<55) * 20" auch zu einen ungültiges Ergebnis ohne Fehlermeldung.

Man sollte jetzt nicht alles Vergleichen, aber daran sieht man das eine Vermischung allgemein nicht Gültig ist.
In diesen fall finde ich sogar gut das Purebasic für True eine "1" liefert. Siehe mein Beispiel oben.

FF

Kaeru Gaman · Beitrag von **Kaeru Gaman** » 15.04.2006 14:10

> daran sieht man das eine Vermischung allgemein nicht Gültig ist.

falsch.
jetzt per zufall eine zweite sprache rausgepickt zu haben,
die so etwas nicht kann, ist keine beweisführung.

im allgemeinen werden boole'sche ausdrücke dementsprechend ausgewertet,
und ihre benutzung ist vielen programmierern vertraut und nützlich.

dass es natürlich bei jeder programmiersprache ne menge leute gibt,
die solche ausdrücke nicht kennen und deshalb auch nicht nutzen,
ist auch klar.

> Nach meinem Verständnis ist Null FALSE und alles andere ist TRUE.
soweit schon ok

> Der Wert der Konstante muß nach meinem Verstandnis aber nicht -1 sein. Jeder Wert ungleich Null ist korrekt.

aber eine konstante kann nun einmal nur einen einzigen wert annehmen.

und der war schon auf dem C64, bevor Billyboy sein Winzigweich gründete, schlicht -1
eben deshalb, weil "NOT 0" nach den regeln für bitweise verknüpfung in jeder variablengröße "-1" liefert

Hyper · Beitrag von **Hyper** » 15.04.2006 15:18

Hallo Gefährten,

ich möchte hier auch meine unmaßgebliche Meinung zum Besten geben.
Ich arbeite gern mit boolschen Variablen und fand es auch sehr gut, wie die Benutzung der Algebra im C64 und auch in QuickBasic funktioniert hat. Man kann damit feine Dinge machen. So hat man oft im Coding umfangreiche IF-Abfragen. Diese kann man auf verschiedene Wege gestalten:

IF-Abfrage - Variante 1

Code: Alles auswählen

IF Eine_LinkedList()\Feld1 > 1 
  IF Eine_LinkedList()\Feld2 > 37
    IF Eine_LinkedList()\Feld3 = "TEXT"
      IF Globales_Flag

	; ....... CODING

      ENDIF
    ENDIF
  ENDIF
ENDIF

IF-Abfrage - Variante 2

Code: Alles auswählen

IF (Eine_LinkedList()\Feld1 > 1) AND (Eine_LinkedList()\Feld2 > 37) AND (Eine_LinkedList()\Feld3 = "TEXT") AND Globales_Flag
    ; ....... CODING
ENDIF

IF-Abfrage - Variante 3

Code: Alles auswählen

; So funktionert es bspw. mit QuickBasic
Test.l = Eine_LinkedList()\Feld1 > 1
Test   = Test AND (Eine_LinkedList()\Feld2 > 37)
Test   = Test AND (Eine_LinkedList()\Feld3 = "TEXT")
Test   = Test AND Globales_Flag

IF Test
...
ENDIF

Welcher Code ist besser lesbar?
------------------------------------------------------
Und:

Code: Alles auswählen

Debug (22 > 15) ; Ergebnis = 1

a = 22
Debug (a > 15)  ; Ergebnis = 15!?

Ergibt für mich überhaupt keinen Sinn. Warum hält man sich hier nicht an Programmiersprachenstandards? #True = -1. Alles andere wirkt unprofessionell.

uweb · Beitrag von **uweb** » 15.04.2006 15:44

In C (10 Jahre älter und weiter verbreitet) bekomme ich eine 1 als Ergebnis.

Code: Alles auswählen

#include <stdio.h>
int main()
{
    int a, b;
    a = 65;
    b = a > 60;
    printf (" b = %d", b);
    scanf("%d", &a);
    return 0;
}

Aber, es gibt gar nichts zu beweisen. Du sagst ja selbst, daß
"Null FALSE und alles andere ist TRUE" ok ist.

Daß -1 TRUE ist habe ich ja auch geschrieben und, daß eine Konstante nur einen Wert annehmen kann wusste ich auch schon.

Wir sind uns auch einig, daß das Beispiel bei einem Wert kleiner 60 für a FALSE liefern müsste.

Wenn wir also so weit einer Meinung sind bleiben nur noch 2 Fragen :

1. ob die Konstante für TRUE -1 sein muß.
2. Ob für TRUE immer die Konstante verwendet werden sollte.

Zu 1. :
Der C64 kann auch keine Beweisführung sein.
Der Ansatz mit dem bitweisen NOT hat etwas für sich, ist aber meiner Meinung nach nicht zwingend, da es nicht um Bit-Operationen geht.

Zu 2. :
Das war das was ich mit

It's not a bug, it's a feature!

oder dem Beispiel mit FileSize() gemeint habe. Wenn es Vorteile hat sollte man meiner Meinung nach einen Rückgabewert oder den Wert eines Ausdrucks ruhig mehrere Bedeutungen haben lassen.
Ob mein Gedanke etwas mit der Situation zu tun hat kann nur Fred beantworten. Wir wissen beide nicht welche Gedanken er sich bei der Entscheidung hier keine Konstante zu verwenden gemacht hat. Ich gehe aber davon aus, daß er einen guten Grund hatte.

Schon auf den Großrechnern war es so, daß bestimmte Situationen als "Ergebnis nicht vorhersehbar" oder gar nicht dokumentiert waren. Das war kein Fehler. Es war aber wohl ein Fehler etwas voraus zu setzen was nicht ausdrücklich definiert war.

AndyX · Beitrag von **AndyX** » 15.04.2006 16:53

ich habe gehört, TRUE kann alles sein außer 0, dann ist FALSE 0. bin mir nicht sicher, nich hauen...