mein Problem ist, das ich eine binäre 32bit
Zahl habe, die ich zwar nach 32bit float
umrechnen kann, aber ein anderes Ergebnis bekomme,
als z.b. von dem Linux Programm <ghex>(Gnome).
Das Programm ist dabei nicht entscheidend, alle
Hexeditoren haben mir den gleichen 32bit float wert
angezeigt.

Der binär Wert ist:
00000000 00000000 10000000 10111111
Oder:
0000 0000 0000 0000 1000 0000 1011 1111
Oder:
0 00000000 00000001000000010111111

Das erste bit besagt das es eine positive
32bit float Zahl ist.

Die nächsten 8 bit sollen den Exponent ergeben.
Dazu rechnet man die 8bit in dezimal um, was 0 ist
und zieht davon 127 ab, dies ergibt -127.
Aslo würde die float Zahl normalerweise wie folgt
berechnet:
(1+2^-8+2-16+2^-18+2-19+2^-20+2-21+2^-22+2-23)*2^-127

Wie auch immer müsste dies laut dem Programm eine 32bit
float Zahl sein:
1,000000e+00
Wobei in dem Programm Little Endian aktiviert ist.
Ist standardmäßig aktiviert. Deaktiviere ich es
kommt eine andere 32bit float Zahl raus.

Wichtig ist mir zu wissen, nicht ob sein Ergebnis richtig
ist oder meins, sondern wie er darauf kommt. Sein
Ergebnis ist definitiv richtig, da ein fertiges octave
skript die gleichen 32bit float Zahlen ausgibt.
Dieses Skript wurden von Entwicklern geschrieben, deren
Software ich nutze...blablabla(unwichtig, außer Jemand
möchte es hören )

Hier noch eine zweites beispiel.
Die 32bit binär Zahl,
00000000 00000000 00000000 11000000
soll die 32bit float Zahl,
-2,000000e+00
ergeben.

Oder die 32bit binär Zahl:
00000000 00000000 10010000 01000001
soll
+18
ergeben.

Hat da Jemand ne Idee wie der hex Editor und das octave
skript auf diese 32bit float kommen ?

In wikipedia steht noch was unter "Interpretation des
Zahlenformats":
http://de.wikipedia.org/wiki/IEEE_754
Dies habe ich aber leider nicht ganz verstanden.

Grüße Markus

Während du den Binärwert direkt rechnen willst, interpretieren die Programme das als Speicherbereich im Little-Endian-Format.

Du rechnest also direkt mit

00000000 00000000 10000000 10111111

Während unter Berücksichtigung des Little-Endian-Formats eigentlich das Wort

10111111 10000000 00000000 00000000

die Grundlage für die Umrechnung bildet.

Trotzdem kommt da nicht 1,000000e+00 sondern -1,000000e+00 heraus. Da hast du wohl in deinem Beitrag geschludert.

Beim Rest sitmmt es aber:

00000000 00000000 00000000 11000000 Speicherbereich Little Endian 
11000000 00000000 00000000 00000000 Datenwort    		       
-2.0                                Float-Wert  

00000000 00000000 10010000 01000001 Speicherbereich Little Endian   
01000001 10010000 00000000 00000000 Datenwort	               
18.0                                Float-Wert

Du hast das Stichwort schon genannt: "Little Endian"

Während du den Binärwert direkt rechnen willst, interpretieren die Programme das als Speicherbereich im Little-Endian-Format.

Du rechnest also direkt mit

00000000 00000000 10000000 10111111

Während unter Berücksichtigung des Little-Endian-Formats eigentlich das Wort

10111111 10000000 00000000 00000000

die Grundlage für die Umrechnung bildet.

Trotzdem kommt da nicht 1,000000e+00 sondern -1,000000e+00 heraus. Da hast du wohl in deinem Beitrag geschludert.

Beim Rest sitmmt es aber:

00000000 00000000 00000000 11000000 Speicherbereich Little Endian 
11000000 00000000 00000000 00000000 Datenwort    		       
-2.0                                Float-Wert  

00000000 00000000 10010000 01000001 Speicherbereich Little Endian   
01000001 10010000 00000000 00000000 Datenwort	               
18.0                                Float-Wert

Hey, hab auch noch mal en frage.

würde aus

00000000 00000000 10000000 10111111

im little endian nicht

11111101 00000001 00000000 00000000

werden?

Gruss

Hey, hab auch noch mal en frage.

würde aus

00000000 00000000 10000000 10111111

im little endian nicht

11111101 00000001 00000000 00000000

werden?

Gruss

Um in Vokard-Manier zu antworten: Nope!

Die Grenzen entstehen aber sobald es sinnvoll im Sinne von effizient sein soll. Und bei einer Speicherorganisation in Bytes macht es nur Sinn das Datenwort ebenfalls in Bytes aufzuteilen und diese dann unter bestimmten Konventionen im Speicher abzulegen (Big-Endian, Little-Endian, Alignment-Regeln, ...)

32Bit Datenworte werden von rechts nach links notiert, d.h. das "0te Bit" steht ganz rechts:

Bit 31 -> 01000001 10010000 00000000 00000000 <- Bit 0

Also, ist auch das niedrigste Byte rechts.

Notationen von Speicherbereichen machen eigentlich nur Sinn, wenn die Speicheradressen auch dabei stehen. Geht man von Little Endian aus und notiert die Speicherstellen aufsteigend von links nach rechts, dann kannst du sagen die Bytes aus dem Datenwort werden "verdreht".

Speicher:

00000000 00000000 10010000 01000001 
________|________|________|________|________|
Byte 305|Byte 306|Byte 307|Byte 308|Byte 309|  ...

Notiert man den Speicher anders, also z.B. absteigend von links nach rechts, dann verdreht sich nichts.

01000001 10010000 00000000 00000000 
________|________|________|________|________|
Byte 315|Byte 314|Byte 313|Byte 312|Byte 311|  ...

Man muss einfach darauf achten, dass bei Little-Endian das niedriegste Byte (Bit 0 bis Bit 7) auf der niedriegsten Adresse ist und die anderen dann entsprechend anordnen.

ich bin ganz offenbar im richtigen Forum. Folgendes Problem quält nicht: Aus einem Standalone-Messgerät aus den 90er Jahren lese ich einen Datenstream aus, direkt in den PC rein übr serielle SN.

Solange es um ascii geht alles easy. Aber es sind auch Zahlen in dem Stream, die in einem FP-Format abgelegt sein dürften.

Wenn mich nicht alles täuscht wird dafür ein 4-Byte Format verwendet. Aber trotz Tüftelns bekomme ich einfach nicht heraus, wie die Zahlen im Array abgelegt oder angeordnet sind. Beispiel: ich lese

b1 b2 b3 b4
0100.0000.0111.0010.1000.1111.0101.1010

Das dürfte einem der vier Werte entsprechen, die ich zufällig auf dem Display des Messgerätes erkannt habe 55.5, 139.0, 39.8 oder 15.0.

Aber der Binär-String ist mit der gängigen EEE 7xxx-Codierung (S1e5m23 ..usw.) nicht in Einklang zu bringen.

KLeine Hilfe: Messgerät geöffnet und geschaut, welche CPU. Sieht aus wie ein 16 Bit Datenbus, CPU durch Kleber und Kratzer unkenntlich gemacht. Leider. Evtl Intel-kompatibles Zeug (also wohl: little endian).

Mehr habe ich nicht als Anhaltspunkte. Wer hat eine Ahnung, wie die Werte abgelegt oder "versteckt" sind?

Danke
Vick