<number> + <bool> = <type?>

[MvGulik]

So, what for type should be returned here.

<number> + <bool> = <type?(int32 / int64 / double)>

int32 + bool = ?

number(bool) = ?

[AdmiralAlkex]

Test it? Or what do you mean with "should"?

[MvGulik]

What do you think it "should" be.

(with perhaps a background reason)

[Andreik]

$var = 12 + True
ConsoleWrite("Value: " & $var & @CRLF & "Type: " & VarGetType($var) & @CRLF)

Value: 13

Type: Double

[MvGulik]

Yes, yes. That's what AutoIt thinks it "should" be.

... Nap time, later ...

[JohnOne]

Or what it loosely thinks it should be.

We are talking about loosely typed language are we not.

$var = HWnd(False) + True;
ConsoleWrite("Value: " & $var & @CRLF & "Type: " & VarGetType($var) & @CRLF)

$var = True + HWnd(False);
ConsoleWrite("Value: " & $var & @CRLF & "Type: " & VarGetType($var) & @CRLF)

[Mat]

As a C programmer, there is no "bool" type. Zero is false and anything else is true. Look at the winapi definition of BOOL (rather than lower case, C++, bool) and you'll see its just "int".

[MvGulik]

Or what it loosely thinks it should be.

We are talking about loosely typed language are we not.

$var = HWnd(False) + True;
ConsoleWrite("Value: " & $var & @CRLF & "Type: " & VarGetType($var) & @CRLF)

$var = True + HWnd(False);
ConsoleWrite("Value: " & $var & @CRLF & "Type: " & VarGetType($var) & @CRLF)

Not sure what's on your mind here, but its a nice case were the order of types is significant.

[MvGulik]

Anyway:

I think in case of autoit it makes more sense if a bool (or other keyword) would be a int instead of a double/float when automatically converted to a number. Mainly because:

- double/float's are slower in math operation.

- double/float take precedence over int's in math operations.

Or, having a double type introduced (by default autoit means) in what generally are int-type calculations seems wrong to me.

In the Number(Bool/Keyword) case, which is also returning a double. Its kinda opposite to what the Number() documentation suggests.

Remarks: (Number())

If you pass number, function outputs the input.

A string beginning with letters has a numeric value of zero. A string beginning with digits has non-numeric characters stripped.

Default behavior results in auto-sized integer. If input value after conversion is within the range of 32bit integer the result is 32bit integer. If not the result is 64bit integer. Both signed.

Seems that with Number() the Keyword is already converted to a number(double) before Number() gets it as input. Or: "If you pass number, function outputs the input." ergo: Double.

Edited November 16, 2012 by MvGulik

[MilesAhead]

This is the one I like

$var = True + True
ConsoleWrite("Value: " & $var & @CRLF & "Type: " & VarGetType($var) & @CRLF)

comes up with value "2" type "double" when it should say

"2True" or even "too True": to my way of thinking.

[JohnOne]

It makes sense to me.

If you pass two different types into a maths operation, then both should be promoted

to highest native precision type before the calculation is made.

I think the speed you talk of is negligible.

Edited November 16, 2012 by JohnOne

[MvGulik]

I think the speed you talk of is negligible.

For autoit (0,001%) I guess it is ... .

[MilesAhead]

Not sure what's on your mind here, but its a nice case were the order of types is significant.

I can understand why adding a 1 to a ptr results in a ptr type. But I don't understand why adding a ptr with value 0 to a 1 results in a double. Seems to me it should be some kind of integer. A bit unexpected. Nothing to do with speed. Just seems uneccesary to promote to double when there's no floating point mentioned n the expression.

Edited November 17, 2012 by MilesAhead

[MvGulik]

But I don't understand why adding a ptr with value 0 to a 1 results in a double.

Because when a bool(keyword) is used in a number context autoit automatically converts its in a number value, of type double/float in this case.

