float Berechnung mit int-Werten erzwingen

Ok, vielen Dank! Da mir "float"-Genauigkeit genügt, werde ich somit die 
3. Variante benutzen.

warum willst du unbedingt das als float rechnen, wegen dem Runden? Oder 
ist das ganze nur ein einfaches Beispiel?

Denn hier kann man die selbe genauigkeit auch mit int erreichen.

Ja, wegen dem runden. Das war nur ein Zahlenbeispiel, va ist in der 
Applikation variabel!

..und die floatrechnung "kostet" nichts, ich habe da einen MPC8314 mit 
einem PowerPC e300c3 Core, der hat eine FPU intus!

Peter schrieb:
> Ja, wegen dem runden.

dann rechne doch anders:

vb = (4000000+(va/2)) / va;

(so in der art - hoffentlich ist kein fehler drin)

>dann rechne doch anders:
>vb = (4000000+(va/2)) / va;
Ob das wirklich schneller ist?

>Dann solltest du aber den Compiler entscheiden lassen, ob er float oder
>double nehmen will.
Wie lasse ich das den Compiler entscheiden?

>Würde mich nicht wundern, wenn float langsamer als double rechnet.
Ich gehe schon davon aus, das ein float (4Byte) schneller ist als ein 
double (8Byte), ist nämlich ein 32Bit System, kein 64Bit!

>Wenn dir Floating Point nichts kostet, dann willst du nämlich um float
>einen Bogen machen, wie der Teufel ums Weihwasser.
Häää...? Was willst Du damit sagen?

Peter schrieb:
> Ob das wirklich schneller ist?

ich denk schon, immerhin fehlt die ganze float int wandlung weg.

>vb = (uint_16_t)(4000000.0 / va - 0.5)

Diese zweite Variante genügt: da der Divident (4000000.0) eine 
Fließkommakonstante ist, wird der Divisor vor der Operation implizit 
ebenfalls in einen Fließkommawert konvertiert. Dann wird die Division 
durchgeführt, 0.5 subtrahiert und dann wegen des explititen casts 
(uint16_t) in eine Ganzzahl konvertiert. Beachte Dabei aber bitte, dass 
explizite casts nicht runden im mathematischen Sinn, sondern nur die 
Nachkommastellen "abschneiden".

Jörg Wunsch schrieb:
> Wenn der Controller die Integerdivision in der Bibliothek machen
> muss, Gleitkomma aber in der FPU, dann stimmt deine Annahme nicht
> mehr.  Selbst, wenn er eine Integerdivision in Hardware hat, wird
> der Unterschied zwischen beiden vernachlässigbar sein, da die
> Umwandlung float/int typischerweise auch in der FPU und damit
> recht schnell passiert.

gibt es wirklich eine CPU die eine FPU hat aber keine hardware division?

Da es sich hierbei eh nur um ein paar takte handelt ist klar das man da 
nicht sehr viel gut machen kann. Aber ich meide aus Prinzip float/double 
wenn ich kann und auch am ende das gleiche rauskommt.

High Performer schrieb:
> Beachte Dabei aber bitte, dass
> explizite casts nicht runden im mathematischen Sinn, sondern nur die
> Nachkommastellen "abschneiden".

aus dem grund rechnet er ja -0.5 dann ist es wieder ein runden.

Jörg Wunsch schrieb:
> Die Umstellung derartiger Rechnungen auf Ganzzahl kann man dann unter
> "Optimierung" verbuchen, getreu dem Motto: "Never start optimizing
> before you have profiled it."

dafür war es bei dem Beispiel eh schon zu spät. Entweder schreibt man

vb = round((float)4000000 / va);

dann ist es genau was man auch haben willt, wenn man es schon umstellt 
kann man gleich auf float verzichten.

Und ja ich mach mir vorher gedanken über mögliche optmierungen, denn 
teilweise beieinflussen sie die Programmlogik.

Ich habe leider keine gelegenheit auf verschienden CPUs zu testen, ich 
bin aber immer noch überzeugt das die int lösung die schnellste ist. Und 
wenn es nur einen Takt ist.

>aus dem grund rechnet er ja -0.5 dann ist es wieder ein runden.

