Equality of Numbers and Strings

[ssubirias3]

Please hang tight while I give some background on my question and possibly flawed logic.

Most of us remember the Transitive Property of Equality, right? Where A=B and B=C then A=C. And yes, this logic cannot be used in all situations like sporting events (Team1 beats Team2, Team2 beats Team3, so Team1 will undoubtedly beat Team3). But this property works pretty much in math and science (1g = 1ml, 1ml = 1cm3, 1g = 1cm3).

While working on a section of code to compare entered dates (m/d(d) or mm/dd format) against floating date ranges, I ran into a snag. The script wouldn't produce the expected/desired results. Using the Date/Time macros in the past hasn't presented any problem when performing calculations... that is until this script, hence this post. After troubleshooting the script's mathematical/logical operations I learned the following:

Despite the Help file stating the au3 Date/Time macros (@MON, @YEAR, @MDAY, etc) returned "digits" the return values are actually "string" characters. (Digit: In mathematics and computer science, a digit is a symbol ... used ... to represent ... integers or real numbers ...)

ConsoleWrite("@MON = " & @MON & "   ...   @MON is a Number: " & IsNumber(@MON) & @CR)
ConsoleWrite("@MON = " & @MON & "   ...   @MON is a String: " & IsString(@MON) & @CR)
ConsoleWrite("@MDAY = " & @MDAY & "   ...   @MDAY is a Number: " & IsNumber(@MDAY) & @CR)
ConsoleWrite("@MDAY = " & @MDAY & "   ...   @MDAY is a String: " & IsString(@MDAY) & @CR)
ConsoleWrite("@YEAR = " & @YEAR & "   ...   @YEAR is a Number: " & IsNumber(@YEAR) & @CR)
ConsoleWrite("@YEAR = " & @YEAR & "   ...   @YEAR is a String: " & IsString(@YEAR) & @CR)

;.......... OUTPUT ..............................
;@MON = 04   ...   @MON is a Number: 0
;@MON = 04   ...   @MON is a String: 1
;@MDAY = 24   ...   @MDAY is a Number: 0
;@MDAY = 24   ...   @MDAY is a String: 1
;@YEAR = 2010   ...   @YEAR is a Number: 0
;@YEAR = 2010   ...   @YEAR is a String: 1

Digging further into this I discovered that au3 (v3.3.6.0) treats strings like numbers in that you can use mathematical operators on them.

ConsoleWrite("What is 4 (number) + 4 (number) = " & 4 + 4 & @CR)
ConsoleWrite('What is "4" (string) + "04" (string) = ' & "4" + "04" & @CR)
ConsoleWrite('What is 4 (number) + "04" (string) = ' & 4 + "04" & @CR)

;.......... OUTPUT ..............................
;What is 4 (number) + 4 (number) = 8
;What is "4" (string) + "04" (string) = 8
;What is 4 (number) + "04" (string) = 8

All looks as expected, no big deal. And again the Transitive Property of Equality is holding long and strong!! But this next section of code is where I need some help from you guys to help school me like a kindergartener.

ConsoleWrite("@MON = " & @MON & "   ...   @MON is a Number: " & IsNumber(@MON) & @CR)
ConsoleWrite("@MON = " & @MON & "   ...   @MON is a String: " & IsString(@MON) & @CR)

If 4 = "4" Then ConsoleWrite("a. TRUE" & @CR)
If "4" = "04" Then ConsoleWrite("b. TRUE" & @CR)
If 4 = "04" Then ConsoleWrite("c. TRUE" & @CR & @CR)

If "04" = @MON Then ConsoleWrite("i. TRUE" & @CR)
If 04 = @MON Then ConsoleWrite("ii. TRUE" & @CR)
If "4" = @MON Then ConsoleWrite("iii. TRUE" & @CR)
If 4 = @MON Then ConsoleWrite("iv. TRUE" & @CR)

;.......... OUTPUT ..............................
;@MON = 04   ...   @MON is a Number: 0
;@MON = 04   ...   @MON is a String: 1
;a. TRUE
;c. TRUE
;
;i. TRUE
;ii. TRUE
;iv. TRUE

Granted to obvious answer is string "4" is not equal to string "04", just as the string "red" is not equal to the string "car". Yeah I get that, thanks. What I don't completely understand is if 4 (A - number) equals "4" (B - string), and 4 (A - number) equals "04" (C - string), why doesn't "4" (B - string) equal "04" (C - string)? Remember (1g = 1ml = 1cm3) and (1g = 1cm3) and (1ml = 1cm3).

