Präzision bei Typumwandlung zwischen double und String

[jueki]

Hallo,
in meinem Programm muss ich doublewerte des öfteren als Strings ablegen und später aus dem String wieder einen double machen. Dabei kommt es vor, dass aus einem Wert -z.B 2.5 - nach einigen Umwandlungen 2.49999999999... wird. Gibt es eine Umwandlungsmethode, die auf die letzte doublestelle (also keine fixe Nachkommastellenangabe) rundet oder aber wirklich exakt castet?

Vornehmlich caste ich zur Zeit mit

Double.valueOf(String)

danke schon mal
jueki

 

[eRaaaa]

Benutze doch BigDecimal ?!

 

[RySa]

Also an den Umwandlungen liegt es definitiv nicht....:

	public static void main(String[] args) {
		Double d = 2.5;
		String s = "";
		s = d+"";
		System.out.println(s);
		d = Double.valueOf(s).doubleValue();
		System.out.println(d);
		s = d+"";
		System.out.println(s);

	}

Liefert immer 2.5

Was du meinst ist, dass nach einigen Rechenoperationen wie z.B:

Double d = 2.5;
d = d + 0.05; //hier wird es noch 2.55 sein
d = d + 0.05; //hier aber schon 2.5999996

Dein Double-Wert plötzlich 2.499999999999999999 ist und nicht 2.5. Das hat aber mit dem Casten nichts zu tun. Doubles sind einfach in dieser Hinsicht ungenau. Du hast 2 Möglichkeiten.

1. Du benutzst BigDecimal
2. Du rundest das Ergebnis bei jeder Rechenoperation auf so viele Nachkommastellen, wie die Zahl hat, die du gerade addierst/subtrahierst. Auf diese Weise solltest du diese x.x999999999999999999 Zahlen vermeiden können.

 

[truesoul]

Hallo

Oder mit der Klasse Math. Würde aber eher eRaaaa's Variante bevorzugen.

Mfg

 

[jueki]

Tatsächlich, RySa hat recht. Das Casten verursacht die Ungenauigkeit nicht sondern die Multiplikation mit einem double-Faktor - tut mir leid.
Das Problem bleibt aber in so weit, dass ich gerne die Werte runden würde und zwar in auf die letzte tatsächliche Nachkommastelle im double. Das Runden selber ist nicht das Problem, aber wie kriege ich die
Anzahl der Nachkommastellen raus?

 

[RySa]

Auf die Schnelle würd ich sagen (wenn die Performance nicht von sehr großer Bedeutung ist, da diese Lösung etwas unschön ist), kannst du so etwas machen um die Anzahl der Nachkommastellen zu ermitteln:

double d = 2.75;
int anzahl = (""+g).split("\\.")[1].length();

Und wie willst du denn die "tatsächlichen Nachkommastellen" denn definieren ? Du müsstest vor jeder Rechenoperation, alle zahlen überprüfen, ob sie nicht "ungenau" sind. Oder du rundest das Ergebnis immer auf so viele Nachkommastellen wie der Faktor hat. Das führt aber genauso zu Ungenauigkeiten und ich nehme an, dass dir die Genauigkeit wichtig ist. Von daher - benutz einfach das BigDecimal, da double nicht für präzise Berechnungen gemacht wurde.

 

[Ezra]

Das Casten verursacht die Ungenauigkeit nicht sondern die Multiplikation mit einem double-Faktor - tut mir leid.

Wie genau sieht diese Rechnung aus? Manchmal kann man daran auch was drehen.

 

[jueki]

Also, die Umstellung auf BigDecimal würde mein mittlerweile doch etwas umfangreicheres Projekt ganz schön auf den Kopf stellen. Im Regelfall reichen mir auch genauigkeiten von 10^-9, könnte aber zu Problemen beim Aufmultiplizieren führen.
Ich habe zwischenzeitlich natürlich auch noch experimentiert und bin zu folgender Lösung gekommen:

	double val = 2.5;
System.out.println(""+val);

System.out.println("");
System.out.println("multiplikation mit 1/1000000 :");
val = val * 1.0e-6 ;
System.out.println(""+val);

System.out.println("");
System.out.println("Runden der 16. Dezimalstelle :");

// hier ist der wichtige Schritt: ...
val = Math.round(val*Math.pow(10, 16))/Math.pow(10, 16);

System.out.println(""+val);

Klappt soweit im Beispiel. Aber hat ein double immer maximal 16 Stellen oder ist das auf 64Bit-Rechnern anders. Mein Problem ist jetzt also nur noch wie ich die "16" sauber ermitteln kann.

(klappt übrigens nicht mit :

val = Math.round(val*Math.pow(10, 16)) * Math.pow(10, -16);

nur so zur Info.)

jueki

 

[RySa]

val = Math.round(val*Math.pow(10, 16)) * Math.pow(10, -16);

Dass es damit nicht klapp, liegt wahrscheinlich daran, dass der Wert so klein ist, dass double schon sagt "hmm ok, machen wa ne 0 draus". Bin da aber nicht sicher.

Und dass mit den 16 Stellen, verstehe ich bei double auch nicht ganz. Habe jetzt mal paar Tests auf einem 32-bit Rechner durchgeführt, und manchmal nimmt der 17 Stellen an, manchmal 16, aber immer mindestens 16. Ich wüsste jetzt aber nicht was das mit dem Problem zu tun hat, dass er manchmal statt 0.5 zu addieren, 0.49999996 addiert. Wenn du das Ergebnis auf 16. Stelle rundest, hast du immer noch diese ungenauigkeit, dass du mit 0.49999996 gerechnet hast und nicht 0.5 ... Die Umstellung auf BidDecimal mag vielleicht "nerfig" sein, ist abber immer noch besser, als vor jeder Rechnung die Zahlen zu runden und sonst noch was. Ist aber deine Entscheidung.

 

