Windows Taschenrechner Bugs

[Rooter]

Hi,

das hier feiere ich grad mehr als es die Sache vermutlich wert ist:
https://www.computerbase.de/2018-07/windows-10-taschenrechner-quadratwurzel/ :ulol:

Ja, ich weiß, dass es 32bit Rundungsfehler (https://de.wikipedia.org/wiki/Gleitkommazahl#Einschränkungen_und_deren_mathematische_Grundlagen) sind.

Was bei mir unter Win7 funktioniert:

Im wissenschaftlichen Modus wird Punkt-vor-Strich beachtet, im Normalmodus nicht - das ist vermutlich kein Bug sondern ein Feature :D
Wurzel aus 4 minus 2 ergibt -8,1648465955514287168521180122928e-39 :ugly:
Dritte Wurzel aus 64 ergibt korrekt 4, das dann minus 4 ergibt aber 1,2871780571469535532654109905298e-37 :ugly:


Aber warum soll es so schwer sein, dieses Problem zu umgehen? Wenn bei einer Wurzelberechnung ein Wert rauskommt der so nah an 0 ist macht man die Gegenprobe (2x2, 4x4x4) und kann das richtige Ergebnis ausgeben.

MfG
Rooter

[=Floi=]

ich kann bei dem artikel auch nur den kopf schütteln.

Das zeigt aber wie weit MS eigentlich von jeglicher realität entfernt ist. Behäbig und wirft halb fertige software auf den markt.

Man könnte aus den standardprogrammen viel mehr machen. Der alte rechner war auch deswegen besser, weil er rechnete bis das ergebnis da war. Irgendwie ist das ganze traurig.

[Monger]

Das Problem hier ist, dass der Anwender Operationen zwischen Dezimalzahlen, natürlichen Zahlen und Gleitkommaoperationen durcheinander wirft.
Der Taschenrechner rechnet mit Gleitkommazahlen, und das korrekt. Alles andere sind Hacks. Wenn du auf einem Computer korrekte Rechnungen mit Dezimalbrüchen haben willst, musst du a) besser ausdrücken was du eigentlich haben willst, und b) deutlich mehr Geld für komplexere Software hinblättern.

Kurzum: Ist im wesentlichen ein Layer 8 Problem. Dass Microsoft auf so einen Quatsch überhaupt reagiert, ist wiedermal facepalm.

[Mosher]

Das Problem hier ist, dass der Anwender Operationen zwischen Dezimalzahlen, natürlichen Zahlen und Gleitkommaoperationen durcheinander wirft.
Der Taschenrechner rechnet mit Gleitkommazahlen, und das korrekt. Alles andere sind Hacks. Wenn du auf einem Computer korrekte Rechnungen mit Dezimalbrüchen haben willst, musst du a) besser ausdrücken was du eigentlich haben willst, und b) deutlich mehr Geld für komplexere Software hinblättern.

Kurzum: Ist im wesentlichen ein Layer 8 Problem. Dass Microsoft auf so einen Quatsch überhaupt reagiert, ist wiedermal facepalm.
+1, sehe ich exakt genau so.

Wer Ergebnisse nach seinen Vorstellungen haben will, der soll halt professionelle Software verwenden. Für den Windows-Taschenrechner kommt halt intern diese Zahl raus und die zeigt er an. Wenn Windows "raten" soll, dass einem eine angezeigte 0 lieber ist, gibt es schon Glaskugeln für USB?
Wenn Windows einzelne Werte per Lookup berechnen soll und nicht mit einem universellen Algorithmus, wo ist die Grenze? Soll die 18. Wurzel aus 57^18 auch noch hinterlegt sein, damit das Ergebnis stimmt?

[registrierter Gast]

Der Anspruch an den Windows Taschenrechner sollte der gleiche Anspruch wie an den Taschenrechner in der Schule sein.

Bei dem Taschenrechner in der Schule kommt 0 heraus. Das sollte der Windows Taschenrechner mit dem milliardenfachen an CPU Leistung auch schaffen.

