0.009 wird zu 0.0090

[me.toString]

Moin!

Habe eben ewig nach einem Fehler in meinem Programm gesucht ... und nu muss ich feststellen, dass Java selber das Problem ist:

System.out.println(0.009);

Aber es wird nicht 0.009 ausgegeben sondern 0.0090 !!! Mit internen Darstellungsfehlern kann das ja nix zu tun haben, dann würde ja sowas wie 0.0090000000000001 rauskommen. Hat von euch schon mal jemand so ein Problem gehabt? Man könnte natürlich dahergehen und die letzten Nullen abscheiden... aber das muss doch auch eleganter gehen !?

 

[Kaffeebohne]

Das ist ja witzig. Stimmt. Und bei einer zusätzlichen Null wirds 9.0E-4

Warum würde mich jetzt aber auch interessieren.

 

[clemson]

package org.javaforum.y06.april.PrintF;

import java.text.DecimalFormat;

public class DoublePrint
{

	public static void main(String[] args)
	{
		double d = 0.009d;
		DecimalFormat format = new DecimalFormat("#.###");
		System.out.println(format.format(d));
	}

}

 

[The_S]

package org.javaforum.y06.april.PrintF;

import java.text.DecimalFormat;

public class DoublePrint
{

	public static void main(String[] args)
	{
		double d = 0.009d;
		DecimalFormat format = new DecimalFormat("#.###");
		System.out.println(format.format(d));
	}

}

Das ist aber nicht die Antwort auf die Frage ... :autsch:

 

[clemson]

Das ist aber nicht die Antwort auf die Frage ... :autsch:

was is denn die frage? ???:L

 

[The_S]

Das ist aber nicht die Antwort auf die Frage ... :autsch:

was is denn die frage? ???:L

warum dass so ist. Also warum bei einer Fließkommazahl immer eine 0 hinter die letzte Kommazahl gehängt wird sobald diese letzte Zahl die einzigste ist, die != 0 ist.

 

[clemson]

achso, ja dann hab ich das wohl falsch verstanden....

 

[Murray]

Ich würde das als Fehler im JDK ansehen; die Doku besagt ja
1. PrintStream#println( double) funktioniert wie PrintStream#print( double)
2. PrintStream#print( double) funktioniert wie String#valueOf( double)
3. String#valueOf( double) funktioniert wie Double#toString( double)
4. Für Double#toString( double) gilt:

How many digits must be printed for the fractional part of m or a? There must be at least one digit to represent the fractional part, and beyond that as many, ****but only as many****, more digits as are needed to uniquely distinguish the argument value from adjacent values of type double. That is, suppose that x is the exact mathematical value represented by the decimal representation produced by this method for a finite nonzero argument d. Then d must be the double value nearest to x; or if two double values are equally close to x, then d must be one of them and the least significant bit of the significand of d must be 0.

Wenn ich jetzt folgendes Testprogramm ausführe:

public class Test {

	public static void main( String[] args) {
		
		test( 0.009);
	
	}
	
	public static void test( double d) {
		System.out.println( "test: d = " + d);
		long l = Double.doubleToLongBits( d);
		for ( int i=-3; i<=3; i++) {
			long ll = l + i;
			System.out.println( i + "\t " + ll + "\t " + Double.longBitsToDouble( ll)); 
		
		}
	}
	

}

dann sehe ich folgende Ausgabe:
-3 4576341768551784248 0.008999999999999994
-2 4576341768551784249 0.008999999999999996
-1 4576341768551784250 0.008999999999999998
0 4576341768551784251 0.0090
1 4576341768551784252 0.009000000000000001
2 4576341768551784253 0.009000000000000003
3 4576341768551784254 0.009000000000000005

Also: die interne Repräsentation von 0.009 ist 4576341768551784251. Dann ist der nächstkleinere, mit double darstellbare Wert offenbar 0.008999999999999998; der nächstgrößere Wert dann 0.009000000000000001. Insofern wäre also bereits 0.009 eindeutig von den angrenzenden beiden Werten unterscheidbar, und da ja nicht mehr Nachkommastellen ausgegeben werden solle, als zur Unterscheidung notwendig, ist das Verhalten hier anders als in der Dokumentation.

IMHO also ein Bug für Erbsenzähler :wink:

 

