Modify

Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#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:1 by AspirinJunkie, 5 years ago

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.

Last edited 5 years ago by jchd18 (previous) (diff)

comment:2 by J-Paul Mesnage, 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:3 by J-Paul Mesnage, 5 years ago

Owner: set to J-Paul Mesnage
Status: newassigned

Fix sent to Jon

comment:4 by Jon, 5 years ago

Milestone: 3.3.15.4
Owner: changed from J-Paul Mesnage to Jon
Resolution: Fixed
Status: assignedclosed

Fixed by revision [12567] in version: 3.3.15.4

comment:5 by Jon, 4 years ago

Milestone: 3.3.15.43.3.16.1

Fixed by revision [12713] in version: 3.3.16.1

Modify Ticket

Action
as closed The owner will remain Jon.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.