Das ist kein Anspruch, den man allein an professioneller Mathesoftware stellen muss. :rolleyes:


Und man braucht noch nicht mal lookup tables dafür. Iterationsverfahren und Gleitkommazahlen mit beliebiger Genauigkeit sind ausreichend erforscht.
Und wenn selbst die 65.000ste Nachkommastelle immer noch 0 ist, dann kann man für den Nutzer im Standard-Modus des Rechners davon ausgehen, dass der keine Gleitkommazahl sehen möchte.

Vielleicht reicht auch schon die Gewissheit nach der 1024. Nachkommastelle. Das soll dann der Produktmanager für den Taschenrechner bei Microsoft entscheiden.

Für den Nutzer des Taschenrechners macht das freilich keinen Unterschied. Ob das Ergebnis nun binnen 0.0000001s oder 0.0001s dargestellt wird, ist egal. Dafür ist die Latenz, selbst eines 144Hz Monitors, immer noch viel zu hoch.

[Gimmick]

+1, sehe ich exakt genau so.

Wer Ergebnisse nach seinen Vorstellungen haben will, der soll halt professionelle Software verwenden. Für den Windows-Taschenrechner kommt halt intern diese Zahl raus und die zeigt er an. Wenn Windows "raten" soll, dass einem eine angezeigte 0 lieber ist, gibt es schon Glaskugeln für USB?
Wenn Windows einzelne Werte per Lookup berechnen soll und nicht mit einem universellen Algorithmus, wo ist die Grenze? Soll die 18. Wurzel aus 57^18 auch noch hinterlegt sein, damit das Ergebnis stimmt?

Bei "Dritte Wurzel aus 64 ergibt korrekt 4, das dann minus 4 ergibt aber 1,2871780571469535532654109905298e-37" hat er ja bei der ersten Rechnung schon entschieden, dass das Ergebnis "4" ist, rechnet dann aber mit einem anderen Zwischenergebnis weiter.

[Mosher]

Ja, es ist inkonsistent, aber in seiner Wirkung halt einfach nur ein Schönheitsfehler.

Wer ernsthaft wurzel(9) im Taschenrechner eingibt, hat doch Langeweile, oder sowieso ganz andere Probleme.


Wenn der Unterschied zwischen 0 und 1.5e-39 wirklich zwischen und Leben und Tod entscheidet, dann verwende ich halt nicht den Windows-Rechner.
Ansonsten denke ich mir meinen Teil, schmunzle 2 Sekunden und gehe dann wieder meinem Schaffen nach.

Edit: Wenn ich "1 / 3" eingebe, steht als Ergebnis auch da "0.333333333333333" und nicht "Null Komma Periode drei" !!!!!!!!einelf!
Ist das überhaupt die korrekte Anzahl Dezimalstellen, oder wird intern noch genauer gerechnet? Also das will ich jetzt von einer Taschenrechner-App schon wissen.
Mein Taschenrechner kann schließlich auch Perioden anzeigen.

[Rooter]

Der Anspruch an den Windows Taschenrechner sollte der gleiche Anspruch wie an den Taschenrechner in der Schule sein.

Bei dem Taschenrechner in der Schule kommt 0 heraus. Das sollte der Windows Taschenrechner mit dem milliardenfachen an CPU Leistung auch schaffen.

Das ist kein Anspruch, den man allein an professioneller Mathesoftware stellen muss. :rolleyes:Eben, so sehe ich das auch.
Wurzelberechnungen sind ja jetzt noch keine höhere Mathematik. :rolleyes:

Vielleicht reicht auch schon die Gewissheit nach der 1024. Nachkommastelle. Das soll dann der Produktmanager für den Taschenrechner bei Microsoft entscheiden.1024 ist auch noch völlig übertrieben. Schon wenn die 10. oder 12. Nachkommastelle noch Null ist wäre es imo okay...