[jueki]

Ich wüsste jetzt aber nicht was das mit dem Problem zu tun hat, dass er manchmal statt 0.5 zu addieren, 0.49999996 addiert

... das ist wohl ein Missverständnis: Mein Problem war, dass ich bei einer Multiplikation kein exaktes ergebnis bekam weil der Faktor als double-Wert nicht exakt darstellbar ist. Ich weiß nicht welchen Umfang diese Ungenauigkeit annehmen kann, aber in meinen Test reichte immer ein Runden der 16. Dezimalstelle aus. Erstaunlicherweise tritt zB. bei einer Multiplikation 1.0/3.0*10e-6 oder 2.0/3.0*10e-6
keine Ungenauigkeit zu tage (hätte ich hier aber erwartret).
Aufgetreten ist das Problem bei einer if-Abfrage: Der User gibt 2.5 ein und das System vergleicht mit 2.49999.... was daraus resultiert, dass eine Einheitenkorrektur durchgeführt werden muss. Es geht also nicht um die letzte signifikante Stelle im double.

jueki

 

[jessy1109]

guten morgen zusammen,

ich möchte mich mit java befassen, komm da aber nicht weiter. kann mir jemand helfen
lg jessy

 

[jueki]

guten morgen zusammen,

ich möchte mich mit java befassen, komm da aber nicht weiter. kann mir jemand helfen
lg jessy

... ich fürchte, in diesem Diskussionsfaden bist Du jetzt eher irrtümlich. Vielleicht machst Du besser einen eigenen auf? ... und vielleicht stellst Du die Frage auch etwas präziser, denn so kann man alles oder nichts dazu sagen. Wenn Du noch ganz grün bist, frag doch mal das Web nach Anfänger Tutorials für Java.

jueki

 

[RySa]

Wenn es dann daran hackt, dass eine Usereingabe vergleicht werden soll, und es aber unglücklicherweise z.B 2.5 mit 2.49999 vergleicht, dann Prüfe vorm Vergleich, wie viele Nachkommastellen die Zahl hat, die der User eingegeben hat, runde deine Zahl auf die Anzahl der Nachkommastellen (zumindest für diesen Vergleich, das Original kannst du behalten) und Vergleiche sie dann erst (nach dem Motto - wenn ich etwas in Metern messe, dann kann es nicht auf den Centimeter genau sein).

Oder aber du Vergleichs die nicht mit == sondern setzst dir eine bestimmte Fehlertoleranz von z.B 0.0004 und überprüfst dann ob es stimmt . zB

if (zahl >= eingabe-0.0004 && zahl <= eingabe+0.0004){
//Inhalt
}

Und nochmal zu dem Runden auf die 16. Stelle. Was macht das denn für ein Unterschied, wenn double sowieso automatisch auf die 16. bzw 17. Stelle gerundet wird (also z.B aus 678.555555555555555 wird 678.5555555555556 bzw. 678.55555555555556 - zumindest was die Umwandlung in Strings angeht).

 

[jueki]

ja, da hast Du recht, wenn nicht ein langer Schwanz ...99999 oder ...000001 als Dezimalstellen im double steckten, bringt das Runden nichts. Meine Beobachtung bisher war aber immer der lange Schwanz mit ...99999. Glücklicherweise konnte ich auch eine Stelle in meinem Projekt ausmachen, an der die Ungenauigkeit entsteht, und zwar genau in der Funktion, die die Einheiten zwischen angezeigter und interner Einheit (intern ist immer Meter) umrechnet. Seit ich in dieser Funktion die oben beschriebene Rundung auf die letzte Stelle eingeführt habe, läuft alles prima.
Die Idee, die Genauigkeit der vom User vorgegebenen Zahl als Maßstab zu nehmen ist aber auch prima, Du hast ja schon oben beschrieben, wie man die raus kriegt.
Mit einer fest vorgegebenen Toleranz zu vergleichen habe ich so ein bisschen Bauchweh, kann ich nicht überblicken, ob ich dann nicht den Teufel mit dem Belzebub austreibe, eben genau so wie jetzt, wenn ich immer fest 16 Stellen im double annehme.

OK, aber ich glaube das führt jetzt von der anfänglichen Fragestellung zu weit weg. Vielen Dank an alle, die sich mit dem Thema befaßt haben und besonders an RySa. Eine Funktionale Lösung habe ich jetzt ja erst mal und eine Menge Ideen dazu.

Wenn aber jemand doch noch weiß, wie ich die Anzahl der möglichen Dezimalstellen im double raus kriege währe ich ganz froh.

jueki

 

[jueki]

... ach ja, und noch eins oben drauf: habe es zu Anfang nicht bemerkt, aber durch die Multiplikation mit 10^16 stößt man schnell an die maximalgrenze der Doubles. Man muss also doch auf BigDecimal zurückgreifen. Meine Rundungsfunktion sieht jetz also so aus:

	public static double precision(double val)
	{
		int n = 16;
		BigDecimal bigdec = BigDecimal.valueOf(val);
		return (bigdec.setScale(n, BigDecimal.ROUND_HALF_UP)).doubleValue();
	}

Das scheint's jetzt zu tun.
jueki