4 Byte in 1 float wandeln

[Gäst_5 (Gast)]

Hallo,

ich grübel schon ewig an folgendem Problem:

ich habe in data[0], data[1], data[2] und data[3]
jeweils ein Byte einer übertragenen float Zahl.

Diese zerstückelte float Zahl möchte ich nun wieder zusammen setzen.

Dazu habe ich mir folgendes gedacht:

int i,j,k,l;
float d;

i = data[0];
j = data[1];
k = data[2];
l = data[3];

d = (l<<24) | (k<<16) | (j<<8) | i;

printf("Value: %f",d);


Leider funktioniert es nicht, bzw es wird eine falsche float Zahl 
angezeigt.

[Johann L. (gjlayde)]

Nimm memcpy; das ist der einzig standardkonforme Weg für solche Hacks.

Alternative ist eine richtige Serialisierung / Deserialisierung des 
Objekts (hier: float).

[Peter II (Gast)]

Gäst_5 schrieb:
> Leider funktioniert es nicht, bzw es wird eine falsche float Zahl
> angezeigt.

kann auch nicht gehen, geht nur bei int.


uint8_t data[4];
float d;

memcpy( &d, data, sizeof( float ) );

woher bekommt du das float, wie kommen denn die 4byte zustande?

[ArthurDent (Gast)]

Ich wuerde glaube ich eine union verwenden.

[Gäst_5 (Gast)]

prima, mit memcpy funktioniert es!

1000 Dank!

[Peter II (Gast)]

ArthurDent schrieb:
> Ich wuerde glaube ich eine union verwenden.

aber dafür sind sie nicht gedacht und das verhalten ist nicht definiert. 
Es muss also nicht gehen.

[Reiner (Gast)]

Hi

hört sich nach einem Bigendian/Littleendian Problem an.
Vorrausgesetzt, beides sind IEEE floats (was mit einiger Sicherheit
anzunehmen ist, probier einfach mal

int i,j,k,l;
float d;

i = data[3];   // umgekehrte Reihenfolge wie oben!!!
j = data[2];
k = data[1];
l = data[0];

d = (l<<24) | (k<<16) | (j<<8) | i;

printf("Value: %f",d);

Reiner

[Peter II (Gast)]

Reiner schrieb:
> Hi
>
> hört sich nach einem Bigendian/Littleendian Problem an.
> Vorrausgesetzt, beides sind IEEE floats (was mit einiger Sicherheit
> anzunehmen ist, probier einfach mal

unsinn, wie soll dann aus diese berechung jemals eine floatzahl werden?

[Rolf M. (rmagnus)]

Ein float kommt da schon raus. Nur halt nicht der, der vorher 
reingesteckt wurde. ;-)

[amateur (Gast)]

Ein bisschen cast beim ersten Versuch hätte auch geholfen. Da wurde 
wahrscheinlich zu früh in float gewandelt.

[g457 (Gast)]

> Ein float kommt da schon raus. Nur halt nicht der, der vorher
> reingesteckt wurde. ;-)

mit kreativem Casten (und einem passendem Speicheralignment) geht das 
schon auch so:

$ cat main.c
#include <stdio.h>
#include <inttypes.h>

int main()
{
  const unsigned char pData[4] = {219, 15, 73, 64};

  float dResult;
  *(uint32_t*)&dResult = (uint32_t)((pData[3] << 24) | (pData[2] << 16) | (pData[1] << 8) | (pData[0]));

  printf("Value: %f\n", dResult);

  return 0;
}

$ rm -f main ; gcc -o main main.c

$ ./main 
Value: 3.141593

..will man aber nicht machen (gcc warnt auch (vollkommen zurecht) sobald 
man die Warnungen nicht unterdrückt und Optimierungen anfordert).

[Peter II (Gast)]

g457 schrieb:
> mit kreativem Casten (und einem passendem Speicheralignment) geht das
> schon auch so:

es fehlen noch ein paar casts. auf einer 16bit CPU geht es nicht.

[g457 (Gast)]

> auf einer 16bit CPU geht es nicht.

Macht aber nix, weil 16 Bits keine Anforderung waren. Ergo hab ichs mir 
selbst rausgesucht was ich nehm, und das ist amd64.

[Bernd O. (bitshifter)]

Gäst_5 schrieb:

> Dazu habe ich mir folgendes gedacht:
>
> int i,j,k,l;
> float d;
>
> [...]
>
> d = (l<<24) | (k<<16) | (j<<8) | i;

> Leider funktioniert es nicht, bzw es wird eine falsche float Zahl
> angezeigt.

Die passende Lösung über memcpy wurde ja schon gepostet, deshalb nur 
für's Verständnis:

Der obige Code erzeugt aus den vier Bytes eine 32-Bit Integerzahl, die 
dann in eine Floatzahl gecastet wird.
Die einzelnen Bits, die in den vier Bytes enthalten sind und für Float 
eine völlig andere Bedeutung haben als für Integer (Exponent, Mantisse 
und Vorzeichen) werden so erst mal nach den Integer-Regeln 
(fehl)interpretiert. Diese fehlinterpretierte Integer-Zahl wird dann 
korrekt nach float konvertiert.

Das vermeidet man dadurch, dass man den Compiler die Zahl erst gar nicht 
interpretieren lässt wie beim Beispiel mit memcopy oder beim Beispiel 
von g457 über Adressoperationen (referenzieren/dereferenzieren).

Gruß,
Bernd

[amateur (Gast)]

@g457

Ich schätze mal auf das:
(uint32_t)((...)|(...)|(...)|...)
kommt es an.

Es zwingt den Compiler erst die Zahl zusammenzustellen und dann fließen 
zu lassen.
Die vielen Zeiger verwirren nur.

[Heiko J. (heiko_j)]

Warum nicht viel einfacher ?
float * foo = (float *) &data[0];
float bar = *foo;

ggf. musst Du bei little/big endian die bytes im Array vorher 
umsortieren.

[Rolf M. (rmagnus)]

amateur schrieb:
> Ich schätze mal auf das:
> (uint32_t)((...)|(...)|(...)|...)
> kommt es an.
>
> Es zwingt den Compiler erst die Zahl zusammenzustellen und dann fließen
> zu lassen.


Nein. Das wird von diesem Teil gemacht:

g457 schrieb:
> *(uint32_t*)&dResult

[Bernd O. (bitshifter)]

amateur schrieb:
> @g457
>
> Ich schätze mal auf das:
> (uint32_t)((...)|(...)|(...)|...)
> kommt es an.
>
> Es zwingt den Compiler erst die Zahl zusammenzustellen und dann fließen
> zu lassen.
Nein - es kommt darauf an zu verhindern, dass der Compiler das Konstrukt 
aus den vier Bytes als Integert interpretiert und dann zwangsweise 
falsch nach float konvertiert.

> Die vielen Zeiger verwirren nur.
Das stimmt - insbesondere Anfänger tun sich damit schwer. Nötig sind sie 
aber trotzdem wenn man nicht über memcpy() gehen will.

Gruß,
Bernd

[ovonel (Gast)]

was ist das Problem an memcpy() ??

[Ralf G. (ralg)]

ovonel schrieb:
> was ist das Problem an memcpy() ??

Zu einfach!

[Bernd O. (bitshifter)]

ovonel schrieb:
> was ist das Problem an memcpy() ??

Vermutlich ist es eine Mischung aus "not invented here" und "was der 
Bauer nicht kennt, frisst er nicht".

;-)

Gruß,
Bernd

[Ralf G. (ralg)]

ovonel schrieb:
> was ist das Problem an memcpy() ??

Und: viel zu kompatibel.