uint32_t => float (32) ohne cast!

Geht eigentlich nur über einen Cast, wenn Du keine zweite Lesefunktion 
erstellen willst. Ich weiß leider nicht, inwieweit man mit C generische 
Funktionen* entwickeln kann; das wäre nämlich eine zweite Möglichkeit.

*https://de.wikipedia.org/wiki/Generische_Programmierung

memcpy(&int, &float, sizeof(float));

Ich habe mal, weil mir die ganzen Hacks nicht gefallen haben, folgende 
Library geschrieben:
https://github.com/Daniel-Abrecht/IEEE754_binary_encoder

Noch einer schrieb:
> Von John Carmack, dem Meister aller Tricksereien stammt:

Pfusch. Das ist ganz sicher nicht das gewünschte.

Rufus Τ. F. schrieb:
> Noch einer schrieb:
>> Von John Carmack, dem Meister aller Tricksereien stammt:
>
> Pfusch. Das ist ganz sicher nicht das gewünschte.

"Trickserei" ist eine Obermenge von "Undefined Behaviour" ;-)

Stefan U. schrieb:
> Warum nicht? Ich finde diese Lösung total naheliegend.

Sehe ich auch so...

Wenn ich 4 Byte im Speicher habe kann ich diese doch interpretieren wie 
ich möchte.

Ob als float, int oder sogar struct.

Oder spricht etwas gegen diese Ansicht?

Peter II schrieb:
> das es Systeme gibt, die eine Ausrichtung der Daten im Speicher
> brauchen. Sie können nicht ein float an beliebiger Adresse verarbeiten.

Zum Beispiel?

Natürlich nur Plattformen bei denen ein float auch wirklich 32 Bit hat.

Ja OK, das der Compiler da vllt. dann nicht mitspielt ist eine andere 
Geschichte, ebenfalls das mit dem wegoptimieren.

Aber wenn der Compiler brav macht, was man in C geschrieben hat, sollte 
es doch kein Problem geben.

(Hab es mit dem gcc ausprobiert - embedded und linux) -> soweit alles 
OK.

Daniel A. schrieb:
> Ich habe mal, weil mir die ganzen Hacks nicht gefallen haben, folgende
> Library geschrieben:
> https://github.com/Daniel-Abrecht/IEEE754_binary_encoder

Ööööh ... wofür soll das gut sein?

32 und 64Bit Float-Zahlen haben doch eine eindeutige binäre 
Repräsentation ... Was spricht gegen casten?

beim gcc braucht's u.U. ein -fno-strict-aliasing (nach dem -O2/-Ox, 
sonst schaltet das wieder ein).

memcpy() ist aber die sauberere Lösung.

Stefan U. schrieb:
>> y = * ( float * ) &i;
>> Pfusch. Das ist ganz sicher nicht das gewünschte.
>
> Warum nicht? Ich finde diese Lösung total naheliegend.

Type Punning.

https://blog.regehr.org/archives/959

http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html

Quake hat ja auch funktioniert. Muss man halt immer sehen wo ich das 
genau wie einsetzen will.

https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code

Mampf F. schrieb:
> Daniel A. schrieb:
>> Ich habe mal, weil mir die ganzen Hacks nicht gefallen haben, folgende
>> Library geschrieben:
>> https://github.com/Daniel-Abrecht/IEEE754_binary_encoder
>
> Ööööh ... wofür soll das gut sein?
>
> 32 und 64Bit Float-Zahlen haben doch eine eindeutige binäre
> Repräsentation ... Was spricht gegen casten?

Eine CPU Architektur muss nicht zwingend IEEE 754 für floating point 
Operationen, verwenden, und ein float muss nicht zwingend 32bit gross 
sein. Auch bit und byte order können unterschiedlich sein. Solange man 
keine Daten zwischen unterschiedlichen Systemen austauscht wäre 
zumindest memcpy akzeptabel, falls in ein uint32_t aber nur, wenn man 
noch ein static_assert(sizeof(float)==sizeof(uint32_t),"Float wasn't 4 
bytes big"), einbaut. Bei einem cast ist nur nach char* in Ordnung, 
wegen aliasing.
Wenn man jedoch zwischen verschiedenen Geräten Daten austauschen will, 
muss man sicherstellen, dass diese auf allen möglichen Plattformen 
identisch gelesen und geschrieben werden, und das ist wofür man diese 
Library brauchen kann. Wenn du z.B. auf einem x86 little endian System 
einen float einfach casten würdest, hättest du, obwohl x86 IEEE 754 
verwendet, die bytes in little endian statt in network byte order aka 
big endian.

Ich versuche meinen Code immer so zu schreiben, dass er 
Programmunabhängig ist. Ich versuche möglichst nie annahmen zu Sachen zu 
machen, die nicht garantiert sind zu funktionieren, so etwas ist einfach 
Murks, und falls es doch mal nicht anders geht, füge ich zumindest einen 
compile time check zur Überprüfung der Annahme hinzu. Plattform 
spezifisches sollte nur an einer möglichst kleinen stelle verwendet 
werden, sofern man das Plattform spezifisches unbedingt verwenden muss, 
den Rest kann man abstrahieren. Damit erspart man sich auch später das 
suchen von scheinbar unerklärlichen Fehlern.

Amüsanter akademischer Ansatz, aber leicht an der Realität vorbei, denke 
ich :)

