Java zu blöde um 1-1 zu rechnen??

[Octron99]

public class Datei1 {

public static void main (String[] args) {
double a,b;

a = 0.1;
b = 1.0;

double Zahl = (a+a+a+a+a+a+a+a+a+a) - b ;
System.out.println ("Das Ergebniss ist " + Zahl);

}
}


wenn man das rechnen will kommt public class Datei1 -1.102230246251565E-16


WIESO BITTE?

danke für jede Antwort

 

[Octron99]

also ich meine als ergebniss kommt das zahlen gewirr raus, was schwachsinn ist, muss ja 1 ergeben, nur warum tuts das nich?

 

[mariopetr]

das liegt daran, das der computer nur diskrete mathematik kann. und -0.000000000000000011 ist doch schon recht nahe dem erwartetem ergebniss

 

[bröggle]

was ist bitte diskrete Mathematik ? und was ist dann das gegenteil?

 

[mariopetr]

in der normalen mathematik sind reelle zahlen unabzaehlbar unendlich, da der computer aber nicht unendlich viel speicher hat, muss er mit einer abzaehlbar, endlichen untermenge der reellen zahlen auskommen. das heist manche zahlen sind einfach nicht darstellbar. und das dann kleine rundungsfehler passieren ist normal.

 

[Guest]

ungenau ergebnisse?? hast du dir mal das ergebniss angeguckt? das ist reiner irrsinn, das ist sicherlich kein rundungsfehler

 

[mariopetr]

-1.102230246251565E-16 == -0.0000000000000001102...

 

[jptc.org]

tja wenn du mit höherer genauigkeit rechnen willst, so bietet dir java ne menge number - klassen an (bigdecimal, biginteger...). diese klassen rechnen mit ein paar mehr stellen, als wenn man die primitiven datentypen benutzt. d.h. für math. berechnungen sind sowieso nur diese objekte vorzuziehen. aber unterm strich bleibt natürlich die ungenauigkeit der diskreten mathematik... getreu des alten witzes: wieviele fussballspieler hat die mannschaft von intel? --- 10.999999999999999999999999999999999999999999999

Karsten Voigt
http://www.java-performance-portal.org

 

[AlArenal]

getreu des alten witzes: wieviele fussballspieler hat die mannschaft von intel? --- 10.999999999999999999999999999999999999999999999

Aber doch nur bei den ersten Pentium1-Serien

 

[jptc.org]

ok, das stimmt aber das problem existiert immer noch bei zahlen mit perioden wiederholungen die gegen unendlich gehen :shock:

Karsten Voigt
http://www.java-performance-portal.org

 

[christian]

Tja, selbst mit BigDecimal kommt kein besseres Ergebnis

import java.math.BigDecimal;

public class Datei1 {

	public static void main (String[] args) {


	BigDecimal a = new BigDecimal(0.1);
	BigDecimal b = new BigDecimal(1.0);

	BigDecimal Zahl = a.add(a.add(a.add(a.add(a.add(a.add(a.add(a.add(a.add(a))))))))).subtract(b);
	System.out.println ("Das Ergebniss ist " + Zahl);

	}
}

Das Ergebnis ist hier 0.0000000000000000555111512312578270211815834045410156250

 

[AlArenal]

Kann es sein, dass println() das Ganze wieder in Double umwandelt?

Außerdem ist der Rundungsfehler nun nur noch 50% so groß.

 

[mariopetr]

nein

BigDecimal.toString
public String toString()
Returns the string representation of this BigDecimal. The digit-to- character mapping provided by Character.forDigit(int, int) is used. A leading minus sign is used to indicate sign, and the number of digits to the right of the decimal point is used to indicate scale. (This representation is compatible with the (String) constructor.)
Overrides:
toString in class Object
Returns:
String representation of this BigDecimal.

 

[Calamitous]

10.999999999999999999999999999999999999999999999

wenn du damit 10,9 periodisch meinst dann wäre es kein Fehler da es mathematisch beweisbar ist das 10,9periodisch gleich 11 ist [kleine Notiz am Rande :]

 

[Javahnsinn]

:### das heisst, der limes der Differenz 10,9.periode. zu elf geht gegen null!

