Konvertierung von double in integer

[Felix E. (felix1601)]

Hallo,

ich denke mein Anliegen ist klar, ich habe leider bis jetzt nichts im 
www gefunden, vielleicht kann mir hier jemand helfen?

[Irgendwer (Gast)]

In welcher Programiersprache?
Einfach abschneiden oder genau gerundet?

double x = 12343.456;
int x = (int)y;

[Felix E. (felix1601)]

Irgendwer schrieb:
> In welcher Programiersprache?
> Einfach abschneiden oder genau gerundet?
>
> double x = 12343.456;
> int x = (int)y;

Programmiere einen ESP8266 also arduino basiert
Sollte genau gerundet sein!
Geht das mit der Funktion so einfach?

das y sollte ein x sein oder?

[Axel S. (a-za-z0-9)]

Felix E. schrieb:
> ich denke mein Anliegen ist klar, ich habe leider bis jetzt nichts im
> www gefunden

Dann kannst du das (das Suchen) also auch nicht?

floor(), trunc() oder round() aus der mathlib tun das. Je nachdem 
welches Verhalten du genau möchtest.

[Rufus Τ. F. (rufus)]

Felix E. schrieb:
> Programmiere einen ESP8266 also arduino basiert

"Also"? Den könnte man auch mit irgendwas anderem programmieren.

Wie auch immer, es geht also um C++.


> Sollte genau gerundet sein!

Dann vor dem Typecast 0.5 addieren.

Der Typecast schneidet ab.

double x = 1234.56;

int y = x;

int z = x  + 0.5;

printf("y = %d  z = %d\n", y, z);

Resultat:

y = 1234  z = 1235

[Markus F. (mfro)]

So rundet da nix, da wird bloß abgeschnitten.

So geht's richtig:

    double x;

    int a = (x > 0.0 ? (int) (x + 0.5) : (int) (x - 0.5));

[Dirk B. (dirkb2)]

z.B mit der Funktion round

http://www.cplusplus.com/reference/cmath/round/

[Rufus Τ. F. (rufus)]

Markus hat natürlich den Nagel auf den Kopf getroffen - "mein" 
Rundungsansatz versagt bei negativen Zahlen.

[Felix E. (felix1601)]

Markus F. schrieb:
> So rundet da nix, da wird bloß abgeschnitten.
>
> So geht's richtig:
>
>

>     double x;
> 
>     int a = (x > 0.0 ? (int) (x + 0.5) : (int) (x - 0.5));
>

Dankeschön!

Auch für alle anderen Antworten!

[Tim T. (tim_taylor)]

Markus F. schrieb:
> So rundet da nix, da wird bloß abgeschnitten.
>
> So geht's richtig:
>
>

>     double x;
> 
>     int a = (x > 0.0 ? (int) (x + 0.5) : (int) (x - 0.5));
>

Wofür der explizite Typecast auf int?

 int a = (x > 0.0 ? (x + 0.5) : (x - 0.5));

Funktioniert genausogut.

[W.S. (Gast)]

Felix E. schrieb:
> ich denke mein Anliegen ist klar,

Nein, dein Anliegen ist durchaus nicht klar. Wozu ein double bemühen, 
wenn man's anschließend auf einen int herunterbrechen will?

Also, wenn man PI so rundet, dann fällt man weit hinter die alten 
Ägypter zurück, die konnten das schon besser als nur 3.

Und was wird aus 1.735E37 werden?

Also, erstmal glaube ich nicht, daß man für solche Feld-Wald-Wiese 
ausgerechnet double braucht, das rechnet sowieso kaum ein billiger µC in 
Hardware (ob der ESP8266 das etwa in HW kann?) und zweitens wäre dann 
allenfalls ein int64 oder notfalls ein long angesagt.

Besser für Meßzwecke wäre es allerdings, einfach float als single zu 
nehmen und dann auch in float zu bleiben.

Also: wozu soll's denn gut sein?

W.S.

[Sebastian S. (amateur)]

Eine sehr interessante Formulierung;)

>Sollte genau gerundet sein!

[Axel S. (a-za-z0-9)]