Based on the Help file, I'm not using the "==" operator and asking au3 to "test if two strings are equal", rather I am using the "=" to "test if two values are equal". And yes, its because two "strings" are being tested that au3 is doing a case insensitive test of the two strings. Ok, I get that too. But why does au3 sum (add) two strings as though they were numbers ("4" (string) + "04" (string) = 8 (number)). Its not like "red" + "yellow" = 13382194 (decimal value for orange based on hex:cc3232)

ConsoleWrite(";---------------------" & @CR)
ConsoleWrite('What is "red" (string) + "yellow" (string) = ' & "red" + "yellow" & @CR)
ConsoleWrite(";---------------------" & @CR)

;.......... OUTPUT ..............................
;---------------------
;What is "red" (string) + "yellow" (string) = 0
;---------------------

Wow... guess I should cut back on the coffee. To think all this because a simple date comparison against @MON failed to work as expected. My workaround was to use the Number() function in order to get the desired outcome. Crazy since all other date calculations using the Date/Time macros didn't require that.

$result = InputBox("test", "enter date (m/d or mm/dd): ")
$aDate = StringRegExp($result, "(\d+)", 3)

$test = _DateCalc($aDate[0], $aDate[1])
MsgBox(0, "Test", $test)

Func _DateCalc($m, $d)
    Local $aMonths[12][2] = [["January", "31"],["February", "28"],["March", "31"],["April", "30"],["May", "31"], _
            ["June", "30"],["July", "31"],["August", "31"],["September", "30"],["October", "31"],["November", "30"],["December", "31"]]

    If (((Number($m) = @MON) And ($d >= @MDAY) AND ($d < $aMonths[$m - 1][1] + 1)) Or _
            ((Number($m) > @MON) And ($d >= 1) And ($d < $aMonths[$m - 1][1]))) Then
        Return "Within Range " & $aMonths[$m - 1][0]
    Else
        Return "Outside Range"
    EndIf
EndFunc   ;==>_DateCalc

Thanks for reading, any insight/correction is appreciated.

[Melba23]

ssubirias3,

I think you are overcomplicating the issue. AutoIt is not a "typed" language - that is the variables are not limited to a single type (integer, string, float, etc). AutoIt does its best to guess what type you want to use in an expression, but it is not infallible - hence the various keywords for forcing a type (Number, String, etc).

Let us run through your examples (bear in mind I do not know exactly how AutoIt deals with them internally, but I can give a pretty good guess based on experience ):

a. If 4 = "4" Then ConsoleWrite("a. TRUE" & @CR)

- Here AutoIt sees a number first, notes it is being compared to a string, and decides that it will treat the string as a number - hence TRUE.

b. If "4" = "04" Then ConsoleWrite("b. TRUE" & @CR)

- Here AutoIt sees 2 strings, so it looks at the ACSII values of the strings - hence FALSE.

c. If 4 = "04" Then ConsoleWrite("c. TRUE" & @CR & @CR)

- As in the first example, a number first, so AutoIt converts the string into a number automatically - hence TRUE.

i. If "04" = @MON Then ConsoleWrite("i. TRUE" & @CR)

- Again 2 strings, but this time both are "04" - hence TRUE.

ii. If 04 = @MON Then ConsoleWrite("ii. TRUE" & @CR)

- Number first, so auto conversion of the string - hence TRUE.

iii. If "4" = @MON Then ConsoleWrite("iii. TRUE" & @CR)

- 2 strings, not the same - hence FALSE.

iv. If 4 = @MON Then ConsoleWrite("iv. TRUE" & @CR)

- Number first, so auto conversion of the string - hence TRUE.

Which matches the results I get when I run them.

Basically, do not make comparisions between numbers and strings. Use Number or String and get both sides of any comparison into the same type.

I hope that makes it all clearer.

M23

[ssubirias3]

I think you are overcomplicating the issue ... AutoIt does its best to guess what type you want to use in an expression ... Basically, do not make comparisions between numbers and strings. Use Number or String and get both sides of any comparison into the same type.

@M23 - thanks for the response and cool pic! The idea that au3 "guess[es] what type [of] ... expression" became obvious clear during my troubleshooting and examining the pattern of test results. Otherwise I might not have landed on the workaround of using Number() to force the type as you've suggested. .

Sorry for "overcomplicating" the issue, I was merely trying to understand why it appeared the operators (+, >=, =, etc) were not treating strings consistently. After all, a string is a string is a string, right?? So the string "4" + another string "04" should = 0 not 8; as in the example "red" + "yellow" = 0 ... but there I go again overcomplicating things. LOL.