Wer ernsthaft wurzel(9) im Taschenrechner eingibt, hat doch Langeweile, oder sowieso ganz andere Probleme.Tolles Argument! :uclap: Also weil die Rechnung so einfach ist, dass es eh jeder im Kopf weiß, darf der Taschenrechner dabei ruhig krassen Quatsch ausspucken!? :freak:

MfG
Rooter

[Gimmick]

Ja, es ist inkonsistent, aber in seiner Wirkung halt einfach nur ein Schönheitsfehler.

Wer ernsthaft wurzel(9) im Taschenrechner eingibt, hat doch Langeweile, oder sowieso ganz andere Probleme.


Jojo, habe in der Schule auch öfter mal so lange irgendwas dividiert auf dem Taschenrechner bis gleichviele Multiplikationen nicht mehr zur Ursprungszahl geführt haben.
Ja aus Langeweile :freak:

[Mosher]

Eben, so sehe ich das auch.
Wurzelberechnungen sind ja jetzt noch keine höhere Mathematik. :rolleyes:



Es geht doch überhaupt nicht darum, wie schwer oder einfach eine Rechnung für den Menschen zu bewältigen ist. Ein Computer arbeitet ganz anders, das weißt du doch. Und klar kann man auch einen Taschenrechner so programmieren, dass er bei der Eingabe schon die Komplexität bewerten kann und dann entsprechend bei Bedarf von seinem Standardalgorithmus abweicht. Ist halt hier offenbar nicht geschehen. Ok.


1024 ist auch noch völlig übertrieben. Schon wenn die 10. oder 12. Nachkommastelle noch Null ist wäre es imo okay...



Aha. Schon mal Schwingkreise berechnet, wo dann am Schluss für den Kondensator ein paar pF oder sowas rauskommen?
Ich hätte in so einem Fall nicht gerne, dass der Taschenrechner dann "krassen Quatsch", also 0 anzeigt. Aber deswegen benutze ich für sowas ja eher andere Software.


Tolles Argument! :uclap: Also weil die Rechnung so einfach ist, dass es eh jeder im Kopf weiß, darf der Taschenrechner dabei ruhig krassen Quatsch ausspucken!? :freak:

MfG
Rooter



Sag mal gehts bei dir eigentlich noch? Wie wärs mal mit zwei Sekunden nachdenken.

Es geht doch überhaupt nicht um die Komplexität der Rechnung, siehe mein Beispiel mit 1/3. Auch da spuckt der Taschenrechner "krassen Quatsch" aus, der aber eben kein "krasser Quatsch" ist, sondern einen technischen Hintergrund hat.
Komisch, dass sich da noch niemand drüber lustig gemacht hat.

Nochmal: Wer sich über einen Rundungs- oder was weiß ich wie gearteten systematischen Fehler bei so einer Rechnung aufregt, hat schlicht nichts besseres zu tun. Für den praktischen Einsatz spielt es überhaupt keine Rolle.

Ich gebe dir noch ein anderes (eher fiktives) Beispiel aus der Praxis:
Warum zeigt mein Multimeter eigentlich selten 0.000V an, wenn ich die Spitzen zusammenhalte? Hat wohl (auch, aber ja, ich weiß, nicht nur)irgendwas mit dem inneren Aufbau der Messchaltung und dem Zappeln am AD-Wandler zu tun. Warum bauen Multimeterdesigner keinen Sensor ein, der erkennt, wenn man die Spitzen zusammenhält und zeigt dann einfach 0 V an?


Jojo, habe in der Schule auch öfter mal so lange irgendwas dividiert auf dem Taschenrechner bis gleichviele Multiplikationen nicht mehr zur Ursprungszahl geführt haben.
Ja aus Langeweile :freak:
Sowas meinte ich mit 2 Sekunden schmunzeln und Langeweile. Hat glaube ich jeder schon mal gemacht.

Aber ich erwarte mir bei sowas halt keinen Skandal-Artikel und Shitstorm über die Unfähigkeit von Casio.

[Lokadamus]

