Wie funktioniert Konvertierung von double zu int?

Wie könnte jemand als Programmierer mit seiner Arbeit Geld verdienen, wenn er nicht über die grundlegenden Datentypen, deren Einsatz, und der wie bei Geldbeträgen vorhandenen Problematik nicht bescheid wüsste?

Das Frage ich mich bei dir auch. Wie man die Problematik bei Geldbeträgen löst, wurde hier schon mehrmals gesagt - und nein: double und float einzusetzen ist nicht die Lösung.

Mach mal eine technische oder wissenschaftlich Berechnung mit int statt float.

Liest du eigentlich die Posts der anderen? Es geht nicht um technische/wissenschaftliche Berechnung, sondern um finanzielle Berechnungen. Und gerade bei solchen Berechnungen darf die inhärente Ungenauigkeit von float und double nicht in einfach in Kauf genommen werden.

Michael E.

Th69 schrieb:

float x = 0;
while(x != x+1)
{
}

cout << x << endl;
Wetten, daß das keine Endlosschleife ist?

Die Wette gehe ich gerne ein: Erstens erhöhst du x nicht und zweitens vergleichst du ohne eps.

Aber prinzipiell hast du Recht:

#include <iostream>
#include <iomanip>
using namespace std;

int main()
{
	float x = 16777216;
	cout << sizeof(x) << "; " << setprecision(20) << x << "; " << x + 1;
}

Ausgabe bei mir:
4; 16777216; 16777216

Was für ein Zufall, dass das 2^24 ist

asc

berniebutt schrieb:

Ach so, was machst du bei Zins- oder Mehrwertsteuer-Berechnungen mit den Anteilen hinter dem Cent? Wegschmeissen oder geschickt in die eigene Tasche stecken?

Einige Sprachen und Bibliotheken bieten nicht ohne Grund Währungstypen (Fixkommazahlen) an. float und double ist in allen ernsthaften Anwendungen in denen es um Geld geht, und in denen viele Berechnungen statt finden ungeeignet.

Ganz davon abgesehen das im Bankenwesen durchaus nicht nur mit Centbeträgen gerechnet wird, sondern dafür exakte Vorschriften gibt mit welchen Genauigkeiten etc. zu arbeiten ist, wie bei Berechnungen zu runden ist, wie Umrechnungsungenauigkeiten gebucht werden... Und auch Datenbanken arbeiten in der Regel nicht bei Währungen mit Fließkommazahlen - und das aus sehr guten Gründen.

SeppJ

berniebutt schrieb:

In der Sprache der Mathematiker: natürliche Zahlen (0,1,2,3, ...) und reelle Zahlen. Den Unterschied lernt man doch schon in der Schule oder heute nicht mehr? Die reellen Zahlen heissen in der Schule manchmal Bruchzahlen, wenn ich mich recht erinnere.

Wie könnte jemand als Programmierer mit seiner Arbeit Geld verdienen, wenn er nicht über die grundlegenden Datentypen, deren Einsatz, und der wie bei Geldbeträgen vorhandenen Problematik nicht bescheid wüsste?

Mach mal eine technische oder wissenschaftlich Berechnung mit int statt float. Da fliegst du schnell allein mit dem darstellbaren Wertebereich auf die Schnauze! Ach so, was machst du bei Zins- oder Mehrwertsteuer-Berechnungen mit den Anteilen hinter dem Cent? Wegschmeissen oder geschickt in die eigene Tasche stecken?

Tut mir leid, du willst hier mit vermeintlichen Wissen glänzen, machst dich aber nur lächerlich. Wenn dir die Begrifflichkeit Kontinuum vs Diskret nichts sagt, dann ist dies eine Bildungslücke deinerseits. Und was du über wissenschaftliche Rechnungen verzapfst ist ebenfalls kompletter Blödsinn. Zufällig verdiene ich mein Geld damit und kenne mich ein wenig mit dem Thema aus. Viele Kollegen rechnen mit Ganzzahlen und dies ist vollkommen in Ordnung, wenn das Modell entsprechend aussieht. Wie schon gesagt, geht es bei double vs. int nicht um Genauigkeit sondern um die richtige Modellierung des Problems.

berniebutt

@SeppJ

Danke für die freundlichen Belehrungen! Ich kenne mich da schon aus, sonst hätte ich nicht viele Jahre erfolgreich mit eigenen Mitarbeitern mein Geld sowohl für technisch-wissenschaftliche wie kaufmännische Anwendungen verdienen können. Soll ich den Kunden das Geld etwa zurückgeben - sie waren doch voll zufrieden?

Nun war es aber einmal so, dass es sinnvoll nur FORTRAN und einige andere Compilersprachen gegeben hatte. Da gab es dann für Zahlenwerte nur int (INTEGER) und float (REAL), C und C++ kamen später hinzu. Also hatten wir einen ganzen Sack eigener Funktionen in der Werkzeugkiste, was heutige Compiler an dieser Stelle zusätzlich anbieten. Ist auch gut so, denn jeder Fortschritt ist willkommen!

