Strange result on a simple arithmetical calculation

[Tlem]

I don't know if I make a mistake somewhere, but to find a solution of a problem, I try to make a simple calculation and he gave me a wrong result !

So this is the code :

$Cpt = 10
For $i = 1 to 20
    $Cpt *= 10
    ConsoleWrite($Cpt & @CRLF)
Next
MsgBox(64, "Strange...", "10*10*10*10*10 ... (20 time) gave this => " & $Cpt)
MsgBox(64, "Strange..." , "10^20 gave this => " & 10^20)

Did someone have a response of this strange fact ?

[youknowwho4eva]

My guess is byte limit of the variable

[Tlem]

I can't believe it because look here : http://www.autoitscript.com/autoit3/docs/faq.htm#15

Number range (floating point): 1.7E–308 to 1.7E+308 with 15-digit precision

Number range (integers): 64-bit signed integer

Edited December 9, 2008 by Tlem

[youknowwho4eva]

It's really odd...

$Cpt = 10^1
For $i = 1 to 19
    $Cpt *= 10
;Sleep(50)
    ConsoleWrite($Cpt & @CRLF)
Next
MsgBox(64, "Strange...", "10*10*10*10*10 ... (20 time) gave this => " & $Cpt)
MsgBox(64, "Strange..." , "10^20 gave this => " & 10^20)

fixes it.

Curse of IRQ 13? (for those that don't know, when cp's had math co-processors they were IRQ 13... and they didn't work to well)

Edit: don't need the sleep

Another Edit: also needs to be to 19

Edited December 9, 2008 by youknowwho4eva

[weaponx]

Both work.

$Cpt = 10.0
 For $i = 1 to 20
     $Cpt *= 10
     ConsoleWrite($Cpt & @CRLF)
 Next
 ConsoleWrite( 10^20 & @CRLF)

$Cpt = 10^0
 For $i = 1 to 20
     $Cpt *= 10
     ConsoleWrite($Cpt & @CRLF)
 Next
 ConsoleWrite( 10^20 & @CRLF)

Edited December 9, 2008 by weaponx

[youknowwho4eva]

Odd. I thought any number to the 0th power = 1

This also confuses me more

dim $Cpt[21]
$cpt[0] = 10
$cpt[1] = 10
For $i = 1 to 20
    $Cpt[$i] = $cpt[$i - 1] * 10
;~  Sleep(50)
    ConsoleWrite($Cpt & @CRLF)
Next
MsgBox(64, "Strange...", "10*10*10*10*10 ... (20 time) gave this => " & $Cpt[20])
MsgBox(64, "Strange..." , "10^19 * 10 gave this => " & 10^19 * 10)

[PsaltyDS]

The value of 10^20 overflows a signed INT64. By default, integers will be INT32 to start, then will be INT64, then should go to DOUBLE (float) for larger numbers, but the "*=" operator will not change to float, so it overflows the signed INT64 variable:

$Cpt = 10
For $i = 1 to 20
    $Cpt *= 10
    ConsoleWrite("$i = " & $i & "  $Cpt = " & $Cpt & "  Type = " & VarGetType($Cpt) & @CRLF)
Next
$Cpt = 2^63 - 1; Max positive value in an INT64
ConsoleWrite("2^64 - 1 = " & $Cpt & "  Type = " & VarGetType($Cpt) & @LF)
$Cpt = 10^20
ConsoleWrite("10^20 = " & $Cpt & "  Type = " & VarGetType($Cpt) & @LF)

P.S. If you change the value multiplier to 10.0, as weaponx posted, you get float types from the start because of the decimal point. Run the script above with "$Cpt *= 10.0" to see the difference.

Edited December 9, 2008 by PsaltyDS

[Tlem]

@weaponx

Your right, but 10.0 and 10^1 is not a way natural to write the number 10.

If I use Calc, I can do 10*10*10... 30 time without going to scientific writing and I have no calculation error.

[weaponx]

@weaponx

Your right, but 10.0 and 10^1 is not a way natural to write the number 10.

If I use Calc, I can do 10*10*10... 30 time without going to scientific writing and I have no calculation error.

I wasn't using 10^0 to represent 10, I used it so your loop could still go from 1-20 instead 1-19...

[youknowwho4eva]

So the answer is that it is the curse of IRQ 13? or is it a *= problem that can be fixed?

[PsaltyDS]

So the answer is that it is the curse of IRQ 13? or is it a *= problem that can be fixed?

I don't think it is considered a 'problem' to be fixed. In most languages aside from AutoIt variable typing is strict and the idea that a function would just automatically change a variable from and INT type to a Float on it's own would be considered a huge bug. The programmer is expected to determine if INT or Float type is appropriate and just code to that. In this instance you do that by using 10.0 vice 10 to force the Float type you need.

AutoIt is not strongly typed because all its variables are acutally just c-type variant under the hood anyway, and it will automatically make the change from INT32 to an INT64 variant as shown above, but the switch from an INT to a Float could be considered a bug in itself, I think.