Verständnisfrage Genauigkeit

[HStev]

Hallo,

ich weiß das Thema wird hier oft durchgekaut aber in keinen Thread wird die Frage wirklich zufriedentstellend beantwortet.

Ich hab zb. folgende Klasse:

public class test {
	public static void main(String[] args) {
		double a,b;
		
		a = 1.6;
		b = 0.5;
		System.out.println(a - b);
		
		a = 1.6;
		b = 1.0;
		System.out.println(a - b);
		
		a = 1.6;
		b = 1.5;
		System.out.println(a - b);
	}
}

Die Ausgabe davon ist:

1.1
0.6000000000000001
0.10000000000000009

Warum fällt bei den letzten die Genauigkeit so aus dem Rahmen und nicht auch bei der 1. Berechnung?
Kann man das irgendwie abfangen?

 

[bygones]

warum nutzt keiner unsere Forensuche

http://www.java-forum.org/de/viewtopic.php?t=4723&highlight=rechnen+ungenauigkeit
http://www.java-forum.org/de/viewtopic.php?t=1188&highlight=rechnen+ungenauigkeit

 

[HStev]

aber in keinen Thread wird die Frage wirklich zufriedentstellend beantwortet.

miss ich etwa jede klitzekleine Berechnung selbst runden?

Warum gibt es für Runden eigentlich keine fertige Klasse/Function?

 

[bygones]

aber in keinen Thread wird die Frage wirklich zufriedentstellend beantwortet.

miss ich etwa jede klitzekleine Berechnung selbst runden?

Warum gibt es für Runden eigentlich keine fertige Klasse/Function?

Api gucken hilft.

Math Klasse bzw. die Formatter oder auch NumberFormats

 

[meez]

Das kommt, weil man Floatingzahlen nicht immer in bit ausdrücken kann...Daher kommt es zu kleinen Rundungsfehler...
0.1 ist speziell ein Problem...

Hier ein wenig Lektüre:
http://www-128.ibm.com/developerworks/java/library/j-jtp0114/
http://grouper.ieee.org/groups/754/

 

[HStev]

Die Frage die sich mir dabei stellt woher weiß ich immer wieviele Nachkommastellen meine Berechnungen ergibt klar bei Plus/Minus kann ich es voraussagen aber ansonsten?

 

[HStev]

Sorry das ich jetzt einen total banalen Vergleich bringe aber es geht ums Prinzip:

Ich hab 2 Quelltexte einmal PHP und einmal Java:

Beide sollen einfach nur 1.66564 - 1.55463 rechnen.

<?php
$a = 1.66564;
$b = 1.55463;

echo $a - $b;
?>

Ausgabe:

0.11101

import java.text.*;

public class test {
	public static void main(String[] args) {
		double a,b;
		NumberFormat nf = NumberFormat.getInstance();
		
		a = 1.66564;
		b = 1.55463;
		System.out.println(a - b);
		System.out.println(nf.format(a - b));
			
	}
}

Ausgabe:

0.11101000000000005
0.111

Selbst der Taschenrechner von Windows liefert mir das richtige Ergebnis... sorry das ist zwar alles schön und gut aber warum bekommt man das mit Java nicht genauso hin?

 

[Ilja]

weil java kein taschenrechner ist -.-

ein taschenrechner rundet es intern auch, bevor es angezeitg wird!
gleiches trifft auf php zu...

 

[Bleiglanz]

php unterschlägt eben die Details, damit die Benutzer immer schön zufrieden sind

und das "Prinzip" ist ganz einfach

0.1 = a_1 * (1/2) + a_2 *(1/4) + a_3 * (1/8) + a_4 * (1/16) + ...

wenn du das mit endlich vielen a_i (die alle 0 oder 1 sind) lösen kannst, dann wirst du das auch mit Java genauso hinbekommen

 

[HStev]

Wie kann man damit vernünftig arbeiten?
Sorry aber genau das hat mich bisher immer daran gehindert mit Java mehr zu machen.
Ich find das ist einfach sch... wenn ich bei komplizierteren Berechnung erst prüfen muss obs nicht ein interner Rundungsfehler ist. Das mag zwar von der Computer-Architektur her vollkommen logisch zu sein das da ein Rundungsfehler auftaucht aber es wird mich wahrscheinlich auch weiterhin davon abhalten in Java mehr zu machen wenn es dafür keine "vernünftige" Lösung gibt.

 

[Illuvatar]

