[PB511] AND OR expression, wrong result

luis · **Posted:** Sat Mar 30, 2013 12:32 am

x86 and x64

Code:

EnableExplicit

Define f1 = #False
Define t1 = #True
Define f2 = #False
Define t2 = #True

; AND and OR have the same priority, so they are evaluated from left to right

If #False And #True Or #False And #True ; FALSE
    Debug "T"
Else
    Debug "F" ; OK
EndIf

If f1 And t1 Or f2 And t2 ; again the same
    Debug "T"
Else
    Debug "F" ; OK
EndIf

If ((f1 And t1) Or f2) And t2 ; equivalent to the above
    Debug "T"
Else
    Debug "F" ; OK
EndIf

If (f1 And t1) Or f2 And t2 ; this too should be equivalent
    Debug "T" ; WHAT THE HELL ? 
Else
    Debug "F"
EndIf

The last expression it's perfectly valid and equivalent to all the previous ones but gives the wrong result indicating that there is something wrong with the way the compiler process simple boolean expressions.

EDIT: I just found this was actually already reported by Trond in ... 2009 -> viewtopic.php?f=4&t=37904

2 0 0 9

Come on, how a compiler can fail on some boolean expression and left alone with a bug like this ?

skywalk · **Posted:** Sat Mar 30, 2013 12:41 am

Hmm, this happens enough that I force parentheses for all complex logic.
And just parentheses around f2 changes the result :shock:

Code:

If (f1 And t1) Or (f2) And t2 ; this too should be equivalent 
    Debug "T"
Else
    Debug "F" ; Back to correct answer !
EndIf

luis · **Posted:** Sat Mar 30, 2013 9:11 pm

skywalk wrote:

And just parentheses around f2 changes the result :shock:

No comment.

idle · **Posted:** Sun Mar 31, 2013 12:03 am

Think this has been the case since I started using PB and is a side effect of short circuit evaluation
if you use parenthesis to change the order of evaluation, you need to ensure that you've specified the order for the whole statement.
otherwise it can result in malformed expressions.

Code:

Procedure False()
   Debug "false called"
   ProcedureReturn 0
EndProcedure 
Procedure True()
   Debug "True Called"
   ProcedureReturn 1
EndProcedure    

If (False() And True()) Or (false() And True()) 
   Debug "T"
Else 
   Debug "F"
EndIf    

luis · **Posted:** Sun Mar 31, 2013 12:20 am

You wrote a different expression: (expression) OR (expression)

Both sub-expression have two boolean values ANDed.

So if the first part of the sub-expression is FALSE it's ok to short circuit that.

You can only end up with a #False OR #False. And that's ok.

The result is correct. (F).

My problematic expression is different: (expression) OR expression AND expression

In this case the first sub-expression is False, the False is ORed with a second False and the result of that is ANDed with True.

For the same reasons which makes your expression work, this one ( a False ORed with a False followed by an AND) could be short circuited at the view of the AND, with the correct result (F).

Code:

Procedure False()
   Debug "false called"
   ProcedureReturn 0
EndProcedure
Procedure True()
   Debug "True Called"
   ProcedureReturn 1
EndProcedure   

; If (False() And True()) Or (false() And True())
;    Debug "T"
; Else
;    Debug "F"
; EndIf   

If (False() And True()) Or False() And True()
  Debug "T"
Else
  Debug "F"
EndIf   

Not T.

I don't see how this cannot be considered a bug. The expression is valid, the result is wrong, even considering short circuit evaluation.

skywalk · **Posted:** Sun Mar 31, 2013 12:27 am

It is definitely a bug, but there is a (workaround) and a (strong suggestion) to always (use) it since the bug might reappear. :idea:

Jacobite · **Joined:** Fri Nov 30, 2012 7:21 pm **Posts:** 16

This works ok:

Code:

If (0 And 1) Or 0 And 1
    Debug "T"
Else
    Debug "F"
EndIf

And this correctly gives "F", if you write (False()) And (True())

Code:

Procedure False()
   Debug "false called"
   ProcedureReturn 0
EndProcedure
Procedure True()
   Debug "True Called"
   ProcedureReturn 1
EndProcedure   

; If (False() And True()) Or (false() And True())
;    Debug "T"
; Else
;    Debug "F"
; EndIf   

If (False() And True()) Or (False()) And (True()) 
  Debug "T"
Else
  Debug "F"
EndIf   

I think there should be something in the manual about this, because it's certainly quirky behaviour.

Little John · **Posted:** Mon Apr 08, 2013 6:02 pm

Jacobite wrote:

I think there should be something in the manual about this, because it's certainly quirky behaviour.

Both of your above code snippets work as expected. What additional documentation do you want for it?

Jacobite · **Joined:** Fri Nov 30, 2012 7:21 pm **Posts:** 16

Hi Little John,

The 2nd code snippet only works as expected when the 3rd and 4th calls to the procedures are bracketed. The following does NOT give the expected "F", but why shouldn't it? :

Code:

Procedure False()
   Debug "false called"
   ProcedureReturn 0
EndProcedure
Procedure True()
   Debug "True Called"
   ProcedureReturn 1
EndProcedure   

If (False() And True()) Or False() And True()
  Debug "T"
Else
  Debug "F"
EndIf  

The standard result of (F & T) v F & T should be F. By merely changing the 3rd and 4th calls from False(), True() to (False()), (True()) you get a different result. Don't you find that odd?

Jacobite · **Joined:** Fri Nov 30, 2012 7:21 pm **Posts:** 16

Here's the equivalent code in Python:

Code:

def false():
   return 0

def true():
   return 1

if (false() and true()) or false() and true():
   print("T")
else:
   print("F")

It prints "F" as expected. Same with javascript and C, but not PB.

In PB, it's as though bracketing the calls - changing True() to (True()) and False() to (False()) - enables an explicit reduction to 1 and 0 in a way that simply using True() and False() doesn't.

Little John · **Posted:** Mon Apr 08, 2013 10:40 pm

Hi Jacobite

Jacobite wrote:

Don't you find that odd?

My previous post was a reply to your previous post. And both code snippets that you showed in that post work as expected. That's why I replied as I did reply.

Now you show different code. I can confirm the result of this code, and yes: I find this result odd.

However:

Jacobite wrote:

I think there should be something in the manual about this, because it's certainly quirky behaviour.

This is a bug in the compiler which has to be fixed, it's not a problem of the documentation.

Jacobite · **Joined:** Fri Nov 30, 2012 7:21 pm **Posts:** 16

Right. Sorry about the confusion. Idle says in his above post that PB has behaved this way from the beginning. TBH I find it rather alarming that a such a fundamental error in the compiler has been left unfixed for so long, although I suppose in practice it would be fairly rare for it show up (otherwise, it would have been fixed before now). But still... :shock:

So I take it that the workaround is to explicitly bracket ALL logical operands, whether they're compound or not?

BTW, I'm using the Linux version of PB, so this bug isn't restricted to Windows, as you'd expect from the nature of it.

idle · **Posted:** Tue Apr 09, 2013 6:40 am

Jacobite, In case you're wondering why your first example worked , it was due to the compiler doing constant folding
so your if statement essentially became a JMP _Else: no evaluation was performed.

Jacobite · **Joined:** Fri Nov 30, 2012 7:21 pm **Posts:** 16

Ok, thanks Idle. So it seems that in the case where evaluation IS performed, we need to fool the compiler into doing constant folding.

idle · **Posted:** Tue Apr 09, 2013 7:32 am

No, if you don't use brackets you just need to ensure that your logic conforms to short circuit evaluation
if you do use brackets, you need to use them for the whole statement, at least until the issue gets fixed

PureBasic Forum

[PB511] AND OR expression, wrong result

Who is online