Umwandlung eines Strings in eine short real

[cbob]

Hallo Gemeinde!

Ich befasse mich gerade erst seit Kurzem mit pyton - bin also quasi Eisnteiger. Habe aber bereits etwas Erfahrung mit C/C++ und Delphi/Pascal.

Nun aber zu meiner Frage: ich habe hier einen Datenlogger, welcher mir seine Werte als ASCII-Zeilen ausgibt. Nun sind aber die Werte, die short reals entsprechen sollen als Strings codiert.
Also sollte bspw. der ausgegebene String '42493CD3' einer real-Zahl von 50.3094 entsprechen. Nun bin ich auf der Suche nach einer geeigneten Typ-Wandlung. Wie kann ich das in python elegant lösen? Oder muss ich "zu Fuß" den String zerpflücken und dann einzeln umrechnen?

Vielen Dank und beste Grüße
-c-

[__blackjack__]

@cbob: Erst in Bytes umwandeln und dann mit Hilfe des `struct`-Moduls aus der Standardbibliothek in eine Gleitkommazahl:

Code: Alles auswählen

In [354]: struct.unpack(">f", bytes.fromhex("42493CD3"))[0]                        
Out[354]: 50.30939865112305

[cbob]

Au, das ging schnell! Vielen Dank, blackjack.
Nun muss ich da nur noch verstehen, was die Sequenz genau macht. Aber das werd ich schon noch heraus finden!

[/me]

Nun muss ich da nur noch verstehen, was die Sequenz genau macht. Aber das werd ich schon noch heraus finden!

Es ist keine Hexerei. bytes.fromhex macht eine Bytes-Sequenz aus dem String. Die Bytes werden dann von struct.unpack durch den Formatstring ">f" in einen Fließkommawert umgewandelt. Da die Rückgabe ein Tupel (mit nur einem Element) ist, wird dieses dann explizit mit [0] angesprochen.

[cbob]

Es ist keine Hexerei. bytes.fromhex macht eine Bytes-Sequenz aus dem String. Die Bytes werden dann von struct.unpack durch den Formatstring ">f" in einen Fließkommawert umgewandelt. Da die Rückgabe ein Tupel (mit nur einem Element) ist, wird dieses dann explizit mit [0] angesprochen.

Dank Dir, /me - die Links waren sehr gut!! Hatte auf den deutschsprachigen Turtorial bzw. Buchseiten (zumindest die, die sich bei google so penetrant am vordersten platziert haben ) nicht wirklich eine Lösung gefunden. Ich hatte dann nach den für mich offensichtlicheren Lösungen wie

Code: Alles auswählen

float.fromhex('42493CD3')

gesucht bzw. weil es sich um eine Single handelt dann den hinweis auf die

Code: Alles auswählen

numpy.float32

gefunden - jedoch ohne Erfolg, weils bei nympy ja kein float32.fromhex gibt.

Allerdings finde ich nun zu

Code: Alles auswählen

struct.unpack

auch nicht wirklich einen Hinweis, wie float dabei behandelt wird - also eigentlich ist ja float64 der Standard bei python. Bei struct scheints anders zu sein?!

[/me]

Der Formatstring gibt an, wie die Bytes interpretiert werden.

[cbob]

Jaja, das ist schon klar - allerdings steht in der Beschreibung halt nur "float" - das wäre mit float.fromhex theoretisch auch shcon möglich, aber da wird ja ein float64 erwartet und folglich eine falsche Umwandlung gemacht.

[__deets__]

Der eingebaute float Typ ist immer ein Double. Also f64. Genauso wie ein integer (seit 3.X) immer eine beliebig genaue Ganzzahl ist. Also auch weit jenseits von 32 oder 64 Bit haben kann.

Doch bei ein/Ausgabe, wie im struct-Module, muss man das konkrete format angeben, und das steht da auch: https://docs.python.org/3/library/struct.html mit f oder d für 32 oder 64 Bit. Und endianess.

Dieses fromhex-Format scheint hingegen ein ganz anderer Standard zu sein. https://docs.python.org/3/library/stdtypes.html - da steht was von C99.

[cbob]

Der eingebaute float Typ ist immer ein Double. Also f64. Genauso wie ein integer (seit 3.X) immer eine beliebig genaue Ganzzahl ist. Also auch weit jenseits von 32 oder 64 Bit haben kann.

Jep, das hab ich auch so gelesen. Also normal ist f64.

Doch bei ein/Ausgabe, wie im struct-Module, muss man das konkrete format angeben, und das steht da auch: https://docs.python.org/3/library/struct.html mit f oder d für 32 oder 64 Bit. Und endianess.

Im C99-Standard interpretiere ich das so , dass eben float eigentlich einem single 32bitig entspricht und darüber double..
Und hier siehts dann offensichtlich nach C99 aus - weil man benutzt ja ein "f" als Formatkennung ...
(vgl.: http://www.open-std.org/jtc1/sc22/wg14/ ... f#page=456)

Dieses fromhex-Format scheint hingegen ein ganz anderer Standard zu sein. https://docs.python.org/3/library/stdtypes.html - da steht was von C99.

... wohingegen hier dann der Standard anders interpretiert wird - wahrscheinlich ist mein Verständnis dazu dann leider doch zu gering

Aber letztendlich langer Rede kurzer Sinn - mit o.g. Umwandlung funktionierts, was soll ich mir da jettz weiter n Kopf machen - bin ja schliesslich kein System/Compiler/Interpreter-Entwickler

Vielen Dank für die vielen Hinweise!