Moin,
gut, einigen wir uns auf 'Bug'. Solange die Entwickler anderer Meinung bleiben, ist es sowieso egal.
Die Konsequenz wäre auch für mich, "Hexadezimalzahlen" mit 8 Stellen und einem Wert >= 8 in der führenden Stelle immer als Int64 zu behandeln. Ich wäre auch ziemlich sicher, dass diese Korrektur kaum Schaden in bestehenden Skripten anrichten würde.
Hosianna!
Eins habe ich noch vergessen:
MsgBox(0, "", Hex(-14))liefert zur Zeit FFFFFFF2. Das müsste dann auch angepasst werden.
Eins habe ich noch vergessen:
AutoIt MsgBox(0, "", Hex(-14))liefert zur Zeit FFFFFFF2. Das müsste dann auch angepasst werden.
Stimmt auffallend.
Dort ist die gleiche Vermischung aus Wert und Kodierung.
Solange die Entwickler anderer Meinung bleiben, ist es sowieso egal.
Genauso wird es kommen - entsprechende Erfahrung hierzu liegt reichlich vor.
Die Konsequenz wäre auch für mich, "Hexadezimalzahlen" mit 8 Stellen und einem Wert >= 8 in der führenden Stelle immer als Int64 zu behandeln.
Guter Vorschlag. Auf die Art bleibt es beim Interpreter weiterhin performant. 
Aber wird ja wie gesagt eh nicht umgesetzt.
Die Alternative wäre hingegen in der Doku zu vermerken, dass die Hexnotation nicht für Zahlenwerte genommen wird sondern nur für Bitfolgen.
Aber wird ja wie gesagt eh nicht umgesetzt.
Na dann....
Die Alternative wäre hingegen in der Doku zu vermerken, dass die Hexnotation nicht für Zahlenwerte genommen wird sondern nur für Bitfolgen.
Ich hoffe, Tweaky liest hier mit. Dann würde wenigstens in der deutschen Hilfe ein Hinweis stehen! Ggf. mit einer entsprechenden "Umrechnungsfunktion" welche korrekte (erwartbare) Ergebnisse zurrückgibt....
Stimmt auffallend.
Dort ist die gleiche Vermischung aus Wert und Kodierung.
Jetzt würde mich nur noch interessieren, welchen Wert die Funktion Deiner Meinung nach liefern sollte.
Das ist wirklich eine gute Frage.
Spontan hätte ich gesagt, das was meine _printHex() von weiter oben zurückgibt.
Aber von der Funktionsbeschreibung her ist es dann doch nicht so eindeutig.
Eigentlich fehlt es noch an der eindeutigen Beschreibung.
Es wird in der Doku direkt auf Int und Binary abgestellt.
Von daher wäre die Bitfolge dann doch was man eher erwarten würde.
Ja du hast Recht - hier ist die Nummer nicht so klar.
Andere Programmiersprachen sagen hingegen klar, dass die Funktion nur für Zahlenwerte gedacht ist und entsprechend auch die Zahlenwerte zurückgibt.
So gibt z.B. ein hex(-14) in Python -0xe zurück.
Die ziehen`s aber auch komplett durch und machen auch bei Gleitkommazahlen aus z.b. float.hex(-2.75) ein -0x1.6000000000000p+1.
Also man kann es nicht eindeutig ableiten, da die Doku hierzu sich nicht hinreichend festlegt was zurückgegeben werden soll.
Schön ist auch diese Zeile:
ConsoleWrite((0x80000000 = -0x80000000) & @CRLF)
ergibt bei mit TRUE.
Paul
Cool
Das ist für mich das bisher eindrücklichste Beispiel was dieses "Konzept" alles für bizarre Seiteneffekte hervorruft.
Langsam reift in mir der grobe Gedanke, wenn die AutoIt Devs sich in der Doku nicht festlegen wollen und dennoch weiter stur die Zahlenwerte ignorieren, dann muss diese Funktionalität eben evtl. durch eine UDF gewährleistet werden.
Allein die Existenz einer solchen UDF würde den einen oder anderen darauf stoßen, dass hier ein Detail existiert, welches bisher nicht adäquat behandelt wurde.
Gerade die fancy Gleitkommadarstellung in Hex wie in Python reizt mich schon die mal umzusetzen (auch wenn ich mir nicht wirklich vorstellen kann, dass das mal gebraucht wird).
Es scheint, als sei der Wechsel von Int32 nach Int64 falsch implementiert.
ConsoleWrite((0x80000000 = -0x80000000) & @CRLF)
ConsoleWrite((0x80000000 = 0x80000000 * -1) & @CRLF)
Global $a = -0x80000000
Global $b = 0x80000000 * -1
ConsoleWrite("$a: " & $a & " (" & VarGetType($a) & ")" & @CRLF)
ConsoleWrite("$b: " & $b & " (" & VarGetType($b) & ")" & @CRLF)ergibt bei mir:
True
False
$a: -2147483648 (Int32)
$b: 2147483648 (Int64)
Paul
Ja das hatten wir >>oben<< schon auseinander genommen.
Bei der Direktnotation von Hexzahlen entscheidet der Parser/Interpreter allein aufgrund der Stringlänge des Zahlenstrings ob dies als Int32 oder Int64 kodiert wird anstatt über den Zahlenwert.
Das ist aber fachlich Käse.
Einen immer noch >>performanten Ansatz<< für den Interpreter wie man das beheben kann hat Velted gezeigt.
Danke, hatte ich übersehen.
Eine generelle Umwandlung von Hexadezimalzahlen nach Int64 halte ich auch für die beste Lösung.
Paul
Ich hoffe, Tweaky liest hier mit.
Nein mache ich nicht 
.
Aber schreibt einfach hier rein was ich genau wie ändern soll. Ich übernehms dann 1:1. 
