# PureBasic Forum

 It is currently Thu Sep 19, 2019 5:29 am

 All times are UTC + 1 hour

 Page 1 of 2 [ 27 posts ] Go to page 1, 2  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 4:22 am
 User

Joined: Thu Aug 28, 2014 9:02 pm
Posts: 62
Try this. The SRC\$ value will cause the first argument to be FALSE. The REF\$ value
will cause the second argument to be TRUE. In Boolean "OR" logic, the result
should be TRUE. but in this case, it is wrongly FALSE and execution falls through
to the "Not supposed to happen" display. Enclosing the first argument in parenthesis
fixes the problem: (SRC\$ <> "F" And SRC\$ <> "K" And SRC\$ <> "R").

Code:
SRC\$ = "F": REF\$ = "1"

If SRC\$ <> "F" And SRC\$ <> "K" And SRC\$ <> "R" Or REF\$ = "1": Goto SKIPSOMETHING: EndIf
MessageRequester("TEST", "Not supposed to happen")
SKIPSOMETHING:
MessageRequester("TEST", "Completed")
End

Something similar to this was reported in 2009.

[url]
viewtopic.php?f=4&t=37904
[/url]

After all this time, it's concerning that it hasn't been fixed.

Using 5.42 LTS x64.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 5:52 am

Joined: Mon Jul 25, 2005 3:51 pm
Posts: 3573
Location: Utah, USA
It is good to simply examples if possible.

The buggy result only needs three conditions to happen:
Code:
SRC\$ = "F": REF\$ = "1"

If SRC\$ <> "F" And SRC\$ <> "R" Or REF\$ = "1": Goto SKIPSOMETHING: EndIf
MessageRequester("TEST", "Not supposed to happen")
SKIPSOMETHING:
MessageRequester("TEST", "Completed")
End

_________________

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 10:19 am

Joined: Thu Aug 30, 2007 11:54 pm
Posts: 1040
Location: right here
the operators have the same precedence, so the order is undefined, or at best left to right, including short circuit evaluation.
use braces.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 11:36 am
 Enthusiast

Joined: Mon Feb 04, 2013 5:28 pm
Posts: 332
#NULL wrote:
the operators have the same precedence, so the order is undefined, or at best left to right, including short circuit evaluation.