Für meinen Geschmack ist die Komplexität für ein triviales Problem zu 
hoch :)

Nicht IEEE754-Floats kommen in der Praxis doch so gut wie nicht vor und 
die Little- und Big-Endian Problematik wurde doch schon mehrfach gelöst 
(zB Network-Endianess und die passenden Konvertierungsfunktionen).

Die Lib unterstützt auch garnichts anderes außer einer Endian-Art und 
nur IEEE754.

Und Buggy ist sie auch:

> Subnormal floating point values (values really close to zero) are
> truncated to zero for simplicity reasons. I may change this someday.

Da kann von allgemeingültiger Ansatz eigentlich keine Rede sein.

In wie weit das besser sein soll als ein

float f = *((float*) &u);

erschließt sich mir daher nicht.

Mampf F. schrieb:
> Für meinen Geschmack ist die Komplexität für ein triviales Problem zu
> hoch :)
>
> Die Lib unterstützt auch garnichts anderes außer einer Endian-Art und
> nur IEEE754.
>
> Und Buggy ist sie auch:

Das ist folgendes aber auch, lies einfach oben:

> float f = *((float*) &u);

Ich versteh echt nicht warum einige hier so an einer offenbar falschen 
Lösung kleben wie am Fliegenleim, wo der korrekte Ansatz via memcpy doch 
bereits gegeben wurde — und gefühlt mindestens 1x pro Monat hier wieder 
und wieder aufs Tablett kommt.

Was ist das Problem bei memcpy?  Die 6 zu tippenden Buchstaben wohl 
kaum...

Arduino F. schrieb:
>   union
>   {
>     uint32_t  asUint;
>     float     asFloat;
>   } konverter;
>   konverter.asUint=value;
>   return konverter.asFloat;

Auch falsch.

Beim Lesen von .asFloat kann der Compiler davon ausgtehen, das Schreiben 
auf .asUint die inkompatible Komponente .asFloat nicht verändert.

Dieses "Type Punning per Union" wird zwar von GCC unterstützt (steht 
irgendwo im Kleingedruckten), konformes C ist es aber nicht.

Nochmal: Was ist so schlimm an memcpy? Ist hier sogar weniger zu tippen.

Aus z.B.
 

1

#include <stdint.h>

2

#include <string.h>

3

4

static inline float asFloat (uint32_t i)

5

{

6

    float f;

7

    memcpy (&f, &i, sizeof f);

8

    return f;

9

}

10

11

static inline uint32_t asUInt (float f)

12

{

13

    uint32_t i;

14

    memcpy (&i, &f, sizeof i);

15

    return i;

16

}

17

18

float nextFloat (float f)

19

{

20

    return asFloat (1 + asUInt (f));

21

}

macht avr-gcc -Os

1

nextFloat:

2

  subi r22,-1

3

  sbci r23,-1

4

  sbci r24,-1

5

  sbci r25,-1

6

  ret

 
getestet mit v8, v7, v6, v5, v4.9, v4.8. v4.7, v4.6 und WinAVR-20100110.

Peter II schrieb:
> Johann L. schrieb:
>> macht avr-gcc -Os
>
> man sollte die Funktionen aber schon aufrufen.

Man sollte den Quellcode schon lesen:

Johann L. schrieb:
> float nextFloat (float f)
> {
>     return asFloat (1 + asUInt (f));
> }

Stefan U. schrieb:
> Wenn ich davon ausgehe, daß die vier Bytes einem Float entsprechen dann
> ist das Casten des Pointers effektiver.

Was nutzt effektiver Code wenn er falsch ist.

> Ich verstehe nicht, wieso memcpy() besser sein soll, als einen Pointer
> zu casten. Im gegenteil, es ist unnötiger Overhead.

Hast du ein konkretes Beispiel?

Stefan U. schrieb:
> Ich verstehe nicht, wieso memcpy() besser sein soll, als einen Pointer
> zu casten. Im gegenteil, es ist unnötiger Overhead.