Your point of not comparing numbers to strings is sound and logical advice! In fact the Help file reads "Macro Reference - Date And Time ... Notice that most return values are two-digits long." Why aren't there any remarks suggesting the use of the Number() function when using date/time macros in mathematical/logical statements? The au3 dev team is too smart and sharp to ever want to encourage/enable a naughty practice like comparing strings to numbers.

I guess the real question here is, "How or why does au3 internally guess the strings "04" and "4" to be numbers when used in a mathematical or logical statement?"

If au3 "internally" finds that strings in mathematical/logical statements are only numbers (0-9) and internally forces these strings into numbers, that would be totally groovy! But that in itself introduces another possible inconsistency. If @MON = "04" (a string) and $m = "4" (another string), then shouldn't au3 handle the statement [iF @MON = $m Then] as a number comparison not a string comparison? After all the statement [iF @MON + $m = 8 Then] is a true statement. Shouldn't this only be true for numbers not strings?

I'll be the first to admit I probably don't know what I'm talking about. But there just seems to be some inconsistency, dare I even hint at a b-u-g. Only in the name of education am I pressing on to understand why A=B, B=C, but A<>C.

ConsoleWrite('@MON = ' & @MON & '    ---    @MON is a String: ' & IsString(@MON) & @CR & @CR)

ConsoleWrite('What is @MON (string) + "4" (string) = ' & @MON + "4" & @CR)
If @MON + "4" = 8 Then ConsoleWrite('Hmmm... @MON + "4" = 8 ... Really?? string + string = number' & @CR & @CR)

If @MON + 4 = 8 Then ConsoleWrite('Hmmm... @MON (string) + 4 (number) = 8 (number) ... Naughty mix 1: string + number' & @CR)
If @MON >= 3 Then ConsoleWrite('Hmmm... @MON (string) is > OR = 3 (number) ... Naughty mix 2: string >= number' & @CR)
If @MON >= "3" Then ConsoleWrite('Hmmm... @MON (string) is > OR = "3" (string) ... Naughty mix 3' & @CR)
If @MON = 04 Then ConsoleWrite('Hmmm... @MON (string) = 04 (number) ... Naughty mix 3a: string = number' & @CR)
If @MON = 4 Then ConsoleWrite('Hmmm... @MON (string) = 4 (number) ... Naughty mix 3b: string = number' & @CR & @CR)

If @MON = 4 And @MON = 04 Then ConsoleWrite('(A = B) @MON (string) = 4 (number) AND @MON (string) = 04 (number)' & @CR)
If 4 = "4" Then ConsoleWrite('(B = C) 4 (number) = "4" (string) --- BUT ...' & @CR)
If @MON <> "4" Then ConsoleWrite('(A <> C) @MON (string) <> to "4" (string) ... WOW!!' & @CR)

;.......... OUTPUT ..............................
;@MON = 04    ---    @MON is a String: 1
;
;What is @MON (string) + "4" (string) = 8
;Hmmm... @MON + "4" = 8 ... Really?? string + string = number
;
;Hmmm... @MON (string) + 4 (number) = 8 (number) ... Naughty mix 1: string + number
;Hmmm... @MON (string) is > OR = 3 (number) ... Naughty mix 2: string >= number
;Hmmm... @MON (string) = 04 (number) ... Naughty mix 3a: string = number
;Hmmm... @MON (string) = 4 (number) ... Naughty mix 3b: string = number
;
;(A = B) @MON (string) = 4 (number) AND @MON (string) = 04 (number)
;(B = C) 4 (number) = "4" (string) --- BUT ...
;(A <> C) @MON (string) <> to "4" (string) ... WOW!!

QUESTION:

"How or why does au3 internally guess the strings "04" and "4" to be numbers when used in a mathematical or logical statement?"

Thanks in advance!

[Melba23]

ssubirias3,

How or why does au3 internally guess the strings "04" and "4" to be numbers when used in a mathematical or logical statement?

Only a Dev could answer that absolutely, but as I explained above, I get the impression that when faced with a comparison AutoIt looks at the first variable it comes across and then decides that is the type it is going to use from then on (with the exception of the == operator which forces a case-sensitive string comparison).

Elsewhere when AutoIt comes across a variable somewhere it expects to see a number, it seems to do the type switch automatically - and vice versa when it comes across numbers when it expects strings.

The lack of strict typing in AutoIt is both an advantage and a disadvantage. I think most longer-term users would see it more as a positive aspect, but I can understand why newcomers might not feel that way.

M23

[jchd]

AutoIt tries hard to be the most flexible and user-friendly possible.

What exactly susprises you in your "demonstration" script?