They have the same precedence (it's documented) and everyday PB use strongly suggests they are evaluated from left-to-right, including the use of short circuit evaluation. Don't know if the latter is documented. I hope it is, it's something which should be documented for a programming language, maybe I just didn't find it. Can you help me here ?

In any case giving every benefit of doubt and supposing the evaluation order is not left to right on monday and friday, or it is for some expressions but not others, and using the simplified example from demivec:

Code:
SRC\$ = "F": REF\$ = "1"
If SRC\$ <> "F" And SRC\$ <> "R" Or REF\$ = "1": Goto SKIPSOMETHING: EndIf
Debug "not supposed to happen"
SKIPSOMETHING:
Debug "completed"
End

The above prints "not supposed to happen"
False and True or True.

The equivalent

Code:
If #False And #True Or #True: Goto SKIPSOMETHING: EndIf
Debug "not supposed to happen"
SKIPSOMETHING:
Debug "completed"
End

... prints "completed"

Clearly something is completely out of control here.

Yeah "use braces" it's a good suggestion, we all agree to that. The point of the OP here is documenting a bug in the hope to get it fixed.
The workaround, instructing the compiler through an excessive use of () to do what we want even when it should do it without any help, it's well understood.

btw: if someone is thinking (see below) the fact those two expressions (one using variables and one using constants) giving two different result is absolutely normal must hurry up and have his head examined

about short circuit evaluation (see below): first of all works only for some operators and certainly does not stop the evaluation of an expression at the first "true" result, but only if and when the outcome of a boolean expression can be unequivocally determined at the point currently under examination, so the explanation in the manual I don't know what it is. And certainly does not result in skipping code just because something along the expression is true

short-circuiting and evaluation order are required for operators || and && in both C and C++ ANSI standards

Code:
#include <stdio.h>

int main(void) {
// SRC\$ = "F": REF\$ = "1"
int a = 'F', b = '1';

// If SRC\$ <> "F" And SRC\$ <> "R" Or REF\$ = "1": Goto SKIPSOMETHING: EndIf
if (a != 'F' && a != 'R' || b == '1') goto SKIP;

puts("wrong");
SKIP:
puts("exit");

return 0;
}

result is "exit"

GW-BASIC, 1983

Code:
10 SRC\$ = "F" : REF\$ = "1"
20 IF SRC\$ <> "F" AND SRC\$ <> "R" OR REF\$ = "1" THEN GOTO 40:ENDIF
30 PRINT "WRONG"
40 REM
50 PRINT "EXIT"

result is "EXIT"

VIC20, 1981

Code:
10 SRC\$ = "F" : REF\$ = "1"
20 IF SRC\$ <> "F" AND SRC\$ <> "R" OR REF\$ = "1" THEN GOTO 40:ENDIF
30 PRINT "WRONG"
40 REM
50 PRINT "EXIT"

result is "EXIT"

APPLESOFT BASIC, 1977

Code:
10 SRC\$ = "F" : REF\$ = "1"
20 IF SRC\$ <> "F" AND SRC\$ <> "R" OR REF\$ = "1" GOTO 40: ENDIF
30 PRINT "WRONG"
40 REM
50 PRINT "EXIT"

result is "EXIT"

Last edited by DontTalkToMe on Thu Jun 09, 2016 6:26 pm, edited 5 times in total.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 11:49 am
 Enthusiast

Joined: Fri Jun 26, 2009 3:51 pm
Posts: 215
Location: Westernmost tip of Norway
Quote:
The equivalent
is not really so when it comes to the details...

Purebasic are in the first code-case where you use variables evaluating these as the code executes, while in the second case with all constant the compiler is optimizing these away & the 'if' turns into nothing or a jump/skip.

_________________
The best preparation for tomorrow is doing your best today.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 11:52 am

Joined: Mon Feb 16, 2015 2:49 pm
Posts: 1896
Deleted, because I misread the example. I kept thinking it started with If SRC\$ = "F" instead of If SRC\$ <> "F". Stupid me.

Last edited by Dude on Fri Jun 10, 2016 1:29 pm, edited 1 time in total.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 12:02 pm
 Enthusiast

Joined: Fri Jun 01, 2012 12:20 am
Posts: 140
I think I have a bug in my mind logic too.

If someone say to me:

Code:
If you're a javaprogrammer and newyorker or righthanded you win a beer!

I realy don't know if I have the beer.

All righthanded persons will win a beer? (javaprogrammer and newyorker) or (righthanded)

Only righthanded javaprogrammers and righthanded newyorkers will win a beer?
(javaprogrammer) and (newyorker or righthanded)

Cheers

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 3:56 pm
 Enthusiast

Joined: Mon Feb 04, 2013 5:28 pm
Posts: 332
edit: removed bashing of Dude

leaving the short circuit evaluation part

SCE works for AND and OR expression.

An expression can be short-circuited if you have an AND expression, and the left part of that expression is false. Because then the whole (a and b) can be only false.
An expression can be short-circuited if you have an OR expression, and the left part of that expression is true. Because then the whole (a or b) can be only true.

The subexpression composed by three AND on the left, may have any result, and you can short-circuit the whole expression at that point if those three AND result in TRUE because they are on the left side of an OR.
If they don't result in TRUE (they don't) you have to evaluate the OR and you can't skip it because if that's one is TRUE the whole expression is TRUE (anything OR true = true).
And in the specific case, it is.

In fact, the PB code using constants instead of variable gives the right result. And mind you, PB is still giving TWO DIFFERENT results for the same expression (one using variables, one using constants).

Even the C code (see my post above, which implement SCE), gives the right result.

Even the old GWBASIC for DOS gives the right result.

And even POWERBASIC, as ANDY told us, gives the right result.

Last edited by DontTalkToMe on Fri Jun 10, 2016 4:47 pm, edited 1 time in total.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 5:51 pm
 User

Joined: Thu Aug 28, 2014 9:02 pm
Posts: 62
This is from the PureBasic Help text:

Logical OR. Can be used to combine the logical true and false results of the
comparison operators to give a result shown in the following table.

LHS | RHS | Result
-----------------------
false | false | false
false | true | true <======
true | false | true
true | true | true

@DontTalkToMe

Thanks for your defense. You are correct in saying that PowerBasic, C and other
languages that use SCE, evaluate this correctly with out the use of parenthesis.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 6:36 pm
 Enthusiast

Joined: Mon Jul 09, 2007 4:47 pm
Posts: 214
Location: Courthouse
These have been around and reported for a LONG time. Go back to very early versions and try them - buggy then too.
viewtopic.php?f=4&t=54135

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 6:43 pm

Joined: Tue Dec 23, 2003 3:54 am
Posts: 1650
It's why I always use explicit parentheses in PB...

Code:
True  = #True
False = #False

If #True And #True Or #False
Debug "1. Correct"
Else
Debug "1. Incorrect"
EndIf

