Operators

[breakbadsp]

why  ("123a"=123) this returns True?

[Melba23]

breakbadsp,

Welcome to the AutoIt forums.

AutoIt can often produce strange results when comparing dissimilar datatypes. In this case I would suggest that AutoIt is forcing both sides to numbers - and so "123a" becomes 123, which is obviously the same as the number to which it is being compared. Here is an example of what is happening:

ConsoleWrite( Number("123a") & @CRLF)

The trick is to get both sides of any comparison into the same datatype so that AutoIt does not have to make any assumptions about which type to use.

M23

[jchd]

The RHS value 123 is numeric, hence a numeric comparison is made, forcing conversion of "123a" using Number().

Your condition is then equivalent to (Number("123a") = 123) and is trivially True.

(As Melba just said, fast Melba!)

[Trong]

casesense compare:

ConsoleWrite(   ("123a"==123)  & @CRLF)  ; => False
ConsoleWrite(   ("123a"="123A")  & @CRLF)  ; => True
ConsoleWrite(   ("123a"=="123A")  & @CRLF)  ; =>  False

Document: https://www.autoitscript.com/autoit3/docs/intro/lang_operators.htm

[Melba23]

Trong,

The "==" operator does indeed force both sides to strings before making a case-sensitive comparison, but I still believe that it is best if the user explicitly defines the datatype to use so that there can be no doubt as to what exactly is being compared.

An example which often causes problems is getting a value from an ini file (always returned as a string) which must be compared to a numeric value within the script - if the user is not careful the result will not be as expected.

M23

[Trong]

with = compare! use string type is better
 

ConsoleWrite(   (Int("999999999999999999999")=999999999999999999991)  & @CRLF)
ConsoleWrite(   (999999999999999999999=999999999999999999991)  & @CRLF)

 

[jchd]

These values aren't meaningful as they by far exceed max int64:

ConsoleWrite(VarGetType(999999999999999999999) & ' -> ' & 999999999999999999999 & @LF)

 

[Jos]

9 minutes ago, Trong said:

with = compare! use string type is better

This is not a correct statement and should be totally ignored! 

Jos

[jchd]

@Jos,

Is it possible that Au3Check would cry wolf when it encouters such invalid integers (int64 speaking)? It would certainly be painfully slow to check every integral operation at runtime, but at check/compile time we could afford wasting a number of cycles to do that.

[Trong]

Whatever! When entering data is unknown. Compare data processing in number type can get unexpected results!

https://www.autoitscript.com/autoit3/docs/intro/lang_datatypes.htm

https://msdn.microsoft.com/en-us/library/s3f49ktz(v=vs.71).aspx

[jchd]

Exactly, so it's the programmer responsability to sanity-check user input so as to carefully avoid undefined/unexpected behavior!

How would you otherwise add 43 to 999999999999999999999? That would need BigInt UDF, wich isn't exactly the same code as regular (in-range) integers.

The first rule of programming is "know your data". Said otherwise, sanitize and validate input of doubtful validity.

[Jos]

1 hour ago, jchd said:

@Jos,

Is it possible that Au3Check would cry wolf when it encouters such invalid integers (int64 speaking)? It would certainly be painfully slow to check every integral operation at runtime, but at check/compile time we could afford wasting a number of cycles to do that.

That should be possible. I will make it an Error.

Jos   

Edited July 19, 2017 by Jos

[Jos]

Try this version of au3check to see if that does what's expected.

Jos

[jchd]

Works like a charm, warm thanks. Sorry to have put you in business (again) for that but the occasion was good enough to deserve fixing, at the check step at least.

[czardas]

These numbers are simply overflowing and the interpreter is treating them as integers. The question is: if the interpreter thinks it's alright, then why would AU3Check throw an error? I personally think they should be converted to floats by the interpreter, but I wouldn't know how to do that. This is the reason for Operator64 - which tries to remain accurate with all numeric ranges and datatypes.

[Jos]

I can make that a warning too by au3check in case that's more appropriate, but won't be opening the autoit3 source to make changes.

Jos

[czardas]

I'm not sure what's best and would be happy either way. I do think a warning is appropriate. If the interpreter were to reject these values, then there would be every reason to report an error. As things are, it's a bit unclear if this behaviour really is by design. If not then it ought to be a bug.

[jchd]

@czardas,

Converting out of range integers into floats isn't doable, as it opens a whole new big can of worms. For instance what would the following code do?

Local $MyBigInt = 999999999999999999900
ConsoleWrite($MyBigInt & @LF)
$MyBigInt += 90
ConsoleWrite($MyBigInt & @LF & @LF)
For $i = $MyBigInt To $MyBigInt + 9
    ConsoleWrite($i & @LF)
Next

I've canned distinct issues here and none can be solved by floats. Have fun making the initial value a float by appending .0

Similar issues can arise in otherwise legal and inconspiciously wrong code:

Local $MyBigInt = 9223372036854775000    ; this initial value can come from Jove or user or ...
ConsoleWrite($MyBigInt & @LF)
$MyBigInt += 8
ConsoleWrite($MyBigInt & @LF & @LF)
For $i = 1 To 9
    ConsoleWrite($MyBigInt + 100 * $i & @LF)
Next

Very few languages offer guards against integral under- overflow and the only serious way out is to support arbitrary-size integer arithmetic out of the box. That or flag invalid constants at check time and warn the programmers that integers must fit in a signed int64.

Edited July 20, 2017 by jchd
spelling

[czardas]

I am aware of the limitations.

32 minutes ago, jchd said:

Have fun making the initial value a float by appending .0

I can and I do (edit : although not by appending .0)!

MsgBox(0, "", 1.0e+099 + 90)

No significant issues here!

Edit: Converting hard coded large integers won't work without the use of strings though. I just try to avoid overflow on calculations - only making conversions when needed. Some kind of warning is a good idea in any event.

Edited July 20, 2017 by czardas

[breakbadsp]

On 7/19/2017 at 2:53 PM, Melba23 said:

breakbadsp,

Welcome to the AutoIt forums.

AutoIt can often produce strange results when comparing dissimilar datatypes. In this case I would suggest that AutoIt is forcing both sides to numbers - and so "123a" becomes 123, which is obviously the same as the number to which it is being compared. Here is an example of what is happening:

ConsoleWrite( Number("123a") & @CRLF)

The trick is to get both sides of any comparison into the same datatype so that AutoIt does not have to make any assumptions about which type to use.

M23

Got it , Its just the implementation. Anyways using == is the best option if you want to avoid the extra typecasting headache