Unexpected behavior of = equals operator conditionals

[mwhidden]

AutoIt documentation of operations states, for the '=' operator,

= Tests if two values are equal.  e.g. If $var= 5 Then    (true if $var equals 5). Case insensitive when used with strings.

 

However, I have found that when the value to compare to is 0, all string values compare as equal to 0.

For example,

If("Foo" = 0) Then MsgBox(1, "Result", "Apparently, Foo = 0")

Also true for >= and <=

This behavior does not occur with the '==' operator.

Local $a="Foo", $b=0, $res=""
If("Foo" = 0) Then $res&="Apparently Foo = 0"&@CRLF
If ($a = $b) Then $res&="Apparently "&$a&" = "&$b&@CRLF
If ($a == $b) Then $res&="Apparently "&$a&" == "&$b&@CRLF
If ($a <= $b) Then $res&="Apparently "&$a&" <= "&$b&@CRLF
If ($a >= $b) Then $res&="Apparently "&$a&" >= "&$b&@CRLF
If ($a < $b) Then $res&="Apparently "&$a&" < "&$b&@CRLF
If ($a > $b) Then $res&="Apparently "&$a&" > "&$b&@CRLF
$b=1
If ($a = $b) Then $res&="Apparently "&$a&" = "&$b&@CRLF
If ($a == $b) Then $res&="Apparently "&$a&" == "&$b&@CRLF
MsgBox(1, "Results", $res)

[DW1]

This is expected behavior.  Which of your examples do you think is behaving in an unexpected way?

[water]

According to the help file:

"If a string is used as a number, an implicit call to Number() function is done. So if it doesn't contain a valid number, it will be assumed to equal 0."

[jdelaney]

ConsoleWrite(Number("test") & @CRLF)
ConsoleWrite(IsBool("test") & @CRLF)
if "test" Then
    ConsoleWrite("should not display" & @CRLF)
Else
    ConsoleWrite("should display" & @CRLF)
EndIf





 output:

0

0

should not display

the bool operator acts differently then?

[Melba23]

jdelaney,

AutoIt treats empty strings as Boolean False and with any content as True. So what you get there seems entirely logical to me:

IsNum -> It is not so 0
IsBool -> It is not so 0
If "test" -> It is not "" and so is taken as True

M23

[mwhidden]

According to the help file:

"If a string is used as a number, an implicit call to Number() function is done. So if it doesn't contain a valid number, it will be assumed to equal 0."

 

I see. So the documentation for '==' is clear that the values are converted to strings, but the documentation of '=' does not make it clear that the values are converted to numbers. So I agree that if the documentation is updated, then this is expected behavior.

[water]

"If a string is used as a boolean and it is  an empty string "" , it will be assumed to equal False (see below).  For example,

    NOT "" equals the Boolean true."

[mwhidden]

I see. So the documentation for '==' is clear that the values are converted to strings, but the documentation of '=' does not make it clear that the values are converted to numbers. So I agree that if the documentation is updated, then this is expected behavior.

 

Actually, I'm going to retract that, since the documentation for '=' says that it compares string in a case-insensitive manner, so it seems to matter whether only one value is a string (string is converted to number) or both are strings (strings remain strings).

[jdelaney]

Ah, I forget that, once every 6 months or so.

[Melba23]

mwhidden,
 

the documentation of '=' does not make it clear that the values are converted to numbers

That is because it is not the case.

You can compare 2 strings with the "=" operator and they both remain strings, but are not compared case-sensitively (if such a word exists):

If "Test" = "test" Then
    ConsoleWrite("True" & @CRLF)
Else
    ConsoleWrite("False" & @CRLF)
EndIf

M23

[mwhidden]

mwhidden,

 

That is because it is not the case.

You can compare 2 strings with the "=" operator and they both remain strings, but are not compared case-sensitively (if such a word exists):

If "Test" = "test" Then
    ConsoleWrite("True" & @CRLF)
Else
    ConsoleWrite("False" & @CRLF)
EndIf

M23

 

I'm responding to user "water" who stated that in my example, the string were being implicitly converted to numbers. Are you saying that user water is incorrect in his explanation of why "Foo" = 0 is true but "Foo" == 0 is false?

