tan() von Single, Double, etc.

[TigerLilly]

Ich bewege mich auf dünnem Eis, weil ich ähnliches vor Jahren mal hatte + nicht weiß, ob es das in der Form jetzt immer noch gibt.

Das Problem damals war, dass das Verhalten des mathematische 8087-Coprozessors maskiert werden konnte und dann warf er bestimmte Exceptions oder eben auch nicht.

Im konkreten Fall wurde eine Division durch 0 durch einen Druckertreiber maskiert, dh ohne Drucken wurde die Exception geworfen, nach dem Drucken wurde sie nicht mehr geworfen. :-/ War cool zum Finden.

Vielleicht gibt es für die mathematischen Routinen was ähnliches.

[Namenloser]

Mal ein paar Gedanken von mir dazu. Ich denke nicht, dass man das als "Bug" beizeichnen kann. Ich nehme an, der Grund, warum der 90°-Fall nicht abgefangen wird, ist, dass die Ergebnisse schon in der Nähe von 90° unbrauchbar (numerisch instabil) werden. Dem muss man sich als Aufrufer einfach bewusst sein. Es führt kein Weg daran vorbei. Es wäre willkürlich, nur den 90°-Fall abzufangen, weil es nur ein Problem aus einer schier unendlichen Menge von Problemen lösen würde. Abgesehen davon, dass schon an der Stelle gar nicht so klar ist, was eigentlich 90° sind, weil Gleitkommazahlen eben meistens nicht exakt sind. Deswegen hast du ja auch dein Epsilon in deinem Code. Aber da stellt sich die Frage: Wie wählt man Epsilon? Und sollte Epsilon wirklich in der Funktion für alle Verwender hardgecoded sein? Oder ist es nicht besser, das dem Aufrufer zu überlassen, so wie es jetzt gelöst ist? Der kann ja seine eigene Wrapper-Funktion schreiben, die speziell auf seine Bedürfnisse angepasst ist, so wie du es auch gemacht hast.

[Medium]

Zitat von Namenloser:

Abgesehen davon, dass schon an der Stelle gar nicht so klar ist, was eigentlich 90° sind, weil Gleitkommazahlen eben meistens nicht exakt sind.

Das schoss mir auch gerade durch den Kopf. Ich bin mir ziemlich sicher, dass alleine schon durch die Umwandlung in eine Gleitkommazahl mit anschließendem DegToRad einiges an systembedingten Rundungsfehlern auftreten, sodass tan() hier gar nicht mit exakt pi/2 aufgerufen wird. Exakt geht es ja eh schon nicht, aber ich bezweifel selbst das hier der theoretisch beste gerundete Wert erreicht wird.
Da der Parameter der zu NaN führen müsste zwangsweise ein für CPUs üblicher Art nicht darstellbarer Wert ist, ist es zu erwarten und völlig korrekt, dass NaN NICHT als Ergebnis vorkommt. Wenn wir schon genau sein wollen, dann aber auch wirklich