tan() von Single, Double, etc.

[Rollo62]

Hallo zusammen,

zu der tan() Funktion ist klar das es Polstellen bei 90° und Vielfachen davon gibt.
Was mir nicht klar ist warum das die tan() Funktion nicht korrekt abbildet.

Delphi-Quellcode:

LSingle := 90.0;
Result := tan ( DegToRag( LSingle ));

Wenn ich das so schreibe erwarte ich als Ergebnis eigentlich Single.NaN.
Stattdessen bekomme ich einen hohen, auch noch negativen Wert, der je nach Single, Double, unterschiedlich ausfällt.
Ist klar warum, weil Pi eben irrational ist, und irgendwo gekürzt ist, aber sollte das nicht abgefangen sein.

Ich schreibe das eigentich singemäß so um, damit es den Erwartungen entspricht:

Delphi-Quellcode:

function MyTan(const ADeg : Single) : Single;
begin
    Result := DegToRad( ADeg);
    if Abs(cos(Result)) > Single.Epsilon) then
        Result := sin(Result) / cos(Result)
    else
        Result := Single.NaN;
end;

Ist aber von der Effektivität vielleicht nicht optimal.


Eigentlich frage ich mich wozu ich die tan() Funktion brauchen soll, wenn ich die nicht zuverlässig nutzen kann.
Ist das ein Bug in den tan() Funktionen oder denke ich nur zu kompliziert ?

Meiner Meinung nach kann man tan() nur nutzen wenn 90° und deren Periodische im Aufruf ausgeklammert werden,
und das MUSS immer im Aufrufer erfolgen.
Hat irgendjemand die Tan() Funktion so im Einsatz, und wie sollte man am Besten die Polstellen abfangen ?

Meinen Ansatz oben sehe ich als Vorteil weil ich das in der Funktion abgefangen haben, und ich am Ergebnis abfragen kann.
So kann sich zumindest ein Fehler nur schwer einschleichen.

Wenn ich das aussen im Aufrufer mache muss ich die Periodizität im Aufrufer beachten mit "mod" o.ä., und es könnten sich
1. bei jeder Nutzung Fehler einschleichen, wenn man die Absicherung mal vergisst, was ich für suboptimal halte.
2. unnötig ineffiziente Abfragen bei jedem Aufrufer einbauen

Eine Option die mir als Lösung sehr sympatisch erscheint wäre ein TryTan(), so in der Art:

Delphi-Quellcode:

function TryTan(const ADeg : Single; var ATan : Single) : Boolean;
begin
    ATan := DegToRad( ADeg);
    if Abs(cos(ATan)) > Single.Epsilon) then
    begin
        ATan   := sin(ATan) / cos(ATan);
        Result := True;
    end
    else
    begin
        ATan := Single.NaN;
        Result := False;
    end;
end;

(Ich mag alle diese Try... Funktionen, auch wenn das vielleicht unter den Puristen verpönt ist,
denn so kann ich immer entsprechend bequem im Aufrufer drauf reagieren, muss es aber nicht)

Wie haltet Ihr das mit dem tangens, würde mich mal interessieren ?


Rollo

[TiGü]

Reicht es nicht, wenn du das Tan-Ergebnis auf größer 1 und kleiner minus 1 prüfst?

Delphi-Quellcode:

program Project3;

{$APPTYPE CONSOLE}

{$R *.res}


uses
  System.SysUtils, System.Math,
  Types;

procedure Main;
var
  I: Integer;
  Degree, Rad, TanResult: Single;
  LogMsg: string;
  DegArray: TArray<Integer>;
begin
  DegArray := [0, 45, 90, 135, 180, 225, 270, 315, 360];
  for I in DegArray do
  begin
    Degree := I;
    Rad := DegToRad(Degree);
    TanResult := Tan(Rad);
    if InRange(TanResult, -1.00001, 1.00001) then
    begin
      LogMsg := Format('Grad: %3.d - Rad: %2.4f - Tan: %2.4f', [I, Rad, TanResult]);
    end
    else
      LogMsg := Format('Ungültige Eingabe für Tan(%3.d) - Rad: %2.4f - Tan: %2.4f', [I, Rad, TanResult])  ;

    Writeln(LogMsg);
  end;
end;

begin
  try
    Main;
    Readln
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

end.

[gammatester]

Zitat von TiGü:

Reicht es nicht, wenn du das Tan-Ergebnis auf größer 1 und kleiner minus 1 prüfst?

Warum sollte tan(60°) = sqrt(3) = 1.732... ungültig sein?

[Medium]

