Hexadecimal in AutoIt

[dem3tre]

Can someone explain why there seems to be such inconsistent handling of hexadecimal representations in AutoIt? I know what the docs say but the reasoning behind it is not clear to me.

ConsoleWrite( 'Dec( 0xff   ) == ' & Dec( 0xff ) & @LF )
ConsoleWrite( 'Dec( "0xff" ) == ' & Dec( "0xff" ) & @LF )
ConsoleWrite( 'Dec( "ff"   ) == ' & Dec( "ff" ) & @LF )

ConsoleWrite( 'IsNumber( 0xff   ) == ' & IsNumber( 0xff ) & @LF )
ConsoleWrite( 'IsNumber( "0xff" ) == ' & IsNumber( "0xff" ) & @LF )
ConsoleWrite( 'IsNumber( "ff"   ) == ' & IsNumber( "ff" ) & @LF )

ConsoleWrite( 'StringIsXDigit( 0xff   ) == ' & StringIsXDigit( 0xff ) & @LF )
ConsoleWrite( 'StringIsXDigit( "0xff" ) == ' & StringIsXDigit( "0xff" ) & @LF )
ConsoleWrite( 'StringIsXDigit( "ff"   ) == ' & StringIsXDigit( "ff" ) & @LF )

Which labors to produce:

CODE

Dec( 0xff ) == 597

Dec( "0xff" ) == 0

Dec( "ff" ) == 255

IsNumber( 0xff ) == 1

IsNumber( "0xff" ) == 0

IsNumber( "ff" ) == 0

StringIsXDigit( 0xff ) == 1

StringIsXDigit( "0xff" ) == 0

StringIsXDigit( "ff" ) == 1

These results seems odd to me since the 0x prefix is necessary to initialize a non-string hex number, why is it not recognized by StringIsXDigit in string form? Why does IsNumber not support hex numerals -- shouldn't it support at the very least the same form accepted by StringIsXDigit? Then there's the Dec function, what's going on there? 0xff = 597? At least it is consistent with StringIsXDigit in accepting "ff" and rejecting the 0x string prefix.

Reason for asking is that I am consolidating my assert functions and this lack of consistency with handling hex numerics is making my head hurt... okay, maybe its the beers doing that . Thanks for clearing the cobb webbs.

[therks]

First off, remember 0xff = 255.

MsgBox(0, '0xff = 255', 0xff = 255)

Yields True.

If you try MsgBox(0, '', 0xff) it will give you 255, because 0xff, without quotes, and thus not a string, evaluates to a pure number, which defaults to decimal.

So what's going on with your first line, Dec(0xff), is basically Dec(255), which equals 597, so does 0x255, so does Dec("255"). Dec is mainly for converting strings in hex representation ("ff") to decimal numbers. So Dec("ff") correctly equals 255. It gives you 0 for "0xff" because there are no X's in hexadecimal numbers, and it wants the whole string to be a hexadecimal "number", otherwise it dies.

StringIsXDigit, if you read the manual (which I just had to do, as I was confused as well) simply checks to see if the string contains 0-9, A-F.

"0xff" :: has X, invalid hex char, so false

"ff" :: has valid hex chars, so true

0xff = 255 :: 2 and 5 are definitely valid hex chars, so true again.

As for IsNumber, both your false results were from giving it strings, and strings are simply not numbers.

Did I leave anything out?

[dem3tre]

So what's going on with your first line, Dec(0xff), is basically Dec(255), which equals 597, so does 0x255, so does Dec("255").

The 597 result makes sense now. My sleep deprived brain was thinking the compiler maintained the numeric base when translating between non-string and string; what a mess that would make if it did :">

StringIsXDigit, if you read the manual (which I just had to do, as I was confused as well) simply checks to see if the string contains 0-9, A-F.

"0xff" :: has X, invalid hex char, so false

"ff" :: has valid hex chars, so true

0xff = 255 :: 2 and 5 are definitely valid hex chars, so true again.

Another good point. You're right, StringIsXDigit is true to its name. I guess what I was hoping for instead was not a character class test but a StringIsHex() function.

As for IsNumber, both your false results were from giving it strings, and strings are simply not numbers.

How does that square with the documentation then? Which reads:

Variants can be of two base types: Strings and Numbers. Additionally, a number can be whole (integer) or fractional/floating-point.

I understand why "0xff" would be false given what's already been said, but why doesn't it realize "ff" can be interpreted as a number? Isn't that its purpose? Bummer. I was hoping I wouldn't have to translate "0x" strings in my files before evaluating them. man I can really be dense sometimes...IsNumber is a type test ala IsString.

Thanks for shaking the tree!