Sehr große Zahlen addieren führt zum falschen Ergebnis

AspirinJunkie & Andy,

ich glaube eher, dass Ihr den Sinn der Hexnotation falsch interpretiert. Es gibt keine 'Hexadezimalzahlen'. Es gibt nur die 'Hexnotation'. Wenn jemand einer Varialen einen bestimmten Dezimalwert zuweisen will, was um Himmels Willen bringt ihn dann dazu, die Hexnotation anstelle der Dezimalzahl zu verwenden?

Du verlinkst einen Wikipedia-Artikel in dem 15x der Begriff "Hexadezimalzahl" verwendet wird - aber selbst behauptest du, dass es diese gar nicht gibt - soso.

Man kann Zahlen in Systemen mit jeder beliebigen Basis verwenden.

Das Dezimalsystem ist kein besonderes System sondern einfach nur das an was wir uns gewöhnt haben.

Alle Mechanismen von Zahlensystemen lassen sich auf alle Basen gleich anwenden.
Daher die Gegenfrage: Warum soll ausgerechnet das Dezimalsystem ganz anders behandelt werden als die anderen Systeme?

Zumal auch das Dezimalsystem am Ende nur die Interfaceschicht darstellt, da die Kodierung eh ausschließlich im Binärsystem passiert.

Letzter Versuch es anschaulich zu machen:

$dZahl = -10

ConsoleWrite("Zahlenwert: " & _printHex($dZahl) & @CRLF)
ConsoleWrite(StringFormat("Zahlenkodierung Int32: %s\n", Binary($dZahl)))
ConsoleWrite(StringFormat("Zahlenkodierung Int64: %s\n", Binary(Number($dZahl,2))))


Func _printHex($dNumber)
    ; printf (StringFormat) kann nur unsigned hex
    Return StringFormat("%s%#X", $dNumber < 0 ? "-" : "", $dNumber < 0 ? -$dNumber : $dNumber)
EndFunc

Und die Frage warum er das tun sollte oder nicht ist auch gar nicht relevant. Es geht um das dokumentierte Verhalten. Und davon weicht AutoIt immer noch ab - Punkt.
Und nochmal: Warum soll es ausgerechnet das erwartbare logische Verhalten in AutoIt sein, wenn jede andere Sprache es genau so macht wie von mir beschrieben?

Bin da auch bei AspirinJunkie, so lange man von Hexadezimalzahlen spricht muss es eine reine Umwandlung der Deszimahlendarstellung einer Zahl in die Hexadezimaledarstellung sein (der "echte" Zahlenwert darf dabei nicht verändert werden). Das gleiche gilt auch, wenn man die Zahl direkt als Hexadezimalezahl angibt.

Etwas anderes ist es jedoch, wenn man dies dann auf Bit-Ebene betrachtet ABER genau da muss es dann eine entsprechende Umwandlung mit Prüfungen geben. Sprich: Ist der übergebene Zahlenwert nicht mehr in dem (32)Bit-Bereich darstellbar, weil sich dieser zu 50% in einen positiven als auch zu 50% in einen negativen Bereich einteilt, muss es eine Fehlermeldung geben anstatt einem falschen (definitiv unerwarteten) Ergebnis.

Aber wie gesagt Bit-Bereich <> Hexadezimalzahl!

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.

Zitat von Velted

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.

Zitat von Velted

Solange die Entwickler anderer Meinung bleiben, ist es sowieso egal.

Genauso wird es kommen - entsprechende Erfahrung hierzu liegt reichlich vor.

Zitat von Velted

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.

Zitat von AspirinJunkie

Aber wird ja wie gesagt eh nicht umgesetzt.

Na dann....

Zitat von AspirinJunkie

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....

Zitat von AspirinJunkie

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

Zitat von Andy

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.