Possible _ArrayUnique bug?

[czardas]

I'm not sure where you are up to with this, but I found more issues last night, when trying my randomly generated integer test using the latest stable release version. Firstly no duplicates are removed. Secondly the following message sometimes appears - that's two different problems:

"C:\Program Files\AutoIt3\Include\Array.au3" (2322) : ==> The requested action with this object has failed.:
$oDictionary.Item($vElem)
$oDictionary^ ERROR

The test is here: https://www.autoitscript.com/forum/topic/178825-_arrayuniquer/?do=findComment&comment=1283701

Edited November 23, 2015 by czardas

[czardas]

I'm not sure if any of the methods I have used in my code will be useful (maybe). I am adding non-hexadecimal (word character) prefixes to all data types (except binary which already has the prefix 0x) and representing the actual data in hexadecimal characters to avoid collisions. This adds a time penalty of course. Positive decimal integers already use hexadecimal characters 0-9. Negative integers require additional preprocessing in my function. A similar approach might help with the integer problems encountered here. Integers could also be prefixed with a highly unlikely sequence of private range unicode characters, and then processed as if they were unique strings - not entirely foolproof, but still plausible. The (Int-32 | Int-64 | Double) problem should entirely disappear. 

Edited November 23, 2015 by czardas

[Melba23]

czardas,

After a very frustrating morning I have the solution to the COM error you discovered. It seems that the return from ObjEvent must be assigned to a variable for a COM error handler to function. This script hard crashes as written - but reverse the ObjEvent line commenting and the COM error handler works as advertised:

Global $aIntegers[3]

$aIntegers[0] = Number(57, 1)
$aIntegers[1] = Number(57, 2)
$aIntegers[2] = Number(57, 3)

$bCOMError = False

Local $oDictionary = ObjCreate("Scripting.Dictionary")

ObjEvent("AutoIt.Error", "_COMErrFunc")
;Local $oObject = ObjEvent("AutoIt.Error", "_COMErrFunc") ; <<<<<<<<<<<<<<<<<<<<<<<<

For $i = 0 To 2

    $vElem = $aIntegers[$i]
    ConsoleWrite(VarGetType($vElem) & @CRLF)
    $oDictionary.Item($vElem)
    If @error Then
        ConsoleWrite("Error: " & VarGetType($vElem) & @CRLF)
        $bCOMError = True
        ExitLoop

    EndIf

Next

ConsoleWrite($bCOMError & @CRLF)

Func _COMErrFunc()
    ; Do nothing special, just check @error after suspect functions.
EndFunc   ;==>_COMErrFunc

So a very quick fix for that problem. I have no idea if an assignment was required in the past as I no longer have all the test scripts I used when rewriting the function - possibly it was removed to prevent "Declared but not used in function" warnings from Au3Check.

I am now investigating your "no duplicates are removed" comment.

M23

[czardas]

I see this is a tough one. I'm glad you tracked down one of the problems. I haven't used _ArrayUnique for a while, so the newest features were unclear to me. Now that I've read a little more about it, and tried a few ideas of my own, I have a clearer picture.

Edited November 23, 2015 by czardas

[Melba23]

czardas,

When I run your "integer" array through the existing _ArrayUnique function (with the COM error fix mentioned above) I get the following results using the 5 available $ARRAYUNIQUE_* parameters:

AUTO error: 7           - Expected as mix of Int32 & Int64 elements

FORCE32 error: 7        - Expected as mix of Int32 & Int64 elements

FORCE64 error: 7        - Expected as mix of Int32 & Int64 elements

MATCH error: 0
Unique: 2002            - Expected: 1001 doubles and 1001 Int32/64 integers
    
DISTINCT error: 0
Unique: 3003            - Expected: 1001 of each datatype

Given your "no duplicates are removed" comment, I assume you feel that the function should not differentiate between integer doubles and Int32/64 integers. Is this the case?

M23

[czardas]

In the first case, that's good news (I think). In my opinion the doubles are duplicates. Consider how such numbers might occur ($fVar = 2/1) and 2.0 is the same as 2. These numbers may be the result of processing and your average user doesn't care how the value is stored internally.

Edited November 23, 2015 by czardas

[Melba23]

czardas,

Regarding all 3 datatypes ( integer doubles and Int32/64 integers) as duplicates is very easily implemented for the MATCH case - the question remains as to whether this is what should happen. I am undecided - perhaps others could offer an opinion.

M23

[czardas]

I'm open to what others think. BTW I made a remark about this in my above edit, just now.

[Melba23]

czardas,

I have seen your edit and it has persuaded me that you are correct. I shall look at how best to implement this.

M23