float ist eh ein Sonderding,
bleib bei double, dann kann das f weg (allerdings muss dann ein d dran ,
sonst wird manchmal int / int = int gerechnet und automatisch gerundet, 3 / 2 = 1)
Auch das hat seinen Sinn! Dadurch wird verhindert, dass du nicht versehentlich Daten verlierst. Angenommen du würdest eine Kommazahl zu einer Ganzzahl hinzuzählen, wäre ja die logische Konsequenz, dass die Kommazahl auch zur Ganzzahl wird und deshalb die Nachkommastellen verliert. Der Compiler macht dich somit darauf aufmerksam, dass es hier zu Datenverlust kommen könnte. Und da ein double mehr Nachkommastellen als ein float haben kann, kann es auch hier zu Datenverlust kommen.
Deshalb musst du in solchen Situationen explizit angeben, dass du auch wirklich diesen Datentyp meinst. Normalerweiße macht man das durch casten. Aber bei Float, Double und Long ist es mögliche eine Kurzform zu verwenden.
Macht also alles Sinn und ist keineswegs eine Ausnahme.
Die Problematik ist mir sehr bewußt. Aber die Antwort ist einfach: Für das, was 90% aller Programmier machen, und woraus 95% des Quellcodes besehen, reicht float oder double. Mir würden aus Ausnahmen nur Finanzinstitute einfallen (die allerdings wohl eher COBOL als Java verwenden, und solche Probleme vmtl. eher mit Binary Coded Digits lösen würden), oder heikle wissenschaftliche Berechnungen, die aber (wenn es nicht gerade nur um einen Taschenrechner geht) "oft" zeitrkitisch sind, und BigDecimal ist SO ineffizient, dass sich jeder, der sowas braucht, C++ verwenden oder sich dafür eine eigene Klasse schreiben oder sich zumindest auf andere (effizientere) Bibliotheken stützen würden.
Saxony hat gesagt.:
Hiho,
Code:
String s = "string";
// ist das selbe wie
String s = new String("string");
Das ist nichtmal das gleiche :wink: Beim ersten wird ein String aus dem internen pool verwendet, beim zweiten wird explizit eine neue String-Instanz erstellt.
Ich habe in den letzten Projekten eigentlich immer BigDecimal verwendet einfach nur um dieser Problematik aus dem Weg zu gehen. Dabei ging es nichtmal um hochwissenschaftliche Berechnungen sondern um ganz simple Preisdaten und einfache Berechnungen.
Wenn schon nicht jeder Entwickler diese Problematik intus hat, wie soll man dass dann einem aus der Fachabteilung erklären warum 24.4 + 3.9 nicht wie erwartet 28.3, sondern 28.299999999999997 ist. Wenn man dann versucht das Problem zu erklären muss man zwangsläufig technisch werden. Und da steigt ein nicht-Techniker meistens aus. Eigentlich interessiert es ihn auch gar nicht. Darum ist es auch, wie ich finde, legitim, für jede sch... Berechnung BigDecimal zu verwenden. Das sind zumindest meine Erfahrungen.
Wenn du so an die Sache rangehst, das du Zahlen zur Berechnung verwendest die um viele Faktoren langsamer sind und ein vielfaches an Speicher fressen, nur um zu vermeiden ein wenig denken zu müssen, braucht man sich nicht wundern wenn Java oft als langsam verschrien wird.
Wenn du so an die Sache rangehst, das du Zahlen zur Berechnung verwendest die um viele Faktoren langsamer sind und ein vielfaches an Speicher fressen, nur um zu vermeiden ein wenig denken zu müssen, braucht man sich nicht wundern wenn Java oft als langsam verschrien wird.
Und was spricht bitte gegen das Runden von primitiven Gleikommezahlen?
Vor allem im finanztechnischen Bereich reicht für die ANZEIGE meist eine Rundung auf 2-4 Nachkommastellen. Weil sich niemand in einer Tabelle solche Werte anguggen will: 2,45454545 EUR.
Da reicht 2,45 für die Anzeige, aber halt intern nicht vergessen weiterhin mit 2,45454545 zu rechnen.
Wie schon mal in einem anderen Thread erwähnt, habe ich ja für die VersicherungskammerBayern an einer Gebäudeversicherungssoftware mitgearbeitet.
Dort war der Tarifrechner aber so komplex (im Pflichtenheft eine Berechnung, erklärt auf knapp 300 Seiten ), das die Genauigkeit von double nicht mehr ausgereicht hat, da es am Ende zu Differenzen im 1/10 Cent Bereich kam. Hier war also die Verwendung von BigDecimal Pflicht.
Mh, das Problem hatte ich mit einer ganz simplen Preis-Addition in einem Online-Shop auch schon mal... Da habe ich auch mit double gearbeitet und nur für die Anzeige gerundet und am Ende hatte ich eine Differenz von einem Cent. Weiß die Details nicht mehr (bin schon lange raus aus der Firma), aber das war eine ziemliche Scheiße .
Ende vom Lied war: Keine Zeit, kein Budget - nimm BigDecimal und machs fertig ...
Wenn du so an die Sache rangehst, das du Zahlen zur Berechnung verwendest die um viele Faktoren langsamer sind und ein vielfaches an Speicher fressen, nur um zu vermeiden ein wenig denken zu müssen, braucht man sich nicht wundern wenn Java oft als langsam verschrien wird.