Markus F. schrieb:
> So rundet da nix, da wird bloß abgeschnitten.
>
> So geht's richtig:
>
>

>     double x;
> 
>     int a = (x > 0.0 ? (int) (x + 0.5) : (int) (x - 0.5));
>

Gibt es einen tieferen Grund, warum hier alle das Rad neu erfinden? Die 
Funktion round() aus der libm existiert, ist standardisiert und tut 
exakt das verlangte. Im Zweifelsfall ist sie auch effizienter als 
jedes Eigengewächs.

[Felix E. (felix1601)]

W.S. schrieb:
> Also: wozu soll's denn gut sein?

Daten eines MPU6050 werden erfasst und umgerechnet auf grad bzw. auch 
ein komplementärfilter verwendet um das driften zu minimieren. Nun 
möchte ich die entgültigen beschleunigungsdaten in int umwandeln um sie 
danach über mqtt zu publishen, und eben die kommastellen beim empfänger 
nicht mehr benötige und das dann nur unnötig genaue daten wären, jedoch 
brauche ich für die berechnungen die kommastellen um das ergebnis so 
genau wie möglich zu halten

[Yalu X. (yalu) (Moderator)]

Axel S. schrieb:
> Gibt es einen tieferen Grund, warum hier alle das Rad neu erfinden? Die
> Funktion round() aus der libm existiert, ist standardisiert und tut
> exakt das verlangte.

Ich verstehe auch nicht, warum deine beiden Beiträge (und anfangs auch
Dirks Beitrag) abgewertet worden sind. Noch besser als round ist in
diesem Fall nur lround, da dieses die Konvertierung nach long bzw. int
(was auf dem ESP8266 dasselbe ist) bereits integriert hat, was die
Funktion evtl. noch etwas schneller macht.

Also:

  a = lround(x);

[Axel S. (a-za-z0-9)]

Yalu X. schrieb:
> Axel S. schrieb:
>> Gibt es einen tieferen Grund, warum hier alle das Rad neu erfinden? Die
>> Funktion round() aus der libm existiert, ist standardisiert und tut
>> exakt das verlangte.
>
> Ich verstehe auch nicht, warum deine beiden Beiträge (und anfangs auch
> Dirks Beitrag) abgewertet worden sind.

Haha. Dirk habe ich wieder auf 0 hoch gevotet.

Sind wohl zuviele Kasper mit Accounts (und deswegen dem Recht zu voten) 
unterwegs. Wenn ich daran denke daß das womöglich die Menschen sind die 
übernehmen, wenn ich mal in Rente gehe, dann wird mir ganz anders.

[Markus F. (mfro)]

Axel S. schrieb:
> Gibt es einen tieferen Grund, warum hier alle das Rad neu erfinden? Die
> Funktion round() aus der libm existiert, ist standardisiert und tut
> exakt das verlangte.

Natürlich kann man auch round() verwenden. Und sollte das auch tun, wenn 
man sowieso die libm einbinden muß.

Wenn ich aber nur eine einzige Zeile brauche, um ganz ohne Library klar 
und verständlich hinzuschreiben, was ich will, dann spare ich mir das. 
Der Compiler kann (ohne LTO-"Tricks") inlinen und im besten Fall spare 
ich einen Funktionsaufruf.

Kann jeder halten, wie er will. Jetzt weiß der TO hoffentlich 
wenigstens, was round() tut.

[Dr. Sommer (Gast)]

Markus F. schrieb:
> klar und verständlich hinzuschreiben, was ich will, dann spare ich mir
> das.

Du findest also so eine Formel verständlicher als "round"? Jeder 
Programmierer, der round sieht, weiß sofort was gemeint ist. Eine Formel 
zu entschlüsseln dauert auf jeden Fall länger.

[H.Joachim S. (crazyhorse)]

Yalu X. schrieb:
> Ich verstehe auch nicht, warum deine beiden Beiträge (und anfangs auch
> Dirks Beitrag) abgewertet worden sind.

Vielleicht weil die ganze "Bewerterei" von Hause aus Nonsens ist? Sie 
hat oft nur wenig mit der fachlichen Qualität zu tun, sondern ist ein 
Spielplatz für persönliche Befindlichkeiten oder kleine Rachegelüste.

[Markus F. (mfro)]

Dr. Sommer schrieb:
> Du findest also so eine Formel verständlicher als "round"? Jeder
> Programmierer, der round sieht, weiß sofort was gemeint ist. Eine Formel
> zu entschlüsseln dauert auf jeden Fall länger.

Wenn's dir gut tut, hast Du recht.

Darüber auch nur eine Minute länger nachzudenken ist m.E. Verschwendung 
von kostbarer Lebenszeit.

[Dr. Sommer (Gast)]

Aha... der Aufwand für den Funktionsaufruf dürfte sowieso klein sein 
gegenüber dem für die Rundung selbst.

[A. S. (Gast)]

Round liefert keinen Integer zurück.

Und dann muss man erstmal recherchieren, ob man wirklich sicher sein 
kann, dass die Konvertierung danach klappt.

[Dr. Sommer (Gast)]

0.5 addieren/subtrahieren und nach int casten kann genau so gut einen 
Over/Under-Flow produzieren.

[Axel S. (a-za-z0-9)]

Markus F. schrieb:
> Axel S. schrieb:
>> Gibt es einen tieferen Grund, warum hier alle das Rad neu erfinden? Die
>> Funktion round() aus der libm existiert, ist standardisiert und tut
>> exakt das verlangte.
>
> Natürlich kann man auch round() verwenden. Und sollte das auch tun, wenn
> man sowieso die libm einbinden muß.

Warum diese Einschränkung? Gibt es Geld zurück für die Nichtverwendung 
von Bibliotheksfunktionen?

Zum zweiten Punkt hat Dr. Sommer sich ja schon geäußert:

Dr. Sommer schrieb:
> Markus F. schrieb:
>> klar und verständlich hinzuschreiben, was ich will, dann spare ich mir
>> das.
>
> Du findest also so eine Formel verständlicher als "round"? Jeder
> Programmierer, der round sieht, weiß sofort was gemeint ist. Eine Formel
> zu entschlüsseln dauert auf jeden Fall länger.

Wahrscheinlich stopft er das dann selber in eine Funktion und nennt sie 
my_round() (weil nur round() geht ja nicht, da könnte es zu Konflikten 
kommen, falls libm für was anderes dazugelinkt wird)

[Yalu X. (yalu) (Moderator)]

Markus F. schrieb:
> Wenn ich aber nur eine einzige Zeile brauche, um ganz ohne Library klar
> und verständlich hinzuschreiben, was ich will, dann spare ich mir das.
> Der Compiler kann (ohne LTO-"Tricks") inlinen und im besten Fall spare
> ich einen Funktionsaufruf.

Auf einem Prozessor ohne FPU wie dem ESP8266 benötigt

(int)(x>0.0 ? x+0.5 : x-0.5)

3 direkte Funktionsaufrufe (Vergleich, Addition/Subtraktion und Cast),

(int)round(x)

2 direkte Funktionsaufrufe (round und Cast) und

lround(x)

1 direkten Funktionsaufruf (lround).

Es sind aber nicht nur die Funktionsaufrufe selbst, an denen Zeit
gespart werden kann. Man kann davon ausgehen, dass die aufgerufenen
FP-Funktionen intern auf Assembler-Ebene sehr gut auf ihre jeweilige
Aufgabe hin optimiert sind. Je spezifischer diese Aufgabe ist, umso
besser ist i.Allg. auch die Optimierung. So muss bspw. in round nicht
nach positivem oder negativen Vorzeichen unterschieden werden, da in der
internen Darstellung die FP-Zahl bereits getrennt nach Betrag und
Vorzeichen vorliegt. In lround muss auch nicht explizit nach int bzw.
long gecastet werden, da das in einem Aufwasch mit der Bestimmung des
ganzzahligen Anteils erfolgen kann.

Somit dürfte die zweite Variante deutlich schneller als die erste und
die dritte deutlich schneller als die zweite sein.

Vielleicht hat ja jemand Lust, die Laufzeiten der drei Varianten auf
einem ESP8266 zu messen.