Is that the fact that an arithmetical operator like + tries to convert its arguments to numeric beforehand?

Is that the fact that the string "04" and "4" are not the same string?

BTW, if AutoIt doesn't fit you needs for a strongly typed language, don't feel anyhow obliged to use it. But if you post here asking for help, please, substanciate your claims that it is inconsistent and buggy. I don't mean that there are no dark corners left, nor that you or me or someone else can discover a bug at times. I'd say that given the spectral potential of this language, it's doing a fairly good job in _most_ cases.

[jchd]

I get the impression that when faced with a comparison AutoIt looks at the first variable it comes across and then decides that is the type it is going to use from then on

If (1 = "1") <> ("1" = 1) Then ConsoleWrite("Melba23 is wrong" & @LF)

With all due respect (sincerely).

[jaberwacky]

A = B

B = C

A <> C

If you assign C to B after you've assigned B to A then A will continue to store the old value of B...

Thus:

Global $A = 13
Global $B = 45
Global $C = 20

$A = $B 

MsgBox(0, 'A', $A)

$B = $C

MsgBox(0, 'B', $B)

If "04" is a string and '4' is a character and strings are arrays of characters right? If you add two characters with the '+' operator then aren't you actually adding their ascii values?

Edited April 25, 2010 by jaberwocky6669

[jchd]

The OP wasn't referring to assignment, as you do, but to the result of assertions.

If '4' = 4 then ... ; True

If '04' = 4 then ... ; True

If '4' = '04' then ... ; False

But the fact that a language allows you to be lazy to increase "practicality" (is that even correct?) doesn't mean you cn always be without being biten someday (like above).

[jaberwacky]

The OP wasn't referring to assignment, as you do, but to the result of assertions.

If '4' = 4 then ... ; True

If '04' = 4 then ... ; True

If '4' = '04' then ... ; False

But the fact that a language allows you to be lazy to increase "practicality" (is that even correct?) doesn't mean you cn always be without being biten someday (like above).

Oh ok silly me.

Oh wait, but isn't '=' an assignment operator?

Oh it's overloaded and so it depends on how the operator is used then?

Edited April 25, 2010 by jaberwocky6669

[Melba23]

jchd,

If (1 = "1") <> ("1" = 1) Then ConsoleWrite("Melba23 is wrong" & @LF)

AutoIt will look inside the 2 brackets first:

(1 = "1") - it finds a number first and so converts the string to a number = True

("1" = 1) - it finds a string first and so converts the number to a string = True

Now we have: boolean <> boolean => True <> True which poses no problem at all.

So Melba23 may still be right!

Or am I missing something (not unusual)?

M23

[jaberwacky]

If "04" == 4 Then
    MsgBox(0, '==', "TRUE")
Else
    MsgBox(0, '==', "FALSE")
EndIf

If "04" = 4 Then
    MsgBox(0, '=', "TRUE")
Else
    MsgBox(0, '=', "FALSE")
EndIf

Ok, I get it now, == compares a characters ascii value to the integer?

No, because "04" is a string and thus has more than one ascii value...

Well, right? A string is an array of chars?

This thread is inappropriate for my question, might start a new one.

Edited April 25, 2010 by jaberwocky6669

[jchd]

Much simpler: think of == as a binary String compare, while = applied to strings performs a Unicode case-insensitive comparison, applied to heterogenous arguments, will convert to numeric what is not.

Edit: missed typing the word String (added in bold)

Edited April 25, 2010 by jchd

[jchd]

Of course you know I was joking ...

... but half joking only:

(1 = "1") - it finds a number first and so converts the string to a number = True

That's correct and we agree on this.

("1" = 1) - it finds a string first and so converts the number to a string = True

Now we have: boolean <> boolean => True <> True which poses no problem at all.

That's impossible:

If (1 = "1") <> ("001" = 1) Then ConsoleWrite("Melba23 is wrong" & @LF)

I find that every case is explained in Language Reference - Datatypes, i.e. what coercion occurs in which case.

AutoIt variables are Variants and AutoIt is C++ i.e. "object" from this point of view and that behavior is (again, as I see it) completely consistent with usual (most intuitive) OO polymorphism.

Edited April 25, 2010 by jchd

[czardas]

I think that it's a cool feature that autoit attempts to interpret variable types based on context. It is encouraging to beginners when stuff just does what you expect, without all the complications of having to differentiate between different data types. The significance of these differences becomes apparent when all of a sudden you get an unexpected result. While I do not know the reasons behind the choices made by the autoit developers, I am happy they made them.

Edited April 26, 2010 by czardas