Hex-Wert in Delphi übernehmen

[RWarnecke]

Hallo zusammen,

ich möchte ein Python Script nach Delphi übersetzen. Das funktioniert auch soweit sehr gut. Ich habe nur ein Problem mit dem folgenden Hex-Wert

Zitat:

0x00000000ffff000000000000000000000000000000000000 0000000000000000

Wenn ich den oben genannten Wert in Python über Print ausgebe, erhalte ich folgendes :

Zitat:

Target : 6.34309482461e+57

Wie muss ich in Delphi den Hex-Wert übergeben, damit ich das gleiche Ergebnis erhalte wie in Python ?

[Furtbichler]

Floating point, d.h. double vielleicht?

[RWarnecke]

Wie soll mir das weiterhelfen ? Ich verstehe Deinen Post nicht.

[mkinzler]

Die Anzeige deutet auf einen Hexwert hin.
Du musst den Hexstring wohl zerlegen, um ihn in einen Float zu wandeln.
Oder auf dem Umweg über einen Dezimalstring:
http://stackoverflow.com/questions/2...back-in-delphi

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

Zitat von Der schöne Günther (Beitrag 1252208)

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:

Zitat von jaenicke (Beitrag 1252209)

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

[Furtbichler]

Zitat:

Zitat von RWarnecke (Beitrag 1252203)

Wie soll mir das weiterhelfen ? Ich verstehe Deinen Post nicht.

So:

Delphi-Quellcode:

Type
  TDoubleConversion = record
    case boolean of
      false : (asDouble : Double);
      true  : (asBytes : Array [0..7] Of Byte);
  End;

var
  X : TDoubleConversion;

Begin
  x.AsBytes := HexStringToByteArray(yourHexStringHere);
  writeln(x.asDouble);
End;

Aber es sind ja 16 Bytes (war vorhin zu faul zum lesen, mal wieder). Ergo vielleicht so

Delphi-Quellcode:

  TExtendedConversion = record
    case boolean of
      false : (asExtended : Extended);
      true  : (asBytes : Array [0..15] Of Byte);
  End;

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

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:

Zitat von Medium (Beitrag 1252212)

(@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:

Zitat von Furtbichler (Beitrag 1252252)

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:

Zitat von himitsu (Beitrag 1252215)

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.

:angel:

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

Zitat von x000x (Beitrag 1252288)

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

Zitat von RWarnecke (Beitrag 1252290)

es ist das Ergebnis 26959535291011309493156476344723991336010898738574 164086137773096960 was Ihr gepostet habt. :duck: 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

Delphi-Quellcode:

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.

[Medium]

Ich vermute ja fast kryptografische Hintergründe. Dort wird ja doch ganz gerne mal rum-Modulo-iert, was gerade den Umgang mit solchen Monstern nach geeigneter Umstellung der Rechenwege trivialisiert. Da wäre dann sogar ein schlankes Recördchen mit den für die Rechnungen geeigneten Päckchen an Bits denkbar. Aber so komplett ohne Hintergrundinfos kann man wirklich nur und ausschließlich auf BigInt Libs verweisen (oder eben auf die eigenhändige Erstellung solcher Funktionalität, die ich mir aber auch abgucken wollen würde :))

[RWarnecke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1252294)

Zitat:

Zitat von RWarnecke (Beitrag 1252290)

es ist das Ergebnis 26959535291011309493156476344723991336010898738574 164086137773096960 was Ihr gepostet habt. :duck: 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.

Zitat:

Zitat von Medium (Beitrag 1252312)

Ich vermute ja fast kryptografische Hintergründe. Dort wird ja doch ganz gerne mal rum-Modulo-iert, was gerade den Umgang mit solchen Monstern nach geeigneter Umstellung der Rechenwege trivialisiert. Da wäre dann sogar ein schlankes Recördchen mit den für die Rechnungen geeigneten Päckchen an Bits denkbar. Aber so komplett ohne Hintergrundinfos kann man wirklich nur und ausschließlich auf BigInt Libs verweisen (oder eben auf die eigenhändige Erstellung solcher Funktionalität, die ich mir aber auch abgucken wollen würde :))

Bei diesem Wert geht es um die Berechnung von BitCoins anhand der aktuellen Difficulty und der eingesetzten Hashrate. Die ganze Berechnung besteht aus mehreren Formeln und bei einer Formel wird dieser Hex-Wert durch die aktuelle Difficulty des BitCoin - Netzwerkes geteilt. Die Orginale Funktion in Python sieht so aus :

Code:

def getTimePerBlock(difficulty,hashrate):
    target = 0x00000000ffff0000000000000000000000000000000000000000000000000000 / difficulty
    return math.pow(2,256)/(target*hashrate)

Dabei war der Returnteil noch der leichtere Teil. Diese Funktion gibt im Grunde die Zeit in Sekunden zurück die eine Berechnung für einen Block dauert. Daraus kann man dann die Anzahl Bitcoins pro Tag, pro Woche und pro Monat berechnen.