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



## Octron99 (11. Dez 2003)

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 (11. Dez 2003)

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


----------



## mariopetr (11. Dez 2003)

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


----------



## bröggle (11. Dez 2003)

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


----------



## mariopetr (11. Dez 2003)

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 (12. Dez 2003)

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


----------



## mariopetr (12. Dez 2003)

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


----------



## jptc.org (12. Dez 2003)

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 (12. Dez 2003)

jptc.org hat gesagt.:
			
		

> getreu des alten witzes: _wieviele fussballspieler hat die mannschaft von intel? --- 10.999999999999999999999999999999999999999999999_



Aber doch nur bei den ersten Pentium1-Serien


----------



## jptc.org (12. Dez 2003)

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 (12. Dez 2003)

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 (12. Dez 2003)

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

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


----------



## mariopetr (12. Dez 2003)

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 (31. Jan 2004)

> 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 (1. Feb 2004)

:### 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 (27. Apr 2004)

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


----------



## Calamitous (28. Apr 2004)

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 (28. Apr 2004)

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 (28. Apr 2004)

Calamitous hat gesagt.:
			
		

> 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.
> ...



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 (28. Apr 2004)

> 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 (28. Apr 2004)

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!!!


----------

