[PB511] AND OR expression, wrong result

[luis]

x86 and x64

Code: Select all

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 -> http://www.purebasic.fr/english/viewtop ... =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 ?


EDIT: another nice thread about this -> https://www.purebasic.fr/english/viewto ... =4&t=65911

[skywalk]

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

Code: Select all

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

[luis]

And just parentheses around f2 changes the result

No comment.

[idle]

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: Select all

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]

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: Select all

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]

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

[Jacobite]

This works ok:

Code: Select all

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: Select all

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]

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]

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: Select all

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]

Here's the equivalent code in Python:

Code: Select all

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]

Hi Jacobite

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:

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]

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...

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]

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]

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]

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