I'm still unclear as to whether and when '=' and '==' converts a string to a number. It seems that '=' does, at least sometimes.

[water]

If one part of a comparison using "=" is a number then the other part is implicitely converted to a number.

[mwhidden]

If one part of a comparison using "=" is a number then the other part is implicitely converted to a number.

 

If that's true, I'm having trouble finding where that is documented. I can't find (I might just be missing it) information on type coercion, or perhaps the documentation could make that more clear. It is true that "Foo" = 0 and that  NOT "Foo" == 0. The latter is clear from the documentation, but the former is not clear (not to me) until it bites you.

[Melba23]

mwhidden,

If you compare 2 like data-types then things are pretty simple - except that using "==" forces both sides to strings regardless of their type, so you might get an unexpected result which is why we do not recommend using that operator except for case-sensitive string comparison. If you mix the data-types that you can get into all sorts of trouble when "=" does not return what you think it should. So the top tip is not to mix data-types in a comparison.

In the OP you were comparing a string ("Foo") to a number (0) - AutoIt will then convert both to a number (I do not have access to the code but experience tells me this is usually the case). As I stated above - do not mix data-types in comparisons - then you control how the comparison actually compares.  This "bug" raises its head from time to time - it is one of the down-sides of having a non-typed language, but personally I feel that it worth it. All clear now?

M23

[BrewManNH]

If that's true, I'm having trouble finding where that is documented. I can't find (I might just be missing it) information on type coercion, or perhaps the documentation could make that more clear. It is true that "Foo" = 0 and that  NOT "Foo" == 0. The latter is clear from the documentation, but the former is not clear (not to me) until it bites you.

Help file Language Reference=>Datatypes

[mwhidden]

mwhidden,

If you compare 2 like data-types then things are pretty simple - except that using "==" forces both sides to strings regardless of their type, so you might get an unexpected result which is why we do not recommend using that operator except for case-sensitive string comparison. If you mix the data-types that you can get into all sorts of trouble when "=" does not return what you think it should. So the top tip is not to mix data-types in a comparison.

In the OP you were comparing a string ("Foo") to a number (0) - AutoIt will then convert both to a number (I do not have access to the code but experience tells me this is usually the case). As I stated above - do not mix data-types in comparisons - then you control how the comparison actually compares.  This "bug" raises its head from time to time - it is one of the down-sides of having a non-typed language, but personally I feel that it worth it. All clear now?

M23

 

 I was confused because in an earlier post you stated that '=' does not convert values to numbers, but I guess you meant that it does not convert both to numbers, but sometimes converts only one to a number.

But, now that I know that '=' (and also <, >, <=, >=) coerces strings to numbers in mixed-type situations ( vs. the other way around), I can be wary in the future. Is this the proper forum to request an update to the documentation?

[Melba23]

mwhidden,

 

in an earlier post you stated that '=' does not convert values to numbers

No, I said that your assertion "that the values are converted to numbers" was not true. And it is not true in all cases, as I explained.

If you want to suggest a change to the documentation - then provide some suitable wording to replace/add to what is already there and post in this thread. Whether guinness accepts it is, of course, another matter.

M23

P.S. When you reply, please use the "Reply to this topic" button at the top of the thread or the "Reply to this topic" editor at the bottom rather than the "Quote" button - I know what I wrote and it just pads the thread unneccessarily.

[mwhidden]

Help file Language Reference=>Datatypes

 

Thank you, but sorry it is not there. It says that Strings are coerced to numbers (using Number()) when strings are used, but there is no rule for when strings are treated as numbers.

Common sense indicates that mathematical operators like +,-, etc., would treat operands as numbers, and the exampls in teh documentation imply this is so. However, there is nothing that speaks to the comparison operations, except in the case of ==.

Empirical evidience suggests that comparison operators (except for == and <>) treat operands as numbers if at least one operand is a number. Otherwise, they treats the operands as strings.

[water]

There is a >thread where you can report help file changes. But before posting, check that the issue hasn't already been sobved.

Edit: Too late.

Edited June 17, 2013 by water

[mwhidden]

Thank you everyone, especially Melba23 and water, for your help.