Dachte ich auch kurz, aber: nein, es wird kein Runden draus. Er müsste 
0,5 addieren, nicht subtrahieren. Da er ja nicht geschrieben hat, was 
die Berechnung darstellen soll, hatte ich die -0,5 einfach mal nicht 
kommentiert.

High Performer schrieb:
> Dachte ich auch kurz, aber: nein, es wird kein Runden draus.

dann schein er wohl einen fehler gemacht zu haben, denn er schreibt:

> Ja, wegen dem runden.

Karl Heinz Buchegger schrieb:
> Das du 'float' nicht benutzen willst, weil dich nämlich die Auflösung
> umbringt. Mit Float hast du gerade mal 5 bis 6 signifikante Stellen und
> das ist nicht viel.
Aber nur, wenn die FPU double-precision kann - z.B. der STM32F4 (ein 
Cortex-M4F) kann nur single-precision

Peter II schrieb:
> Peter schrieb:
>> Ob das wirklich schneller ist?
>
> ich denk schon, immerhin fehlt die ganze float int wandlung weg.

Beim Software-Renderer von Quake wurde beim Rendern der Texturen eine 
Perspektivkorrektur durchgeführt (beinhaltet primär eine Division). 
Diese wurde statt in Integer auf der FPU durchgeführt und war dadurch 
quasi kostenlos. Der Grund: Die FPU kann parallel zur CPU rechnen, 
wodurch die Divison gleichzeitig mit den sonstigen Berechnungen der CPU 
ausgeführt werden konnte und somit keine zusätzliche Zeit in Anspruch 
genommen hat. Zugegebenermaßen war dieser Code aber auch von Hand in 
Assembler geschrieben, und die Instruktionen waren genau so angeordnet, 
daß man diesen Umstand möglichst gut nutzen konnte.

Rolf Magnus schrieb:
> Zugegebenermaßen war dieser Code aber auch von Hand in
> Assembler geschrieben, und die Instruktionen waren genau so angeordnet,
> daß man diesen Umstand möglichst gut nutzen konnte.

und vermutlich wurde auch der wert dann weiter als float/double 
behandelt. Hier will er aber vorher und nachher ein int haben.

>dann schein er wohl einen fehler gemacht zu haben, denn er schreibt:
>> Ja, wegen dem runden.
>genauer: 2 Fehler, denn es heißt wegen des Rundens :-)

Die Rechnung ist schon korrekt, die Formel lautet nämlich:
vb = runden((4000000 / va) - 1)

daraus wird:
vb = int((4000000 / va) - 0.5)

Ich verwende nun doch die Integer Berechnung, ich denke dies ist sicher 
nicht langsamer als die Berechnung über float oder double.

vb = (4000000-(va/2)) / va;

Peter schrieb:
> Ich verwende nun doch die Integer Berechnung, ich denke dies ist sicher
> nicht langsamer als die Berechnung über float oder double.

du könntest uns ja mal den asm code für beide varienten posten

Noch was: Ich denke ich muss bei einem 32 Bitter die Konstante nicht mit 
einem Long-Attribute versehen?

vb = int((4000000UL / va) - 0.5)

>vb = int((4000000UL / va) - 0.5)

Das wird nicht funktionieren, da (4000000UL / va) eine Integerdivision 
darstellt. Das wolltest Du doch gerade vermeiden, oder nicht?

High Performer schrieb:
> as wird nicht funktionieren, da (4000000UL / va) eine Integerdivision
> darstellt. Das wolltest Du doch gerade vermeiden, oder nicht?

nein er wollte das runden geschickt gelöst bekommen. Bei einer 
Integerdivision wird ja nicht gerundet und darum wurde versucht es mit 
float zu lösen.

Peter II schrieb:
> High Performer schrieb:
>> as wird nicht funktionieren, da (4000000UL / va) eine Integerdivision
>> darstellt. Das wolltest Du doch gerade vermeiden, oder nicht?
>
> nein er wollte das runden geschickt gelöst bekommen.

Ja eben, und da bringt es nichts, erst eine Integer-Division zu machen 
und danach dann auf float zu erweitern und 0.5 abzuziehen.

> Bei einer Integerdivision wird ja nicht gerundet und darum wurde versucht es mit
> float zu lösen.

Und genau das passiert beim obigen Beispiel nicht, und daher wird das 
nicht wie gewünscht funktionieren.