Float Zahlen in Hex Zahlen umwandeln

[gammatester]

Zitat von danielA:

@Gammatester
Dein Arroganter Kommentar zeigt mir, dass du das Prinzip welches ich hier zeigen wollte definitiv nicht begriffen hast bzw. nicht kennst!
Sonst hättest du mich sicher auf den Fehler hinweisen können!
Im übrigen kosten Typecasts ne Menge Zeit und sind bei so einer einfachen umwandlung schlichtweg überflüssig!

Der Ausdruck 'Schrott' bezog sich auf das Ergebnis nicht auf Deinen Code (das der fehlerhaft war, ist ja unzweifelhaft). Im Übrigen brauchen Typecasts nicht nur nicht 'ne Menge Zeit' sondern sondern gar keine, weil die Variable vom Compiler re-interpretiert wird, und mM ist das auch einfacher und durchsichtiger als Deine Konstruktion, die einen impliziten verdeckten Typecast gleichkommt.

[himitsu]

Zitat von Darlo:

Hi,

kann ja sein, dass ich jetzt komplett daneben liege, aber meines Wissens sind Hex-Zahlen nur Integer.....

Sollte ich hier richtig liegen dann macht es Sinn, dass es
IntToHex() gibt aber kein
FloatToHex()

HEX ist kein Integer.

Eine Hexadezimalzahl ist eine "Zahl" in Hexadezimaler Darstellung. (0-15 pro Ziffer)

Einen Integer kann mal man auch in vielen Zahlensystemen darstellen (meisten kennen wir aber das Dezimalsystem mit 0-9 pro Ziffer)
oder Binär mit 0-1 pro Ziffer.

Als ganze Zahl läßt sich aber das Zahlensystem leicht umrechnen, weswegen es auch eine passende Funktion gibt.

Wenn man aber den "binären" Speicherhinhalt des "Float" betrachtet, dann ist der auch Hexadezimal darstellbar, aber der enthaltene Fießkommawert ist es nicht, weswegen es auch keine funktion dafür gibt.
Für den binären Inhalt des speichers gibt es z.B. BinToHex.

Aber wie schon erwähnt wurde, muß man da wissen in welcher Reihenfolge die Bytes übertragen werden müssen.

IntToHex stellt die Bytes z.B. in einer anderen Reihenfolge dar, wie das BinToHex.
BinToHex: kleines Byte im speicher = links und kleines Byte im Hex-String ist auch links
IntToHex: großes Byte im Hex ist links (also kleines Byte ist rechts)

[p80286]

Zitat von himitsu:

Aber wie schon erwähnt wurde, muß man da wissen in welcher Reihenfolge die Bytes übertragen werden müssen.

IntToHex stellt die Bytes z.B. in einer anderen Reihenfolge dar, wie das BinToHex.

BinToHex: kleines Byte im speicher = links und kleines Byte im Hex-String ist auch links
IntToHex: großes Byte im Hex ist links (also kleines Byte ist rechts)

Schön, daß das mal jemand ausformuliert, in der Hilfe wird das nicht explizit erwähnt.
(Und welcher Anfänger und wieviele Fortgeschrittene haben noch nie etwas von LittleEndian und BigEndian gehört?)

Gruß
K-H

[danielA]

@gammatester

Nun ja, da werden sich die Geister wohl ewig scheiden und das ist ja auch nicht schlimm .

Typecast:
tatsächlich ist es so, dass ich bereits aus Programmen Typecasts herausgenommen habe, indem ich einmal den Typ bestimmt und anschließend einer Variable zugewiesen habe. Dadurch habe ich Sekunden(!) gewonnen. So ganz ohne Rechenaufwand kann das also nicht stattfinden. Diskutieren kann man allerdings darüber, ob ein Cast auf ein "array of byte" verglichen mit einem Cast auf eine Klasse tatsächlich vergleichbar sind.

Ob mein "Konstrukt" weniger durchsichtig ist, kann ich nicht beurteilen.

Einfacher, performanter und flexibler ist es auf jeden Fall, denn:

Das Record nimmt genau 4 Byte im Speicher ein. Nicht mehr und nicht weniger. Durch Definition des Records gibt es keine Typumwandlung im eigentlichen Sinne. Im Grunde teilen sich 11 Variablen verschiedenen Typs den selben Speicherbereich. Nämlich genau die vom Record belegten 4 byte.

FloatValue, IntValue und CardinalValue dabei die kompletten 4 byte. Die Variablen ByteHH, ByteHL, ByteLH, ByteLL von links nach rechts ebenfalls. Das selbe gilt für die Variante mit den 4 Charactern. (H steht für High, L für Low)

Für die Umwandlung von Single in Integer sind demnach genau(!) ein Schreib + Ein Lesezyklus notwendig.

Belibige Bytekonvertierungen sind ebenfalls problemlos ohne Aufwand möglich. Ich weiß nicht was du mehr willst?

[p80286]

