Boolean Logic Confusion

[Beege]

So when it comes to boolean logic the biggest mistake (IMO) that I've been seening be made in autoit is people thinking numbers 0 and 1 are the same as boolean values True and False. A very easy assumption to make (guilty myself), but it is extreamly wrong. Autoit only has two boolean values, True and False. 0 and 1 are NUMBERS that cannot be treated as a boolean. We can check if that number is logically equal to True or False, but not use those numbers to see if other datatypes are logically True/False. The main reason you cannot do this is because when you compare a string to a number, Autoit will do its best to make those datatypes the same, most likly turning the string into a number. Despite how this can end up causeing confusion, it is a very good and smart thing that happens, as long as you realize whats happening.

Below are the list of what I call "Rules" that are all described in the help file, that determine how the comparison is going to be treated, and 3 examples of where the logical outcome could possibly return True or False for the same variable, and most importatly, the rule to back up why that will happen.

RULES for Numbers, Strings, and Boolean comparison

• Boolean Number Rule: Any number value that is not 0 is evaluated as TRUE.
• Boolean String Rule: Any string that is not blank is evaluated as TRUE.
• Comparison String-Number Rule: If a string is a number, AND it is used WITH or COMPARED to a number, a implicit call to Number() function will be made on the string. If the string doesn't contain a valid number, it will be assumed to equal to 0.

Example 1 - Strings as Numbers

;$sBool is assigned the STRING value of 0.
Local $sBool = '0'
 
;Comparison String-Number Rule 1: If a string is a number, AND it is used WITH or COMPARED to
;a number, a implicit call to Number() function will be made on the string.
;So because $sBool is assigned the number 0 AND it is compared to the number 0, $sBool will evaluate as equal to false.
If $sBool = 0 then ConsoleWrite('sBool = False' & @LF)
 
;Boolean String Rule: Any string that is not blank is evaluated as TRUE.
;Here since we are Comparing it to a Bool, NOT a number, $sBool remains as the string value 0. Since it
;is not blank, $sBool will evaluate as TRUE.
If $sBool = True Then ConsoleWrite('sBool = True' & @LF)

Example 2 - Strings that are not numbers

Local $sString = 'somestring'
 
;Comparison String-Number Rule: if a string doesn't contain a valid number, and it is used
;WITH or COMPARED to a number, it will be assumed to equal to 0.
;Because of this rule, $sString will be evaluated as FALSE
If $sString = 0 Then ConsoleWrite('sString = False' & @LF)
 
;String Boolean Rule: Any string that is not blank is evaluated as TRUE.
If $sString = True Then ConsoleWrite('sString = True' & @LF)

Example 3 - Writing values to files

;Any autoit write fuction,(filewrite, iniwrite, consolewrite) will write boolean values
;TRUE/FALSE  OR  Numbers 0/1 as actual strings "True"/"False", "0" /"1". When the value
;is read back it is now a string value of "True"/"False", "0"/"1". So as an example of possible
;confused outcome could be:
 
;User writes ini key Bool as the NUMBER value 0
IniWrite(@TempDir & '\BoolTest.ini', 'confusing', 'Bool', 0)
 
;When ini key Bool is read back in, it is now a STRING value of "0"
$Bool = IniRead(@TempDir & '\BoolTest.ini', 'confusing', 'Bool', 0)
 
;Boolean String Rule: Any string that is not blank is evaluated as TRUE.
;As a result you now have the opposite value you were expecting.
If $Bool = True Then ConsoleWrite('Bool = True' & @LF)
 
;But if the user compares to a number, everything works out fine becasue of Comparison String-Number Rule 1:
;If a string is a number, AND it is used WITH or COMPARED to a number, a implicit
;call to Number() function will be made on the string.
If $Bool = 0 Then ConsoleWrite('Bool = False' & @LF)

Edited October 2, 2011 by Beege

[Spiff59]

people thinking numbers 0 and 1 are the same as boolean values True and False... is extreamly wrong.

It's useful to discuss the often-confusing results of comparing a string data type to a numeric data type, but your statement by itself is too broad. In the vast majority of cases, considering 0 equals false and 1 equals true is proper thinking.

Edit: Here's some odd, undocumented, AutoIt-specific behavior that's boolean-related:

If "" = False Then Beep(800,100)
Sleep(100)
If "" == False Then Beep(800,100)

Edited October 1, 2011 by Spiff59

[Beege]

It's useful to discuss the often-confusing results of comparing a string data type to a numeric data type, but your statement by itself is too broad. In the vast majority of cases, considering 0 equals false and 1 equals true is proper thinking.

Edit: Here's some odd, undocumented, AutoIt-specific behavior that's boolean-related:

If "" = False Then Beep(800,100)
Sleep(100)
If "" == False Then Beep(800,100)

Is the == a legal operator? Setting it to true or false fails to beep. There are some things I was thinking about rewording, But if your saying that I came off as trying to imply 0 doesnt equal false, and 1 dosent equal true, then yes I definatly need to elaborate cause that is not what im trying to say cause your %100 correct about 0 always equals false and 1 always equals true. Im trying to point out how $var = 0 and $var = false are not the same and can give different results depending on what $var is.

Edited October 1, 2011 by Beege

[Unsigned]

Is the == a legal operator? Setting it to true or false fails to beep.

These both correctly evaluate to false:

If "" == False Then ...
If "" == True Then ...

The "==" operator converts both operands to strings. False converts to the string "False", and True converts to "True". Neither is equal to a blank string.

Edited October 1, 2011 by Unsigned

[AdmiralAlkex]

Edit: Here's some odd, undocumented, AutoIt-specific behavior that's boolean-related:

If "" = False Then Beep(800,100)
Sleep(100)
If "" == False Then Beep(800,100)

