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

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

[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

[Medium]

Zitat von Rollo62:

Ja, genau dehalb bezeiche ich als "Bug", denn das genaue Verhalten ist ja nicht dokumentiert und bei Single, Double, etc. auch individuell anders.

Genau genommen ist es eigentlich eine wohlbekannte und zwangsweise Folge des Rechnens mit Zahlendarstellungen nach IEEE 754. Braucht man höhere Genauigkeit als diese zusichern, muss man zu entsprechenden Libs greifen die diese Eigenschaften umschiffen.

Zitat:

Das mag sein, mir geht es aber um die Richtigkeit der Ergebnisse.

Nochmal: Die Ergebnisse sind richtig. Die Eingabe in Grad und die Nutzung von binärer Gleitkommaarithmetik verschleiern lediglich die Rundungen die auf dem Weg zum Ergebnis hin notwendigerweise passieren. Wie schon erwähnt wirst du genau genommen (und darum geht es dir ja) es niemals schaffen der tan() Funktion einen Parameter zu übergeben der korrekterweise zu NaN führt, da eben genau diese Parameter schon per Definition eine Wertigkeit haben, die kein x86 Computer der Welt (nativ) korrekt abbilden kann.

Zitat:

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

Das ist schon durch die Nutzung von binären Gleitkommazahlen abgemachte Sache.

[TiGü]

Zitat von Rollo62:

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

Die Frage ist halt auch, wie genau man es braucht? Und wofür wird es gebraucht?
Für komplexe mathematische Geschichten würde ich auf eine externe Bibliothek setzen.
Ob man wirklich den tan-Wert für bspw. 89.9999° braucht sei mal dahingestellt.
Die Genauigkeit, bis wann man welche Eingangswerte behandelt muss man sich vorher überlegen.
Was für Werte hast du denn? Willst du irgendwas darstellen?

Delphi-Quellcode:

const
  FAKTOR = 10000;

procedure Main;
var
  I: Integer;
  Degree, Rad, TanResult: Double;
  LogMsg: string;
  DegArray: TArray<Integer>;
begin
  for I := 89 * FAKTOR to 90 * FAKTOR do
  begin
    Degree := I / FAKTOR;
    Rad := DegToRad(Degree);
    TanResult := Tan(Rad);
    LogMsg := '';
    if InRange(TanResult, -500000, 500000) then
    begin
      LogMsg := Format('Grad: %2.4f - Tan: %2.4f', [Degree, TanResult]);
    end
    else
      LogMsg := Format('Ungültige Eingabe für Tan(%2.4f) - Tan: %2.4f', [Degree, TanResult]) ;

    if LogMsg <> '' then
      Writeln(LogMsg);
  end;
end;