Nun löst das aber alles nicht das hier nachgefragte Problem. Der Fragesteller hat eben durch Vorarbeiten vor 20 Jahren double für Geldwerte und will damit weiter leben! Soll er alles aufwendig umschreiben oder völlig neu machen?

daddeldu! :p

Ändert nichts daran, dass du folgendes geschrieben hast:

Fliesskommazahlen (float, double, ...) sind nun einmal viel genauer als Ganzzahlen (int, ...)

Dass diese Aussage nicht zutrifft, wurde dir auf den letzten Seiten dargelegt, allerdings ohne jegliche Einsicht deinerseits.

daddeldu! :p (Wie dämlich ist das denn?)

Michael E.

Nun war es aber einmal so, dass es sinnvoll nur FORTRAN und einige andere Compilersprachen gegeben hatte. Da gab es dann für Zahlenwerte nur int (INTEGER) und float (REAL), C und C++ kamen später hinzu. Also hatten wir einen ganzen Sack eigener Funktionen in der Werkzeugkiste, was heutige Compiler an dieser Stelle zusätzlich anbieten. Ist auch gut so, denn jeder Fortschritt ist willkommen!

Welche Funktionen? Compiler? Dass man für Finanzen keine Fließkommazahlen nehmen soll, gilt sowohl in Fortran als auch in C und C++.

Der Fragesteller hat eben durch Vorarbeiten vor 20 Jahren double für Geldwerte und will damit weiter leben!

Für mich hört sich das etwas anders an:

Belli schrieb:

Deshalb will ich jeden einzelnen Betrag erst Mal in einen Integer - Wert konvertieren

berniebutt

Michael E. schrieb:

Welche Funktionen? Compiler? Dass man für Finanzen keine Fließkommazahlen nehmen soll, gilt sowohl in Fortran als auch in C und C++.

- Funktionen: Eigene Funktionen oder Firmware
- Compiler: So gut wie alle Compiler
- Einsatz von Fliesskomma für Finanzen: zunächst nein, bei Beherrschung der Materie jedoch ja

Gewöhnlich - so auch ich - setzt man für Finanzprojekte keine Fliesskommazahlen ein!

Michael E.

Welche Funktionen?

Einsatz von Fliesskomma für Finanzen: zunächst nein, bei Beherrschung der Materie jedoch ja

Was soll denn jetzt dieser letzte Teilsatz bedeuten? Wenn man um die Nachteile der Fließkommazahlen weiß, dann wird man sie doch wohl nicht einsetzen - vor allem wenn es heutzutage bessere Alternativen gibt.

Belli

berniebutt schrieb:

Nun war es aber einmal so, dass es sinnvoll nur FORTRAN und einige andere Compilersprachen gegeben hatte. Da gab es dann für Zahlenwerte nur int (INTEGER) und float (REAL)

In die Zeit von FORTRAN gehört wohl auch die Sprache COBOL. Und dort gibt es sehr wohl einen für den Umgang mit Geld/Währungen passenden Datentyp.

berniebutt

Belli schrieb:

In die Zeit von FORTRAN gehört wohl auch die Sprache COBOL. Und dort gibt es sehr wohl einen für den Umgang mit Geld/Währungen passenden Datentyp.

Ja, FORTRAN vs. COBOL war so eine eigene Sache - man mochte sich gegenseitig nicht besonders! Das lag aber eher an COBOL. Die FORTRAN-Leute sind nahezu alle auf C und C++ umgestiegen. Man fand dort - wie ich - alles wieder und bekam neue nützliche Möglichkeiten hinzu.

Den geeigneten Datentyp für Geld/Währungen gibt es in ANSI-C und auch in C++ nicht oder noch nicht. Man muss diese spezielle Aufgabe entweder auf angebotene Funktionen des Compilers übertragen oder dafür eigene Funktionen einsetzen.

hustbaer

Früher hat man AFAIK bei Geld mit BCD gerechnet, heute verwendet man vermutlich öfter 64+ Bit Integers mit Scaling (z.B. 100 oder 10000).

Dass man in FORTRAN bei Geld mit floats gerechnet hat höre/lese ich zum ersten mal. Klar werden das Leute gemacht haben, aber es war auch damals schon sehr verpönt.

----

Die eigentliche Frage des OP wurde ja glaube ich schon beantwortet? Falls nicht bzw. nicht "genügend":

double dval = ...;
long long llval_fp100; // geht natürlich genau so mit long/int/short/...
if (dval >= 0)
    llval_fp100 = static_cast<long long>((dval * 100.0) + 0.5);
else
    llval_fp100 = static_cast<long long>((dval * 100.0) - 0.5);