Jojo, habe in der Schule auch öfter mal so lange irgendwas dividiert auf dem Taschenrechner bis gleichviele Multiplikationen nicht mehr zur Ursprungszahl geführt haben.
Ja aus Langeweile :freak:Unser Lehrer hat uns drauf hingewiesen, dass eine Rechnung anders ausgeht, je nachdem, ob der Taschenrechner 8 oder 10 Stellen hat. War auch was mit Rundungsfehler. Ob es dabei um Wurzeln ging, weiß ich nicht mehr.

Alternativer Taschenrechner: https://www.google.com/search?q=sqrt+9 oder http://www.wolframalpha.com/input/?i=sqrt+9

[Rooter]

Aha. Schon mal Schwingkreise berechnet, wo dann am Schluss für den Kondensator ein paar pF oder sowas rauskommen?
Ich hätte in so einem Fall nicht gerne, dass der Taschenrechner dann "krassen Quatsch", also 0 anzeigt. Aber deswegen benutze ich für sowas ja eher andere Software.Hast Recht, 12 ist zu wenig. Ich kann unter Win7 32-stellige Zahlen eingeben, wie wäre es dann mit 32 Stellen?
Ich wollte ja auch nur sagen, dass 1024 viel zu viel ist.

Es geht doch überhaupt nicht um die Komplexität der Rechnung, siehe mein Beispiel mit 1/3. Auch da spuckt der Taschenrechner "krassen Quatsch" aus, der aber eben kein "krasser Quatsch" ist, sondern einen technischen Hintergrund hat.
Komisch, dass sich da noch niemand drüber lustig gemacht hat.Warum solle man? Bei 1/3 weiß ja jeder, dass es halt ein Bruch ist, der nicht anders darstellbar ist.
Aber die dritte Wurzel aus 64 ist nur mal runde 4 und vier ist jetzt keine komplexe Zahl. Sorry aber für solche Fehler brauche ich kein Verständnis zeigen, auch wenn es sich nur um ein kleines Betriebssystem-Tool handelt. Der Calculator von Linux Mint macht übrigens keine solch krassen Rundungsfehler, wie machen die das nur...? :uponder:

Nochmal: Wer sich über einen Rundungs- oder was weiß ich wie gearteten systematischen Fehler bei so einer Rechnung aufregt, hat schlicht nichts besseres zu tun. Für den praktischen Einsatz spielt es überhaupt keine Rolle.

Ich gebe dir noch ein anderes (eher fiktives) Beispiel aus der Praxis:
Warum zeigt mein Multimeter eigentlich selten 0.000V an, wenn ich die Spitzen zusammenhalte? Hat wohl (auch, aber ja, ich weiß, nicht nur)irgendwas mit dem inneren Aufbau der Messchaltung und dem Zappeln am AD-Wandler zu tun. Warum bauen Multimeterdesigner keinen Sensor ein, der erkennt, wenn man die Spitzen zusammenhält und zeigt dann einfach 0 V an?Eher ein schlechtes Beispiel denn beim Multimeter weiß jeder, dass man mit einigen Prozent Messungenauigkeit zu rechnen hat.

MfG
Rooter

[Monger]

Der Anspruch an den Windows Taschenrechner sollte der gleiche Anspruch wie an den Taschenrechner in der Schule sein.
Warum? Der Anwendungsfall in der Schule ist relativ eindeutig, da geht es um das Rechnen mit Dezimalzahlen, meistens in relativ kleinen Bereichen. Das ist auf dem PC alles andere als eindeutig, kommt immer darauf an was für einen Anwender du vor dir sitzen hast.
Wenn du jetzt die Zahl rundest, wirst du die Leute anpissen die zuverlässige Gleitkommaoperationen erwarten.

[Monger]

Eben, so sehe ich das auch.
Wurzelberechnungen sind ja jetzt noch keine höhere Mathematik. :rolleyes:


