Kann sein. Dann braucht der Windows-Calc vielleicht Klammern, um diesen Ausdruck korrekt zu berechnen.
Ich habe keinen Windows-Calc, ich habe kein Windows, ich bin sehr gluecklich darueber und ich habe nicht vor etwas zu unternehmen, das an dieser Situation etwas aendern koennte.
sqrt(2)*sqrt(2) ist jedenfalls 2, Punkt. Frag einen beliebigen Mathematiker Deiner Wahl; darueber laenger zu philosophieren ist jedenfalls sinnfrei.
Du hast eine merkwürdige Auffassung vom Wert der Zahl Null ... und wo das Komma steht, ist sowieso unwichtig; im molekularen oder atomaren Bereich wäre so etwas "riesig".
Is halt ein float. Fliesskommazahlen sind - ausser in Einzelfaellen
- nicht exakt. Der Wert laesst darauf schliessen, dass ein 128-Bit float verwendet wurde - und dass ein Programmierer vergessen hat, den Bitdreck hintendran wegzurunden.
Du hast es unterlassen, zu spezifizieren, was Dich genau am Resultat stoeren wuerde. In Ermangelung Deiner Angabe habe ich angenommen, dass der Windows-Taschenrechner Deine Eingabe in sqrt(sqrt(2)*2) umsetzen wuerde, was tatsaechlich nicht 2 ist, aber mit Klammerung behebbar waere.
Dass jemand zuerst ,---- | Message-ID: | From: snipped-for-privacy@Hullen.de (Helmut Hullen) | | "In nichts zeigt sich der Mangel an mathematischer Bildung mehr als | in einer übertrieben genauen Rechnung." | Carl Friedrich Gauss `---- schreibt, und sich einige Postings spaeter tatsaechlich entbloedet zu behaupten, dass er einer Rechnung der Groessenordnung "2-2" etwas in der Richtung 1*10^-38 rauskriegt, und das nicht Null waere, habe ich ehrlich gesagt nicht erwartet.
Und da kommt natuerlich 0 raus. HP-48SX. Manche Entwickler wissen eben um die Genauigkeit der eingesetzten Datentypen Bescheid, und vor allem wissens sie, wo und wann man zu runden hat.
Den Bitdreck kannst Du nicht wegrunden. Das obige Beispiel ist einer der Klassiker, wie Schutzziffern sichtbar gemacht werden können.
Häufiger Anwendungsfall: automatisiertes Suchen von Nullstellen. Da schauen viele Leute nur auf die Mantisse des Ergebnisses, nicht auf den Exponenten der 10er-Potenz. (ja: da gibt es Abfragen je nach gewünschter Genauigkeit ...)
Weil mich daran überhaupt nichts stört. "Dat isso!"
Es war eine Antwort auf Volkers (nicht immer zutreffende) Behauptung. Und eine indirekte Bestätigung von Gauss' Feststellung.
Am Rande: der angezeigte Rest ist nur dann in der Gegend 1e38, wenn die Ausgangswerte in der Gegend 1 ... 10 sind; ist nun mal ein relativer Fehler. Ich habe das Beispiel eben (unter Zuhilfenahme des Speichers) mit 16e40 (16*10^40) ausprobiert, da war der angezeigte Rest (natürlich) im Bereich von etlichen Tausendern. Hat schon viele Leute verwirrt ...
Natürlich kann man. Excel macht das. (Man verliert dabei zwar numerische Genauigkeit - das "runde" Ergebnis muß ja nicht das exakte sein - aber es geht durchaus, und das Ergebnis dürfte meistens erwartungsgemäßer sein.)
Man verliert gar nichts, es gibt genau die gleichen Ungenauigkeiten beim Weiterrechnen. Das einzige was Excel vom Calc unterscheidet ist die vom Zellenwert unabhängige Formatierung der Anzeige.
Und was das "erwartungsgemäß" betrifft: 99% aller im Umlauf befindlichen Excelblätter mit Summe eines berechneten Steuer- oder Bruttobetrags enthalten die falsche Gesamtsumme.
Klar. Das Produkt war 2,000000000000000000000000000000000000115787396... ? was freilich auf 2 gerundet wird, da es sich nicht anders darstellen läßt. Erst wenn man exakt 2 subtrahiert, werden die übrigen Stellen relevant.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.