Schon wieder double -.-

Discordia

Mitglied
Also vorneweg ich habe
HTML:
http://www.java-forum.org/allgemeines/122323-ungenauigkeit-double-float-gleitkommazahlen-alternativen.html
gelesen und auch soweit alles verstanden.

So ein kleines Beispielprogramm:
Java:
public class GleitkommaOperationen {
  public static void main(String[] args) {
    double a = 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1;
    double b = (1+1+1+1+1+1+1+1+1+1)*0.1;
    double c = 1 + Math.pow(10,20) + (-Math.pow(10,20));
    double d = 1 + (Math.pow(10,20) + (-Math.pow(10,20)));
    System.out.println(a);
    System.out.println(b);
    System.out.println(c);
    System.out.println(d);
  }
}

Die Ausgabe sieht so aus:
HTML:
0.9999999999999999
1.0
0.0
1.0

Die erste Zeile kann ich mir erklären. 0.1 ist als Gleitkommazahl nicht genau darstellen, dadurch summiert sich der Fehler auf. Bei der zweiten Zeile entsteht der Fehler nur einmal.
Aber bei der dritten Zeile Versteh ich das nicht so genau. 1 und 10^20 kann man doch beide mit einer double genau speichern und auch genau zusammenrechnen, bzw auch wieder abziehen, warum kommt dann 0 raus?
10^20 entspricht:
HTML:
VorZ 	Exess											Mantisse																																																			
63	62	61	60	59	58	57	56	55	54	53	52	51	50	49	48	47	46	45	44	43	42	41	40	39	38	37	36	35	34	33	32	31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
0	1	0	0	0	0	0	1	0	0	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0

1 entspricht:
HTML:
VorZ	Exess											Mantisse																																																			
63	62	61	60	59	58	57	56	55	54	53	52	51	50	49	48	47	46	45	44	43	42	41	40	39	38	37	36	35	34	33	32	31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
0	0	1	1	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0

Da 1 den kleineren Exponenten hat wird es bei der Subtraktion an den größeren angepasst:
HTML:
VorZ	Exess											Mantisse																																																			
63	62	61	60	59	58	57	56	55	54	53	52	51	50	49	48	47	46	45	44	43	42	41	40	39	38	37	36	35	34	33	32	31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
0	1	0	0	0	0	0	1	0	0	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0

So und meines Erachtens kann ich die jetzt addieren ohne das Information wegfällt. Warum kommt dann aber die Ausgabe zustande?
 
10^20 ist halt zuviel für ca. 10^16 an Genauigkeit. Da fällt die + 1 nicht mehr ins Gewicht. Dann zählt nur noch 10^20 - 10^20 und das ist halt 0.
 
hätte ich jetzt auch gesagt

10^20 ist 110111100000101101101011001110100111011001000000000000000000
falls ich jetzt nichts falsch gemacht habe

10^20 + 1 ist 110111100000101101101011001110100111011001000000000000000001

als exponent erhalte ich bei beiden 10001000001


für 10^20 ist das normalisierte ergebnis 1.010110101111000111010111100010110101100011000100000000000000000000
für 10^20 + 1 ist es
1.010110101111000111010111100010110101100011000100000000000000000001

wenn ich nun die mantisse bilde benötige ich 52 bits
die mantisse sieht nun bei beiden gleich aus
nämlich
0101101011110001110101111000101101011000110001000000

achja 128 bits würden reichen...
 
Zuletzt bearbeitet:
Soviele Zahlen für 'ne einfache Erklärung? Wieviele Dezimalstellen haben 52 (bzw. 53 inkl. Normalisierung)? [c]lg(2^53)[/c] doch wohl und das sind halt ca. 16. Diese Zahl ist um einiges einfacher zu behalten als ständig die gesamte Theorie zu rezitieren.
 
Oh man ehj schon wieder voll den Denkfehler gemacht -.- Hab einfach mal 10^20 nicht in Binär umgerechnet. *Klatsch Hand gegen die Stirn*
Danke für die Geduld 🙂
 

Zurück
Oben