Wenn man in den Rechner Wurzel(4) eingibt, dann - 2 rechnet, dann kommt:
-wenn man im wissenschaftlichen modus ist:
-8,1648465955514287168521180122928e - 39 raus.
- wenn man im normalen modus ist:
-1,068281969439142e - 19 raus.

Klingt ein wenig falsch..

Und wenn man das Ergebnis -2 rechnet, kommt aber wieder -2 raus... lustig

das liegt am double
die sind ja nicht absolut genau, was wurzeln ausrechnen geht (was ja eig. auch nur bei quadratzahlen exakt zu rechnen geht)
heißt aber auch, das wenn du wurzel(4) nimmst, kommt da 2,000000000000000329746 raus. Zeigt er aber nicht an, wäre ja zu viel unnötige information
wenn du jetzt aber -2 rechnest, kommt 0,000000000000000329746 raus, was ja iwie erst ab 329 interessant wird, heißt, das wird dargestellt
rechnet man wieder -2, wird wieder gerundet ^^

alles geklärt?

Ist doch für normalor unnormal uninteressant!

ja, aber wenn du jetzt 3*10^-4 + 4*10^-5 rechnest, sollte er es doch auch anzeigen, oder?

Ist doch quasi 0. Sehe da nichts falsches, von einer den Datentypen geschuldeten Ungenauigkeit mal abgesehen.
Mit "doof" hat das nichts zu tun, eigentlich auch nciht wirklich mit Windows.

Da meines Wissens nach alle Wurzel-Algorithmen iterativ verfahren, sprich solange arbeiten, bis eine gewisse Fehlerschranke unterschritten oder die maximale Anzahl an Schritten erreicht worden ist, darf man dabei auch nicht auf mathematisch theoretisch exakte Ergebnisse hoffen, selbst wenn es nicht an der beschränkten double-Genauigkeit läge.

Die Ungenauigkeiten bei der Wurzelberechnung sind ja okay, und sie erklären auch das Problem.
Aber ich denke, darum geht es hier gar nicht.

Meiner Meinung nach ist das ein Programmfehler. Und zwar ein Fehler in der "Benutzeroberfläche".
Wenn ein Ergebnis von 2,000000000000000329746 herauskommt, dann sollte das am besten auch so angezeigt werden. Und wenn es auf 2,0 abgeschnitten wird, was ja auch okay ist, dann muss das Programm aber nachher auch mit diesem abgeschnittenen Wert weiterrechnen, und nicht mit dem zuvor intern berechneten genaueren Wert.

Ich finde, ob der User den Wert 2,0 händisch eingibt, oder ob dieser Wert zuvor irgendwie berechnet wurde, darf keinen Unterschied machen. Wenn am Display als Ergebnis 2,0 steht, dann erwartet der Anwender, dass auch mit diesem Wert 2,0 weitergerechnet wird.

@Harry Potter: Tut mir leid, aber bei den vielen Nachkommastellen, die man dafür bräuchte um zu zeigen, dass das Ergebnis nicht wirklich 2 ist, bräuchte man mehr Nachkommastellen als der Taschenrechner angeben kann. Dein Beispiel war 2,000000000000000329746, aber -8,1648465955514287168521180122928*10^-39 + 2 = 2,0000000000000000000000000000000000000081648465955514287168521180122928. So viele Stellen kann der Windows-Taschenrechner nicht anzeigen, also muss er es auf 2 runden. Und die -8,1648465955514287168521180122928*10^-39 sind auch schon gerundet zur maximalen Anzahl an Stellen, die der Taschenrechner anzeigen kann, also wären das in Wahrheit noch mehr Stellen.

Und ich möchte auch nicht, dass der Taschenrechner mit den Werten, die er anzeigt weiterrechnet. Für mich ist ein Taschenrechner SCHLECHT wenn 1/3*3 = 0,999999999 ergibt.

@Lukas: Dann muss zumindest irgendwie angezeigt werden, dass der am Display angezeigte Wert unvollständig bzw. abgeschnitten ist.
Aber den Wert 2 anzeigen, und dann mit 2,0000000000000000000000000000000000000081648465955514287168521180122928 weiterrechnen, finde ich nicht okay.
Das kann in manchen Fällen sinnvoll sein, aber in manchen Fällen für den User auch zu einem unerwünschten/falschen Ergebnis führen.

Also wenn am Display "2" als Ergebnis steht, dann gehe ich davon aus, dass das Ergebnis eine ganze Zahl ist. Und dann gehe ich auch davon aus, dass nachfolgende Rechenoperationen mit genau dieser ganzen Zahl weiterrechnen. Wenn dem nicht so ist, dann sollte dort z.B. stehen: "2,000000000000000000000". Dann weiß man sofort, dass der Wert keine ganze Zahl ist (bei 0,3333333333333333 merkt man das ja auch sofort, aber bei 2 merkt man das nicht).