[teufel]

Hi ehli75,
das hat was mit dem datentyp zu tun.
Jede Zahl wird binär gespeichert. Ich weiß zwar nicht wie das bei dem datentyp double aussieht, aber normalerweiße wird so eine zahl in einem datenwort gespeichert. So ein Wort hat immer eine bestimmte länge (z.b. besteht immer aus 6 bytes das entspricht 48 bits). Werden nicht alle 6 bytes benötigt, wird am schuss einfach eine null rangehängt (Alle ungebrauchten bytes werden zu 0). Nun weiß die Ausgabe ja nicht was man da eingegeben hat und gibt daher das ganze Wort aus (Samt den von Programm hinzugefügten nullen).

Mfg teufel

 

[Kawa-Mike]

Wenn es wirklich mit der Internen Darstellung der Zahlen zu tun hat, könnte es sogar Plattform- oder JVM-abhängig sein.
Ich habe es mal getestet mit

1.) Win2000 und Java 1.5.0_06 von SUN
2.) SuseLinux 9.0 und Java 1.4.2-b28, auch von SUN

Beide Rechner haben eine Intel Pentium-Processor.
Bei beiden Tests wurde die 0 angehängt.
Interessant wäre es auch mit einem Rechner mit AMD-CPU, oder unter einem ander OS z.B. MAC.

 

[me.toString]

warum dass so ist. Also warum bei einer Fließkommazahl immer eine 0 hinter die letzte Kommazahl gehängt wird sobald diese letzte Zahl die einzigste ist, die != 0 ist.

Das ist nicht immer so, sondern nur bei den Zahlen 0.001, 0.002, ..., 0.009. Sonst müsste ja bei System.out.println(0.9) rauskommen 0.90 ... tuts aber nicht.

Das es nun 4 Nachkommastellen sind... mein Gott, dass kann ich dem Kunden schon irgendwie verklickern ... aber nun kommt noch das Problem hinzu, dass durch die "neue" 0 mein Wert falsch wird. Ursprünglich hatte ich die Zahl 0.00917119565217395, die auf 3 Stellen nach dem Komma gerundet werden soll ...das hat auch wunderbar geklappt: 0.009. Wennich nun aber System.out.println(zahl) mache, kommt eben 0.0090 raus ... und das ist, abgesehen davon, dass es auf einmal 4 Nachkommastellen sind, nicht korrekt ... dann müsste es heissen 0.0092!
Bei wievielen Zahlen tritt das denn noch auf? ... da kann man sich ja auf nix verlassen.
Eben hab ich bei SUN in der Bug-Database was dazu gefunden ... aber so richtig schlau werd ich da nicht draus (mein Englisch ist nicht das aller beste) ... aber wenn ich mir überlege, dass der Bug (so fern es denn einer ist ... vielleicht wird es in der nächsten Java-Version als Feature gefeiert ... :wink 2001 eingestellt wurde, ist es schon traurig, dass da Java-Intern noch nix passiert ist ...

 

[byte]

Die Antwort auf die Frage hat Clemson oben doch schon gepostet. Du solltest in Java für die Ausgabe von Dezimalzahlen immer ein NumberFormat bzw. DecimalFormat verwenden, weil Du nur so sichergehen kannst, die dezimalen Ungenauigkeiten zu umgehen. Diese Ungenauigkeiten sind übrigens keine Schwäche von Java sondern kommen daher, dass Java (und jede andere Computersprache auch) intern binär rechnen, das Binärsystem dezimal jedoch ungenauer ist als das 10er System.

Vergleiche dazu:

DecimalFormat df = new DecimalFormat("#.###############");
		
float z = 0.009f;
		
System.out.println(df.format(z));
System.out.println(z);

 

[The_S]

warum dass so ist. Also warum bei einer Fließkommazahl immer eine 0 hinter die letzte Kommazahl gehängt wird sobald diese letzte Zahl die einzigste ist, die != 0 ist.

Das ist nicht immer so, sondern nur bei den Zahlen 0.001, 0.002, ..., 0.009. Sonst müsste ja bei System.out.println(0.9) rauskommen 0.90 ... tuts aber nicht.

Stimmt! Ich frag mich nur gerade was ich dann gestern rumprobiert hab, dass ich da draufgekommen bin ???:L