Aber Hallo,
gibt's jetzt wieder Glaubenskriege?
Meiner Unmaßgeblichen Meinung nach ist es egal ob ich mit einem varianten Record oder mehreren Typen arbeite. Solange ich die Daten nicht extra noch einmal schreiben muß, was bei 4 Byte ja nun auch nicht soo viel ist, ist es eigentlich nur Geschmackssache. Wobei ich zugeben muß, daß variante Records sich u.U. nicht so einfach erschließen.
(übrigens absolute ist irgendwie untergegangen!?)
Was ich bezweifle, ist, daß Typecasts Zeit kosten, da es sich ja eigentlich um eine andere Interpretation vorhandener Daten handelt. Wäre schon schön, wenn das jemand mit einem Beispiel belegen könnte.

Gruß
K-H

[himitsu]

Zitat von p80286:

Was ich bezweifle, ist, daß Typecasts Zeit kosten, da es sich ja eigentlich um eine andere Interpretation vorhandener Daten handelt.

Jupp.


Mit ein paar Ausnahmen.
- implizite/explizite "TypCasts" über Record-Operatoren
- gewisse TypCast von z.B. Strings, wo Delphi ein bissl CompilerMagic drin versteckt und z.B. Konvertierungen der String und/oder CodePages vornimmt

[Mikkey]

Zitat von danielA:

Typecast:
tatsächlich ist es so, dass ich bereits aus Programmen Typecasts herausgenommen habe, indem ich einmal den Typ bestimmt und anschließend einer Variable zugewiesen habe. Dadurch habe ich Sekunden(!) gewonnen. So ganz ohne Rechenaufwand kann das also nicht stattfinden. Diskutieren kann man allerdings darüber, ob ein Cast auf ein "array of byte" verglichen mit einem Cast auf eine Klasse tatsächlich vergleichbar sind.

Typecasts auf eine Klasse müssen mehr Rechenaufwand bedeuten, da sonst beim Cast einer unpassenden Referenz keine Ausnahme geworfen werden könnte. Irgendwo muss also eine Überprüfung stattfinden, ob die Referenz, die gecastet werden soll auch zu dem Zieltyp passt.

Bei Casts auf einen nicht-Klassen-Typ erfolgt keine Überprüfung.

Allerdings entspricht die Record-Methode weit eher der Typsicherheit, die ich an der Uni mal mit dem Ur-Pascal aufgenommen habe

[himitsu]

Records mit varianten Teilen entspricht quasi dem Absolute.
Nur daß beim Absolute keinerlei Prüfungen vom Compiler vorgenommen werden. (beim Record werden gemanagete Typen "verboten")

Ob man nun den Record nimmer und die Daten erst reinkopiert, um sie dann "gecastet" da auszulesen oder ob man den Typ direkt zum Casten nimmt, ist geschmackssache, wobei der direkte Weg sich die zusätzliche Kopieroperation erspart.

Man kann sich auch gern eine generische Funktion schreiben, welche die eine Variable als Parameter annimmt und das im anderen Format ausgibt.
Entspricht dann einem "expliziten" Cast, welchen man sich via Record-Operatoren basteln kann.

Und dann gibt es noch den Weg über einen Record-Helper, wo man sich eine Konvertierungsfunktion basteln kann, wie z.B. das .ToString an Klassen und neuerdings auch an einigen generischen Typen wie z.B. den Integern.


Oder man geht den klassischen Weg und nutzt eine Konvertierungsprozedur mit In-Param und Out/Var-Param, oder das Out als Result.

[danielA]

Hättest du vielleicht mal ein Beispiel oder einen Link zu der Absolute Methode?
Diese direktive kenne ich überhaupt nicht und wird in der Delphi- Hilfe von XE2 auch nur in einer Tabelle als direktive erwähnt aber mit keinem Wort erklärt.
Eine Möglichkeit gäbe es zur eigentlichen Aufgabe aber nocht. Aus Faulheit hätte ich diese sicher auch gewählt

Code:

var SingleVar : Single;
    Intvar : integer;
begin
  SingleVar := 1.1234;
  move(SingleVar, IntVar, 4);
  showmessage(IntToHex(IntVar));
end;

[himitsu]

Delphi-Quellcode:

var
  SingleVar: Single;
  IntVar: Integer absolute SingleVar;
begin
  SingleVar := 1.1234;
  ShowMessage(IntToHex(IntVar));
end;

Es besagt einfach nur, daß diese Variable an der selben "absoluten" Adresse beginnen soll, wie die angegebene andere Variable.

Aber ein Cast ist da eh besser/einfacher, vorallem da der Compiler einem bescheid gibt, wenn der Cast nicht "möglich" ist, z.B. aufgrund der Typen oder Speichergröße.

Delphi-Quellcode:

var
  SingleVar: Single;
begin
  SingleVar := 1.1234;
  ShowMessage(IntToHex(Integer(SingleVar)));
end;