Offensichtlich zu hoch, als dass sie von der Mehrheit der Bevölkerung richtig interpretiert wird. Was der Windows Rechner bisher ausspuckte, war halt nicht das Zahlensystem was du erwartest. Aber falsch war das Ergebnis nicht.

[Mosher]

Warum solle man? Bei 1/3 weiß ja jeder, dass es halt ein Bruch ist, der nicht anders darstellbar ist.

Wieso lässt sich das nicht anders darstellen? Mein Taschenrechner kann die Periode darstellen.
Windows kürzt ab und schreibt 0.333333
Wieso nicht auch 0.3 mit Strich über der 3?
Wieso regt sich da keiner auf?
"Man weiß ja, was gemeint ist".
Blöd nur, wenn unterschiedliche Menschen unterschiedliche Maßstäbe ansetzen. Für mich ist bei 14e-39 eben auch "klar, was gemeint ist", weil ich weiß, wo es herkommt.
Und jetzt?


Aber die dritte Wurzel aus 64 ist nur mal runde 4 und vier ist jetzt keine komplexe Zahl. Sorry aber für solche Fehler brauche ich kein Verständnis zeigen, auch wenn es sich nur um ein kleines Betriebssystem-Tool handelt. Der Calculator von Linux Mint macht übrigens keine solch krassen Rundungsfehler, wie machen die das nur...? :uponder:


Aber sicher kann 4 eine komplexe Zahl sein. Nämlich eine, bei der der Imaginärteil 0 ist. Ok, kluggeschissen, du meintest vermutlich etwas anderes mit komplexer Zahl.

Und sicher macht der Linux Mint Calc, sowie viele andere intern auch systematische Fehler, geht halt anders damit um. Oder hat eine Verzweigung drin, die bei einer Berechnung erst prüft, ob es ein ganzzahliges Ergebnis geben wird.
Sobald ein numerisches Verfahren verwendet wird, kommt so gut wie immer eine Ungenauigkeit in's Spiel.



Eher ein schlechtes Beispiel denn beim Multimeter weiß jeder, dass man mit einigen Prozent Messungenauigkeit zu rechnen hat.


Aha und du bestimmst jetzt einfach, was common knowledge zu sein hat.
Ich behaupte, "jeder weiß, dass er bei einem computergestützen Taschenrechnerprogramm mit Rundungs- und Darstellungsfehlern zu rechnen hat"
Und nun?

Es ging bei diesem Beispiel auch nicht direkt um einen praktischen Anwendungsfall, sondern darum, dass eben Kompromisse für sog. "edge cases" eingegangen werden. Vielleicht nicht immer die besten.

Man kann sich halt jetzt daran aufhängen, dass Microsoft zu doof ist, einen Taschenrechner zu programmieren, oder mit entsprechendem Hintergrundwissen verstehen, wie es dazu gekommen ist und für sich selbst bewerten, ob der "Fehler" (Ich möchte ihn eigentlich nicht so bezeichnen) es jetzt wert ist, darüber einen Artikel zu schreiben.

Für den 0815-Anwender, der nicht weiß, wie ein Computerprogramm funktioniert, kann ich noch verstehen, dass er so eine Welle darum macht, beim typischen 3DCler hätte ich eher müdes Achselzucken erwartet.

[Rooter]

Wieso lässt sich das nicht anders darstellen? Mein Taschenrechner kann die Periode darstellen.
Windows kürzt ab und schreibt 0.333333
Wieso nicht auch 0.3 mit Strich über der 3?
Wieso regt sich da keiner auf?
"Man weiß ja, was gemeint ist".
Blöd nur, wenn unterschiedliche Menschen unterschiedliche Maßstäbe ansetzen. Für mich ist bei 14e-39 eben auch "klar, was gemeint ist", weil ich weiß, wo es herkommt.
Und jetzt?Mit der Funktionalität, die M$ ihrem Programm mitgegeben hat - und die die ganzen 10€ Schultaschenrechner haben - läßt es sich nicht anders darstellen. Ich vermute du hast einen Casio fx mit VPAM!?