Well first and third line is explained by the helpfile, so I guess that means you think "Sleep(100)" is odd and undocumented. Not all facets of it is explained by the helpfile, but I don't agree with those specific words.

[MvGulik]

Is the == a legal operator?

Damn ... Writing that first message, but not knowing about '==' in AutoIt ... ... Better dig up that Manual that's included with AutoIt. Edited October 3, 2011 by iEvKI3gv9Wrkd41u

[twitchyliquid64]

the double equal operator is a comparison for strings. normal use with the = operator yields case insensitive results. use of == is case sensitive.

this stuff is all in the helpfile. its very useful for making interpreters.

[Beege]

Damn ... Writing that first message, but not knowing about '==' in AutoIt ... ... Better dig up that Manual that's included with AutoIt.

Im sure Ive seen it before, its just one of those "if you dont use it, you lose it."

[Mat]

You know, in C there isn't actually a boolean type.

AutoIt lets you compare variables of different types, but that doesn't mean you should. It's not doing code readability any good. As a result, I find it perfectly ok to regard 0 and 1 as true and false.

And for your last rule, it's covered by the third.

[Beege]

I find it perfectly ok to regard 0 and 1 as true and false.

I dont know how you can say that. Comparing a variable to 0 and comparing a varialbe to false can give different results. If they were the same, you would always give the exact same results. But you dont and this is all I'm was trying to demonstrate.

And for your last rule, it's covered by the third.

Ya it kinda of is. I originally had 1 and 2 togther. Since someone has commented about it, ill change it back.

[Mat]

I dont know how you can say that. Comparing a variable to 0 and comparing a varialbe to false can give different results. If they were the same, you would always give the exact same results. But you dont and this is all I'm was trying to demonstrate.

Eh,,, Did you read my whole post? I said that comparing variables of different data types is bad practice.

I would never compare a variable to a boolean anyway, instead I would use Not to check if it's false, and wouldn't compare to anything to check if it's true. As a result I never need to consider your rules.

[Beege]

comparing variables of different data types is bad practice.

Ok cool. We are one the same page then. I guess I just need to go back and rephrase my words better because thats all I'm tyring demonstrate here. 0 and 1 and the Autoit keywords TRUE/FALSE are two different datatypes. One is a bool and one is a Int.

I would never compare a variable to a boolean anyway, instead I would use Not to check if it's false, and wouldn't compare to anything to check if it's true.

Thats just your style of coding and dont get me wrong, its mine too. But 'If Not $far ..' and 'If $far = False' are the exact same thing.

Please realize this write up is not for experienced users like you, more for newish users. There are people that do there bool logic checks using an '='. Why they do it i really don't know. Maybe it helps them read there code better, or maybe they came from some other language that dosnt allow "if $var". Either way, if they are dead set on using the '=', then always use keywords true/false if your just doing a logic check because if you treat 0 and 1 as if they are the same thing could get you into trouble.

Edited October 3, 2011 by Beege

[Mat]

I understand what you are trying to acheive here, but I would try and show that there are good reasons for knowing about datatypes and being aware of what AutoIt is doing rather than looking at this specific case. Otherwise you run the risk of creating more voodoo along the line of "goto is BAD" etc.

[Spiff59]

Well first and third line is explained by the helpfile

Hah! I'd put in a request for a doc change over a year ago, and hadn't realized that any had been made!

It's not exactly the verbage I'd suggested, but it does effectively indicate that case-sensitivity is not the only difference between the = and == operators.

[AdmiralAlkex]

I don't know what you mean.

I'm out.

[Spiff59]

I don't know what you mean.

The helpfile, until fairly recently, only said this about the = and == operators:

= Tests if two values are equal (case insensitive if used with strings).

== Tests if two values are equal (case sensitive if used with strings)

It gave no indication of another important difference between the operators; that one operator (=) would treat 0 as equal to a null string, and the other (==) would cause the same comparison to fail. It now states that string conversions are forced for the == operator. So somewhere in release 3.3.6.0 or 3.3.6.1, my wish came true and the documentation was expanded.

[AdmiralAlkex]

The helpfile, until fairly recently, only said this about the = and == operators:

It gave no indication of another important difference between the operators; that one operator (=) would treat 0 as equal to a null string, and the other (==) would cause the same comparison to fail. It now states that string conversions are forced for the == operator. So somewhere in release 3.3.6.0 or 3.3.6.1, my wish came true and the documentation was expanded.

Now I understand what you mean

[Beege]

I understand what you are trying to acheive here, but I would try and show that there are good reasons for knowing about datatypes and being aware of what AutoIt is doing rather than looking at this specific case. Otherwise you run the risk of creating more voodoo along the line of "goto is BAD" etc.

I completely agree with you here and wanted to put a final "Solution to all this" that covered just that because the solution is not to always use "If $var" or "if $var = true". The real solution is to know about the datatypes, and what autoit it going to do with them. How would you put it all into words?

[Mat]

I completely agree with you here and wanted to put a final "Solution to all this" that covered just that because the solution is not to always use "If $var" or "if $var = true". The real solution is to know about the datatypes, and what autoit it going to do with them. How would you put it all into words?

I can do it in four letters: RTFM. Unfortunately no one seems to learn from tutorials like that

Maybe a tutorial for advice on conditionals should be added to here. It's a good list already that covers most of AutoIt.

[Beege]

I can do it in four letters: RTFM. Unfortunately no one seems to learn from tutorials like that

I hear you on that! Sometimes I think theres a growing cult for noobs: IRTRTFM.

Maybe a tutorial for advice on conditionals should be added to here. It's a good list already that covers most of AutoIt.

Yes that would work. Mainly when writing this I just wanted a place I could point people when I either see misuse of conditionals or there asking questions like "why does this always return 0?"