Custom Query (3931 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (79 - 81 of 3931)

Ticket Resolution Summary Owner Reporter
#3817 Fixed Double to Int64 type conversion - wrong results Jon AspirinJunkie
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.

#3850 Fixed _WinAPI_GetDriveNumber never returns -1 as partition number Jpm AspirinJunkie
Description

The documentation for _WinAPI_GetDriveNumber says:

[2] - The partition number, or (-1) if device cannot be partitioned.

This is consistent with the description of the STORAGE_DEVICE_NUMBER structure.

However, the problem here is that the PartitionNumber part is of data type DWORD - i.e. an unsigned integer. A value of -1 is therefore simply not possible. In C this is not a big problem, because DWORDs can also be tested for -1:

(DWORD)4294967295 == -1 // true

In AutoIt, however, 4294967295 is always returned in the case of -1 due to the conversion to Int64:

#include <WinAPIFiles.au3>

Local $aData = _WinAPI_GetDriveNumber('d:') ; a non partionable drive like a cd-drive
ConsoleWrite('Partition number: ' & $aData[2] & @CRLF)

Therefore, as a pragmatic solution, I suggest to change the structure definition as follows, deviating from the Win API documentation:

Local $tSDN = DllStructCreate('dword;dword;LONG')
#3869 Fixed Subtraction operator before power operation is parsed incorrectly Jon AspirinJunkie
Description

For the operation of the basic form a - b^e, the result depends on the data type of the base b and the parity of the exponent e.

The following test script:

Global $sString = ""

$x = 2

$y = 4
$sString = StringFormat("% 15s = %d\n", "11 - 2 ^ 4", 11 - 2 ^ 4) & _
    StringFormat("% 15s = %d\n", "11 - 2.0 ^ 4", 11 - 2.0 ^ 4) & _
        StringFormat("% 15s = %d\n", "11 - 2e0 ^ 4", 11 - 2e0 ^ 4) & _
        StringFormat("% 15s = %d\n", "11 - '2' ^ 4", 11 - '2' ^ 4) & _
        StringFormat("% 15s = %d\n", "11 - $x ^ 4", 11 - $x ^ 4) & _
        StringFormat("% 15s = %d\n", "11 - (2 ^ 4)", 11 - (2 ^ 4)) & _
        StringFormat("% 15s = %d\n", "11 - - 2 ^ 4", 11 - - 2 ^ 4) & _
        StringFormat("% 15s = %d\n\n", "11 - 2 ^ $y", 11 - 2 ^ $y) 

$y = 3
$sString &= StringFormat("% 15s = %d\n", "11 - 2 ^ 3", 11 - 2 ^ 3) & _
    StringFormat("% 15s = %d\n", "11 - 2.0 ^ 3", 11 - 2.0 ^ 3) & _
        StringFormat("% 15s = %d\n", "11 - 2e0 ^ 3", 11 - 2e0 ^ 3) & _
        StringFormat("% 15s = %d\n", "11 - '2' ^ 3", 11 - '2' ^ 3) & _
        StringFormat("% 15s = %d\n", "11 - $x ^ 3", 11 - $x ^ 3) & _
        StringFormat("% 15s = %d\n", "11 - (2 ^ 3)", (11 - 2 ^ 3)) & _
        StringFormat("% 15s = %d\n", "11 - - 2 ^ 3", 11 - 2 ^ 3) & _
        StringFormat("% 15s = %d\n\n", "11 - 2 ^ $y", 11 - 2 ^ $y) 

ConsoleWrite($sString)

produces under 3.3.16.0:

     11 - 2 ^ 4 = 27
   11 - 2.0 ^ 4 = 27
   11 - 2e0 ^ 4 = 27
   11 - '2' ^ 4 = -5
    11 - $x ^ 4 = -5
   11 - (2 ^ 4) = -5
   11 - - 2 ^ 4 = -5
    11 - 2 ^ $y = 27

     11 - 2 ^ 3 = 3
   11 - 2.0 ^ 3 = 3
   11 - 2e0 ^ 3 = 3
   11 - '2' ^ 3 = 3
    11 - $x ^ 3 = 3
   11 - (2 ^ 3) = 3
   11 - - 2 ^ 3 = 3
    11 - 2 ^ $y = 3

and under 3.3.14.5:

  11 - 2 ^ 4 = 27
11 - 2.0 ^ 4 = -5
11 - 2e0 ^ 4 = -5
11 - '2' ^ 4 = -5
 11 - $x ^ 4 = -5
11 - (2 ^ 4) = -5
11 - - 2 ^ 4 = -5
 11 - 2 ^ $y = 27

  11 - 2 ^ 3 = 3
11 - 2.0 ^ 3 = 3
11 - 2e0 ^ 3 = 3
11 - '2' ^ 3 = 3
 11 - $x ^ 3 = 3
11 - (2 ^ 3) = 3
11 - - 2 ^ 3 = 3
 11 - 2 ^ $y = 3

Two possible explanations for this behaviour:

  1. binary minus is misinterpreted as unary minus:
    • The minus has two functions - once as a binary minus operator and once as a unary sign operator.
    • The tricky thing about this is that the binary operator has a lower priority than the power operator.
    • The sign operator, on the other hand, has a higher priority (in contrast to mathematics) than the power operator.
    • This leads to the implicit execution (-2)^4
    • The basic problem here, however, is that even if the minus here is only interpreted as a sign operator, we still lack a binary operator that links the right side with the 11. The parser seems to assume a plus operator for this.
    • Furthermore, there is no indication in the AutoIt documentation so far that the sign operator has a higher valence than the power operator.
  1. the minus is executed twice:
    • the --Operator seem to be executed twice - once as a unary operator (sign) and once as a binary operator (the minus operation).
    • This leads to the implicit calculation 11 - (-(2^4))
Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.