If (#True And #True) Or #False
Debug "2. Correct"
Else
Debug "2. Incorrect"
EndIf

If #True And (#True Or #False)
Debug "3. Correct"
Else
Debug "3. Incorrect"
EndIf

If True And True Or False
Debug "4. Correct"
Else
Debug "4. Incorrect"
EndIf

If (True And True) Or False
Debug "5. Correct"
Else
Debug "5. Incorrect"
EndIf

If True And (True Or False)
Debug "6. Correct"
Else
Debug "6. Incorrect"
EndIf

If True And #True Or #False
Debug "7. Correct"
Else
Debug "7. Incorrect"
EndIf

If #True And True Or #False
Debug "8. Correct"
Else
Debug "8. Incorrect"
EndIf

If #True And #True Or False
Debug "9. Correct"
Else
Debug "9. Incorrect"
EndIf

_________________
On GitHub: PB Includes - IDE Tools - Color Themes

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Thu Jun 09, 2016 10:15 pm

Joined: Thu Aug 30, 2007 11:54 pm
Posts: 1040
Location: right here
i just read this on stackoverflow:
Quote:
In C++ there is an extra trap: short-circuiting does NOT apply to types that overload operators || and &&

i don't know if it's true, and thats not C, but to mention this is not worse than comparing PureBasic to some BASIC of the 80th.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Fri Jun 10, 2016 12:07 am
 Enthusiast

Joined: Mon Feb 04, 2013 5:28 pm
Posts: 332
@#NULL

It's true, it makes the two operators greedy and so the second part of the expression is always evaluated.
Think at the bitwise & and the boolean AND.
The first is greedy, the second is lazy, and for the second you can avoid evaluating the right side of the expression if the left one is false, because (false and anything) is always false.
The bitwise one always evaluate the right part.

#NULL wrote:
but to mention this is not worse than comparing PureBasic to some BASIC of the 80th.

I've mentioned some BASIC from the '80 to show how boolean expressions like these are working this way for quite some time.
C is from 1972 and it's often compared to PB with good reason (up to a point).

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Fri Jun 10, 2016 4:39 am

Joined: Thu Jun 04, 2015 7:10 am
Posts: 1673
its always been a habit of mine to uses brackets even where not needed, such as A = A + (B * C)
is this considered bad practice in those cases? or does it not really matter? I use them simply because for me and my brain or lack thereof it visually makes things clearer - i find equations too ambiguous when relying purely on the BIMDAS/precedence kinda thing, and prefer to be slapped in the face with the obvious. It seems to have kept me out of the problems being mentioned in this thread at least? am i causing any problems this way?

_________________
Thankyou to all the coders who generously helped & encouraged me in the nearly 2yrs when i was welcome here,
it was a tremendous privilege. I learned a lot. I wish you and your families all the best and success for the future.

Top

 Post subject: Re: Faulty And/Or ProcessingPosted: Fri Jun 10, 2016 10:51 am
 Enthusiast

Joined: Mon Feb 04, 2013 5:28 pm
Posts: 332
@Keya

IMO if you like it and helps you to better follow your code when you look at it go for it.
I don't think it's that important, I often do the same for clarity myself. Certainly I wouldn't call it a bad practice unless you bring it to some excess.
It can be useless for the compiler (if the compiler work as it should) but it has no detrimental effects and if brought to excess can make people think "why he's putting all that useless parenthesis here ?" but nothing more. If you can live with that...
The only detrimental effect absolutely irrelevant it's the code requires more time in absolute terms to be compiled because add some workload to the parser tree.
As long as you don't tell me it's ok for a compiler to be bugged and generate wrong code when what I wrote is perfectly valid just because you are using parenthesis everywhere and so you don't care, we can be friends

http://programmers.stackexchange.com/qu ... arentheses

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 2 [ 27 posts ] Go to page 1, 2  Next

 All times are UTC + 1 hour

#### Who is online

Users browsing this forum: No registered users and 2 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forum

Search for:
 Jump to:  Select a forum ------------------ PureBasic    Coding Questions    Game Programming    3D Programming    Assembly Programming    The PureBasic Editor    The PureBasic Form Designer    General Discussion    Feature Requests and Wishlists    Tricks 'n' Tips Bug Reports    Bugs - Windows    Bugs - Linux    Bugs - Mac OSX    Bugs - Documentation OS Specific    AmigaOS    Linux    Windows    Mac OSX Miscellaneous    Announcement    Off Topic Showcase    Applications - Feedback and Discussion    PureFORM & JaPBe    TailBite