Ich nehme mal stark an, dass man sich dafür entschieden hat den Performance-Weg zu gehen, und sich einfach auf das Ergebnis verlässt das die CPU ausspuckt ohne zusätzliche Prüfungen zu machen. Das halte ich prinzipiell auch für den richtigen Weg bei einem Compiler, da gerade solche Funktionen häufig in zeitkritischen Abläufen genutzt werden. Wer es 100% mathematisch wasserdicht braucht, kann ja wie du es gemacht hast entsprechend darauf aufsetzen. (Ich gebe aber zu, dass es schön wäre wenn sowas dokumentiert würde.)

[Rollo62]

Hallo TiGü,

if InRange(TanResult, -1.00001, 1.00001) then wäre auch eine Alternative, aber du meinst sicher InRage innehalb gewisser Grenzen.
Damit könnte man den gültigen Bereich vorgeben, z.b. +/- 1000000.
Hätte auch seinen Charme, vielleicht auch um herauszufinden von welcher Seite man kommt.
Obwohl ich noch nicht genau den Nutzen/Anwendung sehe.

Trotzdem denke ich das eigentlich der Wert selbst bei 90° einfach mathematisch undefiniert ist,
und dafür wäre der richtige Wert Single.NaN oder besser Single.Infinity.
Weil es aber Infinity nur als PositiveInfinity und NegativeInfinity gibt fände ich NaN an der Stelle korrekter.

Jeder andere Wert wäre doch "falsch".

Rollo

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

[gammatester]

Für Single/Double wird tan(DegToRag(x)) nie eine Exception werfen (wenn Du eine findest darfst Du sie behalten und ich geben Dir symbolisch ein Bier aus).

D.h. wenn es Dir auf Geschwindigkeit ankommt, ist die Sache damit erledigt. (Zu mindest für kleine bis mittlere Winkel).

Wenn Du es genau haben willst, reduzierst Du modulo 360, und wenn dabei 90 oder 270 herauskommt, lieferst Du Nan oder Infinity.

[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

[TiGü]

Zitat von gammatester:

Zitat von TiGü:

Reicht es nicht, wenn du das Tan-Ergebnis auf größer 1 und kleiner minus 1 prüfst?

Warum sollte tan(60°) = sqrt(3) = 1.732... ungültig sein?

Stimmt, ich hätte nicht nur mit den paar Werten mit vielfachen von 45 testen sollen.

Delphi-Quellcode:

program Project3;

{$APPTYPE CONSOLE}

{$R *.res}


uses
  System.SysUtils, System.Math,
  Types;

procedure Main;
var
  I: Integer;
  Degree, Rad, TanResult: Single;
  LogMsg: string;
  DegArray: TArray<Integer>;
begin
  for I := 0 to 360 do
  begin
    Degree := I;
    Rad := DegToRad(Degree);
    TanResult := Tan(Rad);
    if InRange(TanResult, -1000, 1000) then
    begin
      LogMsg := Format('Grad: %3.d - Rad: %2.4f - Tan: %2.4f', [I, Rad, TanResult]);
    end
    else
      LogMsg := Format('Ungültige Eingabe für Tan(%3.d) - Rad: %2.4f - Tan: %2.4f', [I, Rad, TanResult]) ;

    Writeln(LogMsg);
  end;
end;

begin
  try
    Main;
    Readln
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

end.

Die Grenze mit 1000 ist natürlich willkürlich. Muss man je nach gewünschter Genauigkeit anpassen.
Der Windows-Taschenrechner liefert bspw. für tan(90.001°) = -57295,7795...

[Rollo62]

@Namenloser

Zitat:

Dem muss man sich als Aufrufer einfach bewusst sein.

Ja, genau dehalb bezeiche ich als "Bug", denn das genaue Verhalten ist ja nicht dokumentiert und bei Single, Double, etc. auch individuell anders.
Wie du schon sagts, es würde auch das Epsilon fehlen, das muss sich selbst der Aufrufer noch erraten (oder ertesten).

In der Praxis lege ich auch ein Epsilon fest, und selbst dabei kommt man in logische Probleme.
Habe nämlich gerade des Epsilon von 1 nano auf 1 micro hochgesetzt, und selbst das ist bei bestimmten Werten
nicht genug wenn man z.B. millimeter pro meter braucht können große Aubweichungen Auftreten.

Deshalb ist der Vorschlag von TiGü ja interessant, weil ich den Bereich nicht im Eingang sondern im Ausgang festlegen kann.

@gammatester

Zitat:

Für Single/Double wird tan(DegToRag(x)) nie eine Exception werfen

Das mag sein, mir geht es aber um die Richtigkeit der Ergebnisse.
Wahrscheinelich wäre eine Exception sogar sinnvoller als falsche Werte.


Das Ganze hat für mich den Geschmack von "irgendeinen Tod muss man sterben".


Rollo