Großer Java bug beim rechnen?

[Bug?]

Also entweder ich kann nicht mehr rechnen oder java kanns nicht

hier mein code:

(testet vorher mal mit nem taschenrechner was rauskommt^^)

public class test4 {

	public static void main(String[] args) {
		// TODO Auto-generated method stub
	double lol ;
	lol=16.6;
	lol=lol+3.9;
	lol=lol+3.9;
	lol=lol+3.9;
	System.out.print(lol);
	

	}

}

Beim normalen Taschenrecher kommt 28,3 raus was ja auch richtig ist. nur das java progrmam zeigt mir ne Periodische Zahl an. Bug oder?

 

[sparrow]

äähm falsch ^^ ich werde bezahlt um mit java zu programmieren

... ohne Wort ....

 

[Gast]

achso ^^ du wolltest doch noch wissen was ich mit ausnhamen meine.

nur zum bleistift dass hinter die 3,9 jetzt n F muss usw ^^, fällt wahrscheinlich einem der nut mit java schafft nicht auf.

Mir als alter basicer fällt es doch sehr schwer sich durch die unendlichen weiten des java zu wühlen .



( ui das hab ich aber schön gesagt ^^)

 

[SlaterB]

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)

 

[Gast]

okay dann bleib ich bei double

danke

 

[SlaterB]

hoffentlich hast du noch gelesen was ich noch als Klammer raneditiert habe

 

[The_S]

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.

 

[Saxony]

Hiho,

zudem habe ich schon 2 Seiten weiter vorne eine Lösung zum runden auf zwei stellen geposted.

Und meine Hinweise zum Sexagesimalsystem hat auch niemand beachtet. :lol:

bye Saxony

 

[tfa]

äähm falsch ^^ ich werde bezahlt um mit java zu programmieren

... ohne Wort ....

Wahrscheinlich in Handy-Klingeltönen...

 

[Marco13]

@Marco13
Was soll den deiner Meinung nach verwendet werden, wenn nicht BigDecimal?

Hier übrigens ein Beitrag, der die Problematik ein wenig erläutert.

ms

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.

Hiho,

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.

 

[Saxony]

Schon klar , nur für mich als Entwickler ergeben sich in der weiteren Verwendung von s keine Unterschiede.

Zudem sollte es auch nur zeigen, dass String somit eine Klasse ist, da man davon Instanzen mittels new erzeugen kann.

bye Saxony

 

[ms]

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.

ms

 

[Wildcard]

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.

 

[Saxony]

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.

Richtig.

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.

bye Saxony

 

[Tobias]

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 ...

mpG
Tobias

 

[Saxony]

Hiho,

kann man eigentlich nicht auch nen long für vor dem Komma und einmal long für nach dem Komma nehmen ?

bye Saxony

 

[SlaterB]

oder nur ein long und immer berücksichtigen, dass die letzten beiden Ziffern nach dem Komma stehen,
also in ganzen Cents rechnen

 

[ms]

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.

In diesem Fall hat das niemanden interessiert.

Ende vom Lied war: Keine Zeit, kein Budget - nimm BigDecimal und machs fertig ...

So wie es aussieht bin ich nicht der einzige dem es so geht.

ms