Hex-Wert in Delphi übernehmen

[DeddyH]

In hexadezimaler Scheibweise entspricht doch AFAIK jede Stelle einem Nibble (Halbbyte), oder? Wir haben also 16 "Gruppen" zu je 4 Nibble, d.h. 16*4*4 = 256, also stimmt Mediums Rechnung. Das passt nicht einmal in einen Extended.

Zitat von http://docwiki.embarcadero.com/Libraries/XE5/de/System.Extended:

Auf Win32-Systemen beträgt die Größe von System.Extended 10 Byte.

Auf Win64-Systemen ist der System.Extended-Typ aber ein Alias für den Typ System.Double, der nur 8 Byte groß ist. Diese Differenz kann die numerische Genauigkeit von Gleitkommaoperationen nachteilig beeinflussen. Weitere Informationen dazu finden Sie unter Delphi-Gesichtspunkte für plattformübergreifende Anwendungen.

[himitsu]

Oder anders gesagt:
Mein Editor meint es gibt 64 Zeichen (67 inkl. 0x und dem Leerzeichen), was 32 Byte entspricht.
"Native" Fließkommazahlen gibt es nur mit 4, 8 und 10 Byte.

Der größte Typ, den Delphi kennt, ist ein SET mit 256 Werten, welche auch 32 Byte ist, aber sonst ist alles Kleiner.



Im Grunde muß irgendwer erstmal rausbekommen, was das eigentlich für ein Typ sein soll.
Und wie Medium schon darstellte, seh ich auch irgendwie keinerlei Zusammenhang zwischen dem Hex-Wert und dem vorgegebenem Fließkommawert. Egal welches Format ich mir ausdenke ... mit $FFFF komm ich einfach nicht auf diesen "krummen" Wert.

Nichtmal als sehr großer "Integer" kommt was Passendes raus.
Wie gibst du denn den wert in Pyphon aus? Der Integer war da das einzige, was ich mir noch vorstellen konnte.

0x 00000000 ffff0000 00000000 00000000 00000000 00000000 00000000 00000000

$FFFF0000 * $100000000 * $100000000 * $100000000 * $100000000 * $100000000 * $100000000
=
4294901760 * 4294967296 * 4294967296 * 4294967296 * 4294967296 * 4294967296 * 4294967296
=
2,6959535291011309493156476344724e+67

Die Bytes zwischen Little-Endian und Big-Endian umzuwandeln bringt garnichts, genauso wie die Words.
Die DWORDs umzuwandeln, was eh allerdings sehr nutzlos ist, ergibt 4,1136986222856612385797845984991e+62
und QWORDs umzudrehehen, ist ja noch sinnloser und ergibt 1,7668201048317171789435028337278e+72 .




Das Einzige, was mir noch einfällt, ist "Mist".
Das ist kein Wert, es gibt im Pyphon einen Überlauf/Fehler und es kommt sonstwas dabei raus.

[Furtbichler]

Oder es ist ein Float, nur die ersten 8 Bytes interessieren und es ist auch noch falsch abgeschrieben worden... Was passiert eigentlich, wenn man die ersten Bytes in ein Double ballert?

[jaenicke]

Zitat von Medium:

(@jaenicke: Warum sollten die Nullen nach den F's auf ein Mal dezimal sein?)

Eigentlich sind sie das nicht, klar, aber wenn du die als hexadezimal nimmst, kommt man erst recht nicht auf den Wert, oder?

[himitsu]

Zitat von Furtbichler:

Oder es ist ein Float, nur die ersten 8 Bytes interessieren und es ist auch noch falsch abgeschrieben worden... Was passiert eigentlich, wenn man die ersten Bytes in ein Double ballert?

Zitat von himitsu:

Und wie Medium schon darstellte, seh ich auch irgendwie keinerlei Zusammenhang zwischen dem Hex-Wert und dem vorgegebenem Fließkommawert. Egal welches Format ich mir ausdenke ... mit $FFFF komm ich einfach nicht auf diesen "krummen" Wert.

[x000x]

Moin moin,

Rolf sollte nochmal evtl. die Stelle vom Python-Script posten. Wenn ich hier folgendes mache:

Code:

>>> x = 0x00000000ffff0000000000000000000000000000000000000000000000000000
>>> x
26959535291011309493156476344723991336010898738574164086137773096960
>>> float(x)
2.695953529101131e+67
>>> print(x)
26959535291011309493156476344723991336010898738574164086137773096960
>>>

dann kommt auch im Python interpreter der Wert raus den Frank (Himitsu) bereits gepostet hat. Ich komme aber nicht auf den Wert vom Thread-Ersteller...

[RWarnecke]

Zitat von x000x:

Moin moin,

Rolf sollte nochmal evtl. die Stelle vom Python-Script posten. Wenn ich hier folgendes mache:

Code:

>>> x = 0x00000000ffff0000000000000000000000000000000000000000000000000000
>>> x
26959535291011309493156476344723991336010898738574164086137773096960
>>> float(x)
2.695953529101131e+67
>>> print(x)
26959535291011309493156476344723991336010898738574164086137773096960
>>>

dann kommt auch im Python interpreter der Wert raus den Frank (Himitsu) bereits gepostet hat. Ich komme aber nicht auf den Wert vom Thread-Ersteller...

Ja, Peter Du hast recht. Ich bin in der Zeile verruscht und habe den Wert schon aus meiner Berechnung gepostet. Du und Himitsu haben recht, es ist das Ergebnis 26959535291011309493156476344723991336010898738574 164086137773096960 was Ihr gepostet habt. Aber selbst mit diesem Integer-Wert kann Delphi nicht umgehen, weil dieser zu groß ist.

[x000x]

Moin moin,

also dann kann ich nur auf (T)BigInt verweisen. Es gibt diverse Libs die dann solche großen Zahlen unterstützen.

[Uwe Raabe]

Zitat von RWarnecke:

es ist das Ergebnis 26959535291011309493156476344723991336010898738574 164086137773096960 was Ihr gepostet habt. Aber selbst mit diesem Integer-Wert kann Delphi nicht umgehen, weil dieser zu groß ist.

Darf man fragen, was dieser Wert für eine Bedeutung hat? Ich kann mir nicht vorstellen, daß es sich hier um eine Zahl handelt die etwas praktikabel Zählbares beschreibt.

[himitsu]

Den Wert 2.6959535e67 würde man locker in einen Double reingekommen.
und selbst in einen Single würde er passen, da "effektiv" nur 16 Bit belegt sind. (vom ersten gesetzten Bit, bis zum Letzen)

Ich weiß nicht, ob StrToFloat('$00000000ffff0000000000000000000000000000000000000000000000000000') das noch hinbekommt, bzw. ob IntToFloa überhaupt Hexadezimal versteht (so wie das StrToInt).
Ansonsten muß man das Hexadezimale selber auflösen und es Zeichen für Zeichen dezimal im Double zusammenrechnen.

Oder man nimmt halt doch eine BitInt-Implementation.

Oder, wenn es sich eigentlich "nur" im irgendwelche Binärdaten handelt, dann nicht in einen Integer/Fließkomma-Wert übersetzen und als Hexadezimal-String belassen.