Hex-Wert in Delphi übernehmen

[Der schöne Günther]

Nix verstehen.

Floats sind hier nicht im Spiel:

Zitat:

A hexadecimal string takes the form:

Code:

[sign] ['0x'] integer ['.' fraction] ['p' exponent]

( http://docs.python.org/2/library/std...html#float.hex )

Das sind doch normale Ganzzahlen (verdammt große), oder?

Passt das überhaupt noch in einen Int64?

[jaenicke]

Zitat von Der schöne Günther:

Passt das überhaupt noch in einen Int64?

Würde es, aber wie man auf 6.34309482461e+57 kommen könnte, wenn im Wert nur 0xffff, sprich 65535, vorkommt, sehe ich auch nicht.
Hinter dem Wert kommen noch 52 Nullen, mit 53 würde es fast hinkommen, aber das Leerzeichen in dem Wert irritiert mich.

[RWarnecke]

Zitat von jaenicke:

..., aber das Leerzeichen in dem Wert irritiert mich.

Dass hat der Quote-Tag hier im Forum verursacht.

Ich verstehe irgendwie immer noch nichts. Kann mir bitte jemand anhand eines Beispiels erklären, wie ich den Hex-Wert in einer Berechnung übergeben muss ?

[jaenicke]

Also eigentlich sieht der Wert für mich aus wie:

Delphi-Quellcode:

const
  a: Double = $00000000ffff * 10000000000000000000000000000000000000000000000000000.0;
// bzw.
const
  a: Double = $00000000ffff * 1E52;

Aber das sind ja 6,5535E56.

[Medium]

Der Wert ist ein riesen Otto, der geht gewiss nicht in einen Int64.
0000 0000 ffff 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
32 Bit + 32 Bit + 32 Bit + 32 Bit + 32 Bit + 32 Bit + 32 Bit + 32 Bit
= 256 Bit

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

Da Delphi keinen 256 Bit Integer kennt, bleibt nur die Umwandlung in einen Fließkommawert, wobei aber Genauigkeit flöten geht. Potenziell hier sogar ohne viel Verlust (zumindest binär gesehen) wegen der vielen Nullen hinten dran. Die Ausgabe von Python deutet z.B. darauf hin, dass der Wert zumindest für die Anzeige ein Mal durch einen Float-Wert geschleift wurde. Ob das so gehört, oder eine Grenze von Python ist, weiss ich nicht. Ich weiss nur, dass man ohne 3rd Party Libs bzw. entsprechende Handarbeit solche Werte nicht einfach so in einem Delphiprogramm nutzen kann - ausser eben wie o.g. als Fließkommazahl. Ob das in dem Fall eine Option ist, hängt davon ab was damit nachher noch alles passieren muss, das können wir hier nicht einschätzen.

[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?

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