Modify

Opened 4 years ago

Closed 3 years ago

Last modified 3 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 Changed 4 years ago by AspirinJunkie

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.

Version 0, edited 4 years ago by AspirinJunkie (next)

comment:2 Changed 4 years ago by Jpm

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 Changed 4 years ago by Jpm

  • Owner set to Jpm
  • Status changed from new to assigned

Fix sent to Jon

comment:4 Changed 3 years ago by Jon

  • Milestone set to 3.3.15.4
  • Owner changed from Jpm to Jon
  • Resolution set to Fixed
  • Status changed from assigned to closed

Fixed by revision [12567] in version: 3.3.15.4

comment:5 Changed 3 years ago by Jon

  • Milestone changed from 3.3.15.4 to 3.3.16.1

Fixed by revision [12713] in version: 3.3.16.1

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Jon.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.