Aber sicher kann 4 eine komplexe Zahl sein. Nämlich eine, bei der der Imaginärteil 0 ist. Ok, kluggeschissen, du meintest vermutlich etwas anderes mit komplexer Zahl.Stimmt, den wissenschaftlichen Begriff der "komplexen Zahl" habe ich nicht gemeint, ungünstige Wortwahl meinerseits.

Und sicher macht der Linux Mint Calc, sowie viele andere intern auch systematische Fehler, geht halt anders damit um. Oder hat eine Verzweigung drin, die bei einer Berechnung erst prüft, ob es ein ganzzahliges Ergebnis geben wird.
Sobald ein numerisches Verfahren verwendet wird, kommt so gut wie immer eine Ungenauigkeit in's Spiel.Natürlich macht der auch Fehler, der kocht ja sicher auch nur mit 32-Bit-Wasser (nehme ich mal an). Es geht mir um diese krassen Fehler bei simplen Berechnungen wie:
sqr(4) -2 = irgendwas völlig Krummes :ucrazy2:

Aha und du bestimmst jetzt einfach, was common knowledge zu sein hat.
Ich behaupte, "jeder weiß, dass er bei einem computergestützen Taschenrechnerprogramm mit Rundungs- und Darstellungsfehlern zu rechnen hat"
Und nun?Bestimme ich natürlich nicht. Aber jeder der ein Multimeter einsetzt wird ja wohl wissen, dass es nicht perfekt ist!?

Wie oben schon geschrieben, es geht mir nicht darum, dass irgendwo bei der 16. Nachkommastelle das Ergebnis nicht mehr stimmt sondern um diese lächerlichen Fehler bei einfachen Berechnungen die selbst ein 5€ Rechner aus dem Aldi nicht bringen würde.

MfG
Rooter

[Monger]

Es geht mir um diese krassen Fehler bei simplen Berechnungen wie:
sqr(4) -2 = irgendwas völlig Krummes :ucrazy2:

Ist halt so. Bei Gleitkommazahlen ist 4 nicht das gleiche wie 4.0 .

[registrierter Gast]

Ihr driftet hier ein bisschen ab.

90% der Windowsnutzer wissen nicht, was eine Gleitkommazahl ist. Die kennen eine reelle Zahl aus der Schule. Das sind die Zahlen mit einem Komma.
Die Quadratwurzel von 9 ist 3. 3 minus 3 ist 0. Wenn da nicht 0 rauskommt, ist das für 90% der Windowsnutzer ein falsches Ergebnis.

Für die falsche Darstellung könnte man im wissenschaftlichen Modus Verständnis haben. Aber doch nicht im Standardmodus.

Und keiner, wirklich keiner, rechnet im Standardmodus des Windowstaschenrechners irgendwelche Schwingkreise aus.

Also kommen wir zurück zu dem Punkt. Der Taschenrechner hatte ein inkonsistentes Verhalten, sprich Bug, und der wurde nun zurecht gefixt.

[Monger]

Nachtrag, weil da ja offenbar ne Bildungslücke besteht:
https://www.floating-point-gui.de/

Verstanden? Nein? Keine Sorge, geht fast allen Entwicklern so.

[Monger]

Die Quadratwurzel von 9 ist 3. 3 minus 3 ist 0. Wenn da nicht 0 rauskommt, ist das für 90% der Windowsnutzer ein falsches Ergebnis.

Ja. Aber es ist vernünftig zu denken, dass die meisten Windows Nutzer den Taschenrechner nutzen um andere Software mit Werten zu füllen - und dann sind solche Hacks gefährlich. Du brichst halt damit Symmetrien.
Hängt halt extrem davon ab, wozu man rechnet. So trivial das Thema aussieht, so untrivial ist es halt.

[registrierter Gast]

Nachtrag, weil da ja offenbar ne Bildungslücke besteht:
https://www.floating-point-gui.de/