Das hat nichts mit Java zu tun. Es ist nur so, dass die Ausgabemethoden von vielen anderen Sprachen automatisch runden. Das kannst du in Java auch machen. Aber in von alle (normal gebräuchlichen (Java C# C++ Delphi Bla)) Sprachen erzeugten Programmen werden Fließkommazahlen so dargestellt, dass es nun mal ungenau ist.

 

[HStev]

Es ist nur so, dass die Ausgabemethoden von vielen anderen Sprachen automatisch runden. Das kannst du in Java auch machen.

Und warum gibt es dafür keine Klasse in Java? Die NumberFormat rundet ja eine "entscheidende" einfach weg.

 

[Illuvatar]

Du kannst NumberFormat ja sagen, wie es runden soll ???:L

 

[HStev]

Die Frage die sich mir dabei stellt woher weiß ich immer wieviele Nachkommastellen meine Berechnungen ergibt klar bei Plus/Minus kann ich es voraussagen aber ansonsten?

nur mal als Beispiel wenn ich mir überlege einen Taschenrechner zu programmieren ... na klasse n Taschenrechner der ne stelle verschluckt :bloed:

 

[byte]

Also ich verstehe das Problem nicht. Du kannst doch dem NumberFormat die gewünschte Genauigkeit mitteilen und hast dann das gewünschte Ergebnis.

NumberFormat nf = NumberFormat.getInstance();
nf.setMaximumFractionDigits(10);

double a = 1.66564;
double b = 1.55463;

System.out.println(a - b);               // 0.11101000000000005
System.out.println(nf.format(a - b));    // 0,11101

 

[Sky]

Wie kann man damit vernünftig arbeiten?
Sorry aber genau das hat mich bisher immer daran gehindert mit Java mehr zu machen.
Ich find das ist einfach sch... wenn ich bei komplizierteren Berechnung erst prüfen muss obs nicht ein interner Rundungsfehler ist. Das mag zwar von der Computer-Architektur her vollkommen logisch zu sein das da ein Rundungsfehler auftaucht aber es wird mich wahrscheinlich auch weiterhin davon abhalten in Java mehr zu machen wenn es dafür keine "vernünftige" Lösung gibt.

Damit ist der Thread doch eigentlich schon beendet.
Du hast Dich entschieden, deine Probleme auf eine andere Art zu lösen.

 

[Bleiglanz]

Wie kann man damit vernünftig arbeiten?

scheinbar neu in der Computer-Welt?

Wem das nicht passt, für den gibts in Java BigInteger und BigDecimal, beim Rechnen mit Währungen ist das sogar "üblich"

Sorry aber genau das hat mich bisher immer daran gehindert mit Java mehr zu machen.

Dann bleib bei Smalltalk, Lisp, Maple oder dem genialen System mit dem du bisher gearbeitet hast

In C C++ VB.NET C# Delphi PHP Perl sind diese bösen Effekte jedenfalls standardmässig eingebaut

 

[stev.glasow]

*rufRette*
Ich bin weder stev noch hstev. Hatte stev gebeten seinen Nick zu ändern, nun heißt er hstev :?

@topic: :roll:

 

[HStev]

@stevq stevq u. HStev sehehn doch vollkommen anders aus und hören sich auch anders das einzigst gemeinsame ist das stev ... aber wenn man sonst keine Probleme hat...

Die Lösungen sind zwar schön und gut aber wie soll man damit Vergleiche anstellen. Sorry wenn ich nerve ich wills nur endlich mal kapieren warum das in in Java so kompliziert ist.

import java.text.*;

public class test {
	public static void main(String[] args) {
		double a,b,c,d;
		NumberFormat nf = NumberFormat.getInstance();
		
		a = 4.66;
		b = 1.55;
		c = 1.44;
		d = 1.33;
		
		double erg = a - b - c - d;
		
		if (erg == 0.34)
		{
			System.out.println("Stimmt 1");
		}
		
		if(nf.format(erg) == "0.34")
		{
			System.out.println("Stimmt 2");
		}
		
		System.out.println(a - b - c - d);
		System.out.println(nf.format(a - b - c -d));	
	}
}

Ausgabe:

0.3400000000000003
0.34

 

[Bleiglanz]

du sollst in KEINER Programmiersprache jemals doubles oder floats auf gleichheit testen

if(Math.abs(a-b) < 0.0000001){

}

wobei man die Genauigkeit eben nach Aufgabenstellung einstellt

das ist die EINZIGE Möglichkeit

 

[stev.glasow]

Wieso rundest du erg nicht einfach?

 

[HStev]

du sollst in KEINER Programmiersprache jemals doubles oder floats auf gleichheit testen

Das wäre mir ganz neu aber nun gut, damit wäre meine Frage beantwortet. danke!

 

[norman]

public int java.lang.Double.compareTo(Double anotherDouble)
Returns:
the value 0 if anotherDouble is numerically equal to this Double; a value less than 0 if this Double is numerically less than anotherDouble; and a value greater than 0 if this Double is numerically greater than anotherDouble.

funktioniert folglich auch nicht?

 

[HStev]

habs grad getestet trifft auf jeden Wert zu der kleiner ist

 

[Bleiglanz]

Nein

 

[norman]

warum wird darauf in der API nicht hingewiesen? oder verstehe ich "numerically" falsch?
bzw. wozu nützt diese Methode dann?

 

[HStev]

Vielleicht sollte man diesen Thread Sticky machen hier im Anfängerforum.

 

[stev.glasow]

Ne, las mal. Das Thema an sich wär mal was für die FAQ aber nicht dieser Thread.

 

[HStev]

Naja ich mein ja nur weil das mit der Genauigkeit war mir nie so klar ... ansonsten der Rest Design Patterns, OOP, RegEx und was es da sonst noch gibt ist soweit klar...und ich denke wie mir wird es vielen anderen auch gehen.

 

[stev.glasow]

jo. hast Recht.

 

[bygones]

trotzdem ist es unsinnig diesen Thread als sticky für Informationsgewinn zu machen. Dafür ist er zu unstrukturiert - wenn dann einen schönen FAQ Beitrag schreiben und schöner is

 

[byte]

Das ist ja nur eine von vielen immer wiederkehrenden Fragen und wenn man für jede einen Thread sticked, dann darf man für die "normalen" Threads auf Seite 2 blättern. Wer der Nachwelt etwas Gutes tun will und/oder zuviel Zeit hat, der schreibt einen Eintrag für die FAQ, der kurz, knapp und präzise ein Problem löst, und gut is. :roll: