#3817 closed Bug (Fixed)
Double to Int64 type conversion - wrong results
| Reported by: | AspirinJunkie | Owned by: | Jon |
|---|---|---|---|
| Milestone: | 3.3.16.1 | Component: | AutoIt |
| Version: | 3.3.15.3 | Severity: | None |
| Keywords: | Int Number | Cc: |
Description
Following script:
$fN = 562949953421312.0
$iN = Int($fN, 2)
$iN2 = Number($iN, 2)
ConsoleWrite("$fN :" & $fN & " (" & VarGetType($fN) & ")" & @CRLF & _
"$iN :" & $iN & " (" & VarGetType($iN) & ")" & @CRLF & _
"$iN2:" & $iN2 & " (" & VarGetType($iN2) & ")" & @CRLF)
produces:
$fN :562949953421312 (Double)
$iN :562949953421313 (Int64)
$iN2:562949953421313 (Int64)
This applies to all integer numbers >= 249 stored as double.
The numbers themselves can be mapped completely and without rounding errors in IEEE 754 double precision.
The naive approach to implementing an Int() function would be a C-type cast ((long long) fValue)) or a C++-typecast (static_cast<long long>(fValue)).
However, these do not exhibit the problem:
#include <iostream>
using namespace std;
int main()
{
double f = 562949953421312.0;
long long iInt1 = (long long)f;
long long iInt2 = static_cast<long long>(f);
cout<<iInt1<<"\n"<<iInt2;
}
In old public source codes of AutoIt also the C-cast was used for the Int() function ((__int64)m_fValue in method n64Value in file variant_datatype.cpp).
In the meantime, however, there has apparently been a change here.
Attachments (0)
Change History (5)
comment:2 by , 5 years ago
Checking the code I realize that big positive float lead to negative return due to precision loss
so I decide to return in this case the max positive int64
Not sure is IEEE conversion compatible but I cannot accept a positive float number be converted as a negative number even if it is the max negative number ...
comment:4 by , 5 years ago
| Milestone: | → 3.3.15.4 |
|---|---|
| Owner: | changed from to |
| Resolution: | → Fixed |
| Status: | assigned → closed |
Fixed by revision [12567] in version: 3.3.15.4
comment:5 by , 4 years ago
| Milestone: | 3.3.15.4 → 3.3.16.1 |
|---|
Fixed by revision [12713] in version: 3.3.16.1

The problem has already been reported here once:
https://www.autoitscript.com/trac/autoit/ticket/3703
Anyway - the reasoning that this is not a bug is not correct.
As explained here, rounding errors are not the cause, since these should only occur from 253 - not already from 249.
Furthermore C/C++ gets along with this type conversion - only in AutoIt wrong results are produced.
So the problem must be related to the internal handling in AutoIt.