Übrigens: wäre der reelle Zahlenraum auf Digitalrechnern nicht diskret sondern kontinuierlich (auf Analogrechnern isser's), dann gäb es keine fraktalen Grafiken... Da werden nämlich bewusst kleinere Ungenauigkeiten ausgenutzt, um genügend dicht beieinander liegende reelle Zahlen in die Iterationsformel zu stopfen, an derem anderen Ende ein Farbwert rauskommt...

OK, eigentlich sinds komplexe Zahlen. Aber deren Imaginärteil wird vom Rechner (vom Algorithmus der Formel bei Sprachen, die keinen Datentyp Complex kennen, wie FORTRAN oder auch PYTHON) als reelle Zahl behandelt.

Gruß,
Jürgen

 

[Anubis]

Wer unbedingt genaue Ergebnisse braucht. muss sich eingen Rechenalgoryhtmen schreiben!! Von der Addition angefangen bis zur Wurzelfunktion.

 

[Calamitous]

tja ich hoffe ich rede mich da nirgendswo rein, also bitte korrektur wenns nicht stimmt...

Wer unbedingt genaue Ergebnisse braucht. muss sich eingen Rechenalgoryhtmen schreiben!! Von der Addition angefangen bis zur Wurzelfunktion.

hilft gar nix, denn der Prozessor wird nach wie vor mit 32bit/ev. 64bit rechnen, daher die Genauigkeitsbeschränkung. Du wirst also keine Alghorithmen schreiben können die "über die Fähigkeiten der CPU rausgeht..."

 

[Tobias]

Doch: Algorithmen, die die Ungenauigkeit mit einrechnen - also ein Ergebnis +-d als richtig und und genau erachten. Solche Algorithmen und die Art und Weise, auf die sie Ungenauigkeiten korrigieren oder ignorieren, sind natürlich anwendungsfallabhängig.

mpG
Tobias

 

[Grizzly]

tja ich hoffe ich rede mich da nirgendswo rein, also bitte korrektur wenns nicht stimmt...

Wer unbedingt genaue Ergebnisse braucht. muss sich eingen Rechenalgoryhtmen schreiben!! Von der Addition angefangen bis zur Wurzelfunktion.

hilft gar nix, denn der Prozessor wird nach wie vor mit 32bit/ev. 64bit rechnen, daher die Genauigkeitsbeschränkung. Du wirst also keine Alghorithmen schreiben können die "über die Fähigkeiten der CPU rausgeht..."

Das stimmt ja so nicht: Es gab' früher - als alles noch besser war :wink: - für C und Pascal Bibliotheken, die die Arbeit eines Coprozessors übernehmen konnten. Sprich man konnte dann auf Systemen ohne Coprozessor (der ja bekanntlich für die Gleitkomma-Arhytmetik zuständig ist) trotzdem Gleitkommazahlen benutzen, als wäre ein Coprozessor vorhanden.
Und durch Zerlegung lassen Sie auch Zahlen mit größerer Bitzahl als die Verarbeitungsbreite des Prozessor verarbeiten (bspw. 64 Bit Zahl auf einem 32 Bit Prozessor).

Der Nachteil bei der Zerlegung sowie bei der Bibliothek für Gleitkommazahlen ist jedoch die Geschwindigkeit: Diese Software-seitigen Implementationen sind immer signifikant langsamer als die Hardware-seitigen.

 

[Calamitous]

Und durch Zerlegung lassen Sie auch Zahlen mit größerer Bitzahl als die Verarbeitungsbreite des Prozessor verarbeiten (bspw. 64 Bit Zahl auf einem 32 Bit Prozessor).

stimmt natürlich, also meine Aussage rein auf "prozessor only"

 

[Anubis]

Ich meinte dass man den Computer "Schriftlich rechnen lassen sollte" wie wird es ja in der GRudschule gelernt haben und mittler wegen dem Taschenrechner verlernt haben. so meint ich dass.

Auf diese Technik konnte ich mal 2 ^ 10000 berechnen mit einer Programmiersprache, die nur Zahlen bis 2 ^ 32 unterstützt!!!
2 ^ 1000 hat etwa 6000 Stellen!!!