Seite 2 von 4
Verfasst: 10.12.2004 14:17
von Kaeru Gaman
oh yeah, i think 'he's on it'
(sorry konnt ich mir echt nicht verkneifen, steinigt mich)
Verfasst: 10.12.2004 14:28
von Danilo
freedimension hat geschrieben:Bin zum selben Ergebnis gekommen und plädiere für Bug.
PB bricht ab, sobald die ganze Bedingung nicht mehr wahr
sein kann.
Bei "if 0 and 0 or 1 and 1" wird logischweise nach dem ersten
"0 and 0" abgebrochen, da schon nicht erfüllt.
Warum sollte PB auch weitermachen, wenn die 1. Bedingung
schon nicht erfüllt wurde? Damit ist die ganze Aussage nicht
erfüllt.
Mit den Klammern funktioniert es korrekt, da somit zuerst
die Klammern gecheckt werden, wegen den Vorrangregeln.
So wie Spider es schon sagte:
"habe ich gelernt, dass bei gleichwertigen Rechenoperatoren strikt von
links nach rechts ausgewertet wird."
Also Klammern verwenden, der Rest ist logisch aufgebaut...
von links nach rechts.
Verfasst: 10.12.2004 15:21
von Kaeru Gaman
thnx für den tip
also wie in C: abbruch bei erstem FALSE...
Verfasst: 10.12.2004 15:54
von Torakas
Kaeru Gaman hat geschrieben:also wie in C: abbruch bei erstem FALSE...
also ich habe doch noch nicht in C gehabt. Vielleicht weil ich die Klammern richtig gesetzt hab
Aber ich bin auch der meinung das es ein Bug ist.. immerhin sollte auch kontrolliert werden ob vielleicht der rest der bedingung auch falsch ist und nicht einfach beim ersten FALSE aussteigen...
Verfasst: 10.12.2004 15:58
von freedimension
Danilo hat geschrieben:
PB bricht ab, sobald die ganze Bedingung nicht mehr wahr
sein kann.
Bei "if 0 and 0 or 1 and 1" wird logischweise nach dem ersten
"0 and 0" abgebrochen, da schon nicht erfüllt.
Warum sollte PB auch weitermachen, wenn die 1. Bedingung
schon nicht erfüllt wurde? Damit ist die ganze Aussage nicht
erfüllt.
Alles schön und gut, nur kommt da halt noch dieses
or nach
0 and 0.
Auswertung müsste sein:
false and false = false
-> false or true = true
-> true and true = true
Also so hab ich das zumindest mal gelernt
Verfasst: 10.12.2004 16:09
von Kaeru Gaman
@freedimension
is scho recht, aber wenn es so ist, wie danilo sagt,
dann ist es lediglich C-Konvention, darauf wird in C-Tutorials explizit hingewiesen.
das hat in C den hintergrund, da man in abfragen auch zuweisungen
einbauen kann, die nur ausgefürt werden, wenn der erste teil TRUE ist,
aber keinen einfluss auf die abfrage haben, da sie selbst immer TRUE sind.
(weil sie aufgrund des == in C nicht mit nem Boolean verwechselt werden können)
in PB kann man das natürlich als BUG erachten...
und nochmal wiederholt: sollte es tatsächlich "OR vor AND" heissen,
dann ist es korrekt.
Verfasst: 10.12.2004 16:15
von freedimension
is scho recht, aber wenn es so ist, wie danilo sagt, dann ist es lediglich C-Konvention, darauf wird in C-Tutorials explizit hingewiesen.
das hat in C den hintergrund, da man in abfragen auch zuweisungen
einbauen kann, die nur ausgefürt werden, wenn der erste teil TRUE ist,
aber keinen einfluss auf die abfrage haben, da sie selbst immer TRUE sind.
(weil sie aufgrund des == in C nicht mit nem Boolean verwechselt werden können)
in PB kann man das natürlich als BUG erachten...
Also, ein klein wenig C kann ich auch noch, und dass würde auch so klappen wenn da ein AND stünde, mit einem OR allerdings bin ich da noch sehr skeptisch
Hab's mal in php probiert (ist ja sehr stark an C angelehnt) und hier kommt ganz korrekt 1 heraus.
Code: Alles auswählen
<?php
echo 0 && 0 || 1 && 1;
echo 0 and 0 or 1 and 1;
?>
EDIT:
Code: Alles auswählen
<?
function test($txt)
{
echo $txt;
}
if(0 or test('or'))
echo;
if(0 and test('and'))
echo;
?>
Ausgabe hier wie erwartet: or
Verfasst: 10.12.2004 17:19
von Danilo
Kaeru Gaman hat geschrieben:und nochmal wiederholt: sollte es tatsächlich "OR vor AND" heissen,
dann ist es korrekt.
Das steht aber in PB nirgendwo. In der Referenz gibt es
keine Vorrangregeln dafür.
So wie PB das auswertet sind 'Or' und 'And' gleich, ist also
dafür korrekt. Durch das erste (von links nach rechts)
"0 and 0" ist die ganze Bedingung nicht wahr und es wird
abgebrochen.
Wäre es "Or hat Priorität vor And", dann wäre es ein Bug.
Nur steht diese Priorität nirgendwo, und solange gibt es die
nicht offiziell.
Ich kann freedimension schon verstehen, nur geht er von
Vorrangregeln aus, die nirgendwo stehen. Bis dahin gilt dann
IMHO das alte "von links nach rechts".
Ist ja ein allgemeines PB-Problem, das es keine komplette
und eindeutige Sprachspezifikation gibt (d.h. nur die Syntax
der Sprache "PureBasic", ohne irgendwelche Libs), in der
alles komplett drin steht.
Verfasst: 10.12.2004 17:35
von freedimension
Danilo hat geschrieben:
Das steht aber in PB nirgendwo. In der Referenz gibt es
keine Vorrangregeln dafür.
So wie PB das auswertet sind 'Or' und 'And' gleich, ist also
dafür korrekt. Durch das erste (von links nach rechts)
"0 and 0" ist die ganze Bedingung nicht wahr und es wird
abgebrochen.
Wäre es "Or hat Priorität vor And", dann wäre es ein Bug.
Nur steht diese Priorität nirgendwo, und solange gibt es die
nicht offiziell.
Ich kann freedimension schon verstehen, nur geht er von
Vorrangregeln aus, die nirgendwo stehen. Bis dahin gilt dann
IMHO das alte "von links nach rechts".
Ist ja ein allgemeines PB-Problem, das es keine komplette
und eindeutige Sprachspezifikation gibt (d.h. nur die Syntax
der Sprache "PureBasic", ohne irgendwelche Libs), in der
alles komplett drin steht.
Manchmal kann überzeugen echt schwer sein
1.) jede Programmiersprache hat Vorrangregeln, ob sie aufgeschrieben sind oder nicht
2.) Ich gehe von Links nach Rechts aus, so wie du auch, nicht von OR vor AND
3.) Alleine das Vorhandensein des ORs müsste dafür sorgen dass der Ausdruck weiter ausgewertet wird denn mit diesem OR steht und fällt alles
Nochmal aufgeschlüsselt wie das ganze (Links nach Rechts) ausgewertet werden sollte.
(((0 and 0) or 1) and 1)
((0 or 1) and 1)
(1 and 1)
1
Einzige Möglichkeit daraus Falsch zu machen wäre das auswerten von Rechts nach Links
(0 and (0 or (1 and 1)))
(0 and (0 or 1))
(0 and 1)
0
Das wäre dann aber wirklich dass Schlimmste was man beim Design einer Computersprache überhaupt machen kann
Verfasst: 10.12.2004 17:49
von Kaeru Gaman
in OPAL hat der compiler bei so einer construktion ne fehlermeldung gebracht
"more than 2 infixes"
da war man gezwungen, klammern zu schreiben.
...die lösung mochte ich aber nicht wirklich...