Für Leute, die aus der "Assemblerwelt" kommen, ist das natürlich 
Blödsinn. Ich habe 4 Bytes im Speicher und ob ich die als Ganz- oder 
Gleitkommzahl verwende ist meine Sache.

C führt eine Abstraktionsebene ein. Ein Variable ist nicht einfach eine 
typisierte Adresse im Speicher die ein paar Bytes belegt. Es sind auch 
verschiedene Regeln mit dieser Variablen verbunden. Eine davon ist das 
(verbotene) Aliasing.

http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

Mach einfach einen cast auf float und fertig. Sehe da für Deine 
Anwendung 0 Probleme.

Mampf F. schrieb:
> Die Lib unterstützt auch garnichts anderes außer einer Endian-Art und
> nur IEEE754.

IEEE 754 ist der standard, und convertier Funktionen zwischen Big und 
Little endian sind nun wirklich trivial, warum sollte ich denn 
irgendetwas anderes als IEEE 754 in Big Endian implementieren?

Little endian wird doch sowieso nur in einigen MS Formaten und 
Pseudostandards verwendet, und eventuell noch in einigen Freedesktop 
"Standards", und von denen halte ich nicht besonders viel. Die C 
standard liabrary hat auch kein Equivalent zu hton für little endian, 
bei all den MS Dateiformaten haben die Entwickler das doch direkt ohne 
Konvertierung rausgeschrieben, jedes MS Programm ist in der hinsicht 
garantiert kaputt Programiert, aber Windows läuft ja sowieso nur auf x86 
und amd64 CPUs.

> Und Buggy ist sie auch:
>
>> Subnormal floating point values (values really close to zero) are
>> truncated to zero for simplicity reasons. I may change this someday.

Nein, nicht buggy, nur etwas weniger genau für Zahlen mit 35 Nullen 
hinter dem Komma bei 32bit, oder 307 nullen hinter dem Komma für 64bit. 
Auf der Logarithmischen Scalala existierten die nummern garnicht mehr, 
also hat man sie linear verteilt, sinvoll gerundete Resultate in dem 
bereich hat man also keine.

Niemand rechnet absichtlich mit Subnormalen zahlen, einige CPU 
architekturen die IEEE 754 implementieren haben subnormale ebenfalls 
einfach ignoriert. Der einzige Zweck von Subnormalen war, dass bei 
Substraktionen von 2 Subnormalen nummern die Mathematisch nicht 0 
ergeben das Ergebnis wirklich nicht 0 ist, aber wegen Ungenauigkeiten 
bei Floats vergleicht diese sowieso niemand dierekt, auch nicht mit 0, 
statdessen verwenden bei float vergleichen alle einen Threshold für 
deren Delta, womit Subnormale wieder absolut sinnlos werden. Es gibt 
sogar Situationen in denen Subnormale Probleme machen.

Wenn dir die Subnormalen aber wirklich so wichtig sind, kannst du ja 
einfach die Librarie erweitern, und einen Pull request machen. Solange 
keine Hacks oder Annahmen zur Implementation der Floats auf 
Hardwareebene enthalten sind, nehme ich diese gerne an.

Grösste subnormalen:
http://www.binaryconvert.com/result_float.html?hexadecimal=007FFFFF
http://www.binaryconvert.com/result_double.html?hexadecimal=000FFFFFFFFFFFFF

Argumente gegen Subnormale:
https://en.m.wikipedia.org/wiki/Denormal_number#Performance_issues

Daniel A. schrieb:
> IEEE 754 ist der standard, und convertier Funktionen zwischen Big und
> Little endian sind nun wirklich trivial, warum sollte ich denn
> irgendetwas anderes als IEEE 754 in Big Endian implementieren?

und

Daniel A. schrieb:
> Eine CPU Architektur muss nicht zwingend IEEE 754 für floating point
> Operationen, verwenden, und ein float muss nicht zwingend 32bit gross
> sein.

und

Daniel A. schrieb:
> Auch bit und byte order können unterschiedlich sein. Solange man
> keine Daten zwischen unterschiedlichen Systemen austauscht wäre
> zumindest memcpy akzeptabel ... Wenn man jedoch zwischen verschiedenen
> Geräten Daten austauschen will,muss man sicherstellen, dass diese auf
> allen möglichen Plattformen
> identisch gelesen und geschrieben werden, und das ist wofür man diese
> Library brauchen kann.
> Ich versuche meinen Code immer so zu schreiben, dass er
> Programmunabhängig ist.

Wüsste nicht, wie deine Aussagen irgendwie zusammen passen ...

So oder so, deine Lösung ist nichts, was ich mir bookmarken werde, weil 
ich den Sinn dahinter nicht erkennen kann :)