And: (assuming Dev's where using logic I can understand.)

(Number-type + Ptr-type)= number-type (using pointer as additional math parameter)

(Ptr-type + number-type)= Ptr-type (doing math on a pointer)

Edited November 17, 2012 by MvGulik

[jchd]

This is the one I like

$var = True + True ConsoleWrite("Value: " & $var & @CRLF & "Type: " & VarGetType($var) & @CRLF)

comes up with value "2" type "double" when it should say "2True" or even "too True": to my way of thinking.

Do you mean "Double True"?

[Just kidding]

Anyway: I think in case of autoit it makes more sense if a bool (or other keyword) would be a int instead of a double/float when automatically converted to a number.

I second that. Note that it's precisely what is said (albeit implied) in the help file under Language Reference > Datatypes >

If you use arithmetics together with Boolean values (which is not advisable!), the following rules apply:

A Boolean true will be converted into the numeric value 1

A Boolean false will be converted into the numeric value 0

Example:

$Boolean1 = true

$Number1 = 100

$Number2 = $Boolean1 + $Number1

This will result in $Number2 to be the numeric value 101

Notice that the values shown are indeed integers. Double values would be (resp.) 1. 0. 101. or more clearly 1.0 0.0 and 101.0

I can understand why adding a 1 to a ptr results in a ptr type. But I don't understand why adding a ptr with value 0 to a 1 results in a double. Seems to me it should be some kind of integer. A bit unexpected. Nothing to do with speed. Just seems uneccesary to promote to double when there's no floating point mentioned n the exp<b></b>ression.

In this case it isn't promotion, it's demotion!

Not all (exact) integers can be represented exactly as double. Even then, a double value of 1.0 is in fact an abstract representation of an interval of reals whose mapping in the double format gets to 1.0 but there is no such ambiguity with integers.

Because when a bool(keyword) is used in a number context autoit automatically converts its in a number value, of type double/float in this case. And: (assuming Dev's where using logic I can understand.) (Number-type + Ptr-type)= number-type (using pointer as additional math parameter) (Ptr-type + number-type)= Ptr-type (doing math on a pointer)

That's also highly questionable. The order of operands for the addition and multiplication should never impact the result. This is violating a fundamental property of these operations: commutativity. Let alone associativity and distributivity...

I can understand the reasonning behind the scene: since a double is able to represent a broader range of values, let's keep immune to integer overflow by mapping the operation to doubles. This way saves a few cycles but leads to surprising results mentionned in this thread.

That's done at the expense of accuracy.

I would favor an implementation where conversion to double is only done when integral overflow is experienced. That means a few cycles spent for each operation but that would give consistent results and a way for the programmer to notice that an overflow occured (when such things can actually happen and they have significance) by testing VarGetType.

Edited November 18, 2012 by jchd

[MvGulik]

I can understand the reasonning behind the scene: since a double is able to represent a broader range of values, let's keep immune to integer overflow by mapping the operation to doubles.

Mmm. If that is true, and I have a hard time believing that, I think that would be a very bad reason.

As:

- A double/float takes precedence over int.

(as in: introducing a Int-type into a Double-type math operation has no down side(user side). Introducing a Double-type into a Int-type math operation has in my view.)

- It break the general logic that follows from Number(<string>)=int(by default, if applicable)

- And its not AutoIt's job to protect users against logic code/math errors.

*) "I have a hard time believing that": Mmm, feel I'm probably giving some dev's to much credit here.

Edited November 18, 2012 by MvGulik

[bogQ]

Yes, yes. That's what AutoIt thinks it "should" be.

i dont even see why your trying.

it do say, and i quote (Boolean values for use in logical expressions.)

and your trying to use it for calculus for god's sake

True is still expression .

its like asking why the hell string 'a'+'1' = 1 and its Double ..,why not = 'a1' and why its not int32 or string?.

If your mixing something that you know it shud not be mix, why are you consirned with results?

Edited November 18, 2012 by bogQ

[MilesAhead]

Do you mean "Double True"?

ur 2droll. Oh, what a sec. droll is not a built in type.

[MilesAhead]

Because when a bool(keyword) is used in a number context autoit automatically converts its in a number value, of type double/float in this case.

So what you're saying is, that's the way it is. Nothing about why it should be that way. I still don't see the point of using doubles unless you have to. A bit weird. It's like in Quick Basic I was getting slow loops unless I remembered to stick "DefInt a-z" at the top. Doing for loops with doubles by default is bizarre.

[MvGulik]

Way it is:

0+'1' = 1 {iD} {0xDouble} [0,0]
Number('1') = 1 {I3} (0x00.00.00.01) [0,0] <-- compared to this ...
Number('1', 1) = 1 {I3} (0x00.00.00.01) [0,0]
Number('1', 2) = 1 {I6} (0x00.00.00.00.00.00.00.01) [0,0]
Number('1', 3) = 1 {iD} {0xDouble} [0,0]

0+True = 1 {iD} {0xDouble} [0,0]
Number(True) = 1 {iD} {0xDouble} [0,0] ... <-- this is inconsistent (period), and initial reason for this post.
Number(True, 1) = 1 {I3} (0x00.00.00.01) [0,0]
Number(True, 2) = 1 {I6} (0x00.00.00.00.00.00.00.01) [0,0]
Number(True, 3) = 1 {iD} {0xDouble} [0,0]

Used code. (minus personal debug UDF)

debugout("0+'1'", 0 + '1')
debugout("Number('1')", Number('1'))
debugout("Number('1', 1)", Number('1', 1))
debugout("Number('1', 2)", Number('1', 2))
debugout("Number('1', 3)", Number('1', 3))
debugout("0+True", 0 + True)
debugout("Number(True)", Number(True))
debugout("Number(True, 1)", Number(True, 1))
debugout("Number(True, 2)", Number(True, 2))
debugout("Number(True, 3)", Number(True, 3))

Reason: (for using Double/Float as default type when converting some none number-type to a number type.)

I can understand the reasoning behind the scene: since a double is able to represent a broader range of values, let's keep immune to integer overflow by mapping the operation to doubles.

---

Think #20 post is plenty for this subject, that is resolved as far as I'm concerned.

Edited November 18, 2012 by MvGulik