Is this a Bug? - StringLen() & Hex()

[funkey]

Hello.

Try this please:

Local $iLen = StringLen("00") / 2
ConsoleWrite($iLen & @CRLF)
ConsoleWrite(Hex($iLen, 4) & @CRLF)  ;result is 0 ??
ConsoleWrite(Hex(Int($iLen), 4) & @CRLF)
ConsoleWrite(Hex(1, 4) & @CRLF)

Is this a bug or is it just for me? Without division it works!?

[BrewManNH]

This is what I get when I omit the ,4 in the second consolewrite, which shows that 2/2 in floating point notation is different than 2/2 in integer notation.

1

3FF0000000000000

0001

0001

[funkey]

I found this in the documentation, so I know now why this is as it is (but I don't like it).

Changed: Hex() detects doubles internally and processes them respecting binary format.

[Mat]

What would you rather it do? Truncate the data?

Actually, what it should do is simplify the result of any operations like division, so that double values that are actually integral are cast automatically to integers.

[Valik]

Actually, what it should do is simplify the result of any operations like division, so that double values that are actually integral are cast automatically to integers.

No. That's not a good idea for general usage and may not be the desired behavior some of the time. Also, remember, an Int() cast function exists for a reason and will correctly account for some deviation due to floating point inaccuracies. It's also a performance impediment since detecting whole floating point numbers takes a couple steps and can be error-prone without accounting for representation inaccuracies. Detecting those inaccuracies adds additional steps.

[BrewManNH]

Totally talking out my ass here because I am no programmer, but when doing a division, couldn't you do something equivalent to a Mod(x,y) to see if the number to be returned is a whole number or not? That way you could do FP math or not depending upon the return.

[Valik]

Division is not a cheap operation. You do not want AutoIt to do a mod, conditional test and then possibly a second division. If a user is so concerned about getting a floating point result then they should pre-cast their values or cast the result.

Remember, it's AutoIt's job to make your life easier but it can't read your mind and judge your intent. Sometimes it needs help and that's why we provide cast functions so you gain fine control over what happens.

[funkey]

Next problem:

How can I do this right?

$sData = "0x43E77762000004180101"

$iDB = Int(BinaryMid($sData, 7, 2))
ConsoleWrite($iDB & @CR)        ;wrong

$sDB = BinaryMid($sData, 7, 2)
ConsoleWrite($sDB & @CR)
ConsoleWrite(Int($sDB) & @CR)   ;wrong

ConsoleWrite(Int("0x0418") & @CR)       ;solution that I want!

[Valik]

Format your input right. Integers are stored as little endian but your input data has them ordered for big-endian.

Here's your example modified to put the data in little-endian format.

Local $sData = "0xE7436277000018040101"

Local $sDB = BinaryMid($sData, 7, 2)
ConsoleWrite($sDB & @CR)
ConsoleWrite(Int($sDB) & @CR)   ;wrong

ConsoleWrite(Int("0x0418") & @CR)      ;solution that I want!

Remember, you are working with raw bits when you use Binary functions.

[wraithdu]

Another solution to get the value you are looking for (whatever its significance in integer form may be):

$sData = "0x43E77762000004180101"

$iDB = Int(String(BinaryMid($sData, 7, 2)))
ConsoleWrite($iDB & @CR)        ;better

[funkey]

Thanks Valik anmd wraithdu.

@Valik: Data comes from big endian machine (PLC), so I cannot change the format.

@wraithdu: Thanks for this solution. I found it out by my own right after posting, but had no time for editing the post.

Now I know that the binary functions do not return strings, they just look like some!