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

All times are UTC + 1 hour




Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 4:22 am 
Offline
User
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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 5:52 am 
Offline
Addict
Addict
User avatar

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

_________________
Image


Top
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 10:19 am 
Offline
Addict
Addict

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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 11:36 am 
Offline
Enthusiast
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 :D


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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 11:49 am 
Offline
Enthusiast
Enthusiast
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 11:52 am 
Offline
Addict
Addict

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". :oops: Stupid me.


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

Top
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 12:02 pm 
Offline
Enthusiast
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)

Please debug my mind!

Cheers


Top
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 3:56 pm 
Offline
Enthusiast
Enthusiast

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

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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 5:51 pm 
Offline
User
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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 6:36 pm 
Offline
Enthusiast
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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 6:43 pm 
Offline
Addict
Addict
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Thu Jun 09, 2016 10:15 pm 
Offline
Addict
Addict

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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Fri Jun 10, 2016 12:07 am 
Offline
Enthusiast
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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Fri Jun 10, 2016 4:39 am 
Offline
Addict
Addict
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: Faulty And/Or Processing
PostPosted: Fri Jun 10, 2016 10:51 am 
Offline
Enthusiast
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 :)

PS found this answer here
http://programmers.stackexchange.com/qu ... arentheses


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 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 forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron

 


Powered by phpBB © 2008 phpBB Group
subSilver+ theme by Canver Software, sponsor Sanal Modifiye