Verstanden? Nein? Keine Sorge, geht fast allen Entwicklern so.
Ich denke mal, dass wissen und verstehen sehr viele in diesem Forum. Du weißt aber anscheinend nicht, wer den Taschenrechner nutzt. Bestimmt nicht Entwickler sondern 0815 Leute. Wenn da 3 - 3 nicht 0 ergibt, dann wissen die, dass da etwas nicht stimmt.

Und es erfordert auch keine rocket science, um diese Problematik zufriedenstellend für den 0815 Nutzer zu lösen. Manchmal benötigt Microsoft nur etwas länger.

[registrierter Gast]

Ja. Aber es ist vernünftig zu denken, dass die meisten Windows Nutzer den Taschenrechner nutzen um andere Software mit Werten zu füllen - und dann sind solche Hacks gefährlich. Du brichst halt damit Symmetrien.
Hängt halt extrem davon ab, wozu man rechnet. So trivial das Thema aussieht, so untrivial ist es halt.
Quatsch hoch zehn. Man kann heutzutage mit beliebiger Genauigkeit rechnen. Wenn 1024 Nachkommastellen 0 sind, dann bricht man da überhaupt keine Symmetrien. Da wird auch keine andere Software mit falschen Daten gefüttert.

[Monger]

Quatsch hoch zehn. Man kann heutzutage mit beliebiger Genauigkeit rechnen. Wenn 1024 Nachkommastellen 0 sind, dann bricht man da überhaupt keine Symmetrien. Da wird auch keine andere Software mit falschen Daten gefüttert.
Mal angenommen du rechnest Wurzel 4 - 2 / 0... Der Windows Taschenrechner spuckt dir jetzt nen Division durch 0 Fehler, andere Programme eine sehr kleine Zahl...
Das meine ich mit Symmetriebruch. Nicht umsonst wurde das Gleitkommaverhalten standardisiert, damit jede Software, jeder Rechner miteinander reden kann.

Wenn man mit anderer Präzision rechnet, muss man das angeben, weil aus der Zahl alleine lässt sich das unmöglich schließen.

[Pinoccio]

Das Problem hier ist, dass der Anwender Operationen zwischen Dezimalzahlen, natürlichen Zahlen und Gleitkommaoperationen durcheinander wirft.
Der Taschenrechner rechnet mit Gleitkommazahlen, und das korrekt.Nein, auch bei Gleitkommazahlen nach IEE754 ist die Wurzel aus 4 ganz genau 2 und nicht irgendwas in der Nähe von 2.
Wurzelberechnungen sind ja jetzt noch keine höhere Mathematik.Kannst du alleine Wurzeln ziehen? (Ohne jetzt die auswendig gelernten Sonderfälle wie sqrt(9)=3.)
Wenn du jetzt die Zahl rundest, wirst du die Leute anpissen die zuverlässige Gleitkommaoperationen erwarten.Aber der Standard IEEE754 fordert doch genau das - Runden! (Nur halt richtig...)
Ist halt so. Bei Gleitkommazahlen ist 4 nicht das gleiche wie 4.0 .? Jede ganze Zahl bis zu einer gewissen Grenze (32 Bit: < 16,777,217, 64 Bit < 9.007.199.254.740.993) wird exakt dargetstellt. Wo liegt dann der Uterrschied zwischen 4 und 4.0?

Nach Standard IEEE754 - und der regelt nun mal Gleitkommazahlen - muss bei sqrt(4) -2 als Ergebnis 0 rauskommen. Alles andere ist nicht Standardkonform.

mfg

[Mosher]

Zu dem Thema fällt mir dann noch folgendes ein:

https://abload.de/thumb/0.1avsnr.jpg (http://abload.de/image.php?img=0.1avsnr.jpg) https://abload.de/thumb/0.03dks0y.jpg (http://abload.de/image.php?img=0.03dks0y.jpg)
Debug-Ansicht eines STM32.

https://electronics.stackexchange.com/questions/210072/why-float-data-type-is-not-accurate-on-a-stm32

[vanquish]

This! :freak: