Jcl Unit test: Mathefrage

[TurboMagic]

Damit es nicht untergeht dachte ich, ich lagere diese gestern gestellte Frage mal in einen
neuen Thread aus:

In TestJclMath sind einige leere Testmethoden schon mal deklariert, aber noch nicht ausprogrammiert.
Manche davon konnte ich inzwischen ausfüllen (Pull requests sind erstellt), aber diese hier Will
nicht so recht, dummerwise bin ich aber auch kein Mathe-Genie:

Delphi-Quellcode:

procedure TMathTranscendentalTest._ArcCsc;
var
  x: Extended;

begin
  x := -3.98;

  while x < -1 do
  begin
    CheckEquals(Math.ArcCsc(X), JclMath.ArcCsc(X), PrecisionTolerance);
    x := x + 0.1;
  end;

  x := 1.00;

  while x < 4 do
  begin
    CheckEquals(Math.ArcCsc(X), JclMath.ArcCsc(X), PrecisionTolerance);
    x := x + 0.1;
  end;
end;

Die _ArcCsc meckert, dass die Ergebnisse nicht übereinstimmen, obwohl beide verglichenen
Ergebnisse lt. DUnit log-Eintrag identisch sind. Da muss wohl der Fehler noch weiter hinten
in den Nachkommastellen liegen...

PrecisionTolerance: Float = 0.0000001;
Und Log-Meldung: expected: <-0,253977954770906> but was: <0,253977954770906>

Habe jetzt eben erst gesehen, dass das Vorzeichen falsch ist und ein Vergleich von Math.ArcCsc und JclMath.ArcCSc ergibt:
System.Math: Result := ArcSin(1 / X);
JclMath: Result := ArcSec(X / Sqrt(X * X -1));

Wer hat recht?

[TurboMagic]

Und weil wir gerade beim Thema Mathe sind:

Und ArcSec Test der analog zum ArcCsc von mir umgesetzt wurde läuft auch auf einen Fehler und hier
wird das auch in System.Math und JclMath unterschiedlich implementiert, wobei JclMath sogar die
Implementation von System.Math benutzt, wenn ein gewisses Define gesetzt ist.

JclMath: FArcTan(Sqrt(X*X - 1)); aber in ASM programmiert
System.Math: Result := ArcCos(1 / X);

Warum ist die Umsetzung in der JCL so anders?
Was tun?

[Andreas13]

Hallo TurboMagic,

da ich die Jcl Unit selber nicht benutze, konnte ich für Dich nur eine Gegenüberstellung zwischen der von mir präferierten hochpräzisen Mathe-Bibliothek AMath von Wolfgang Ehrhardt (Gammatester) und der Standard-Delphi-Unit Math machen.

Füg doch mal folgende Zeile in Deinen Code ein:
WriteLn('Differenz = ', Math.ArcCsc(X) - JclMath.ArcCsc(X)); Der Unterschied zwischen obigen Mathe-Units liegt bei mir zwischen
-2.71050543121376E-0020 … 5.42101086242752E-0020

Die von Dir angegebene PrecisionTolerance: Float = 0.0000001; ist für Real-Zahl-Arithmetik ist „lasch“. Selbst Math.SameValue(..) verwendet einen viel geringeren Wert.

Ich kann nicht beurteilen, ob JclMath besser ist als Math. Was ich definitiv weiß, AMath von unserem leider zu früh verstorbenem Gammatester liefert stets auf 19 Nachkommastellen exakte Werte.
Gruß, Andreas

[TurboMagic]

Danke schon mal für die Antwort, nur:
wenn ich für diesen Test die Toleranz auf einen noch kleineren Wert umstelle,
dann wird ja das Problem, dass die beiden Werte als ungleich angesehen werden
eher größer, oder täusche ich mich da?

Außerdem ist ja das Problem, dass ein komplett unterschiedliches Vorzeichen rauskommt.
Also eine der beiden Parteien liefert wohl das Ergebnis, aber im falschen Quadranten.
Das ist doch das Hauptproblem.

Nur wer von den beiden ist es?

[Andreas13]

Ja, natürlich: Wenn Du die Toleranz verkleinerst, wird eine noch geringere Abweichung als bedeutsam ausgewiesen. Vermutlich sind grobe Fehler in JclMath vorhanden. Könntest Du bitte den Quellcode der Implementierung der Funktion JclMath.ArcCsc(x: Extended) posten? Und Dein konkretes Zahlenbeispiel, in dem die falschen Quadranten rauskommen?
Gruß, Andreas

[TurboMagic]

Hier das Zahlenbeispiel:

Not equals for x = -3,98, expected: <-0,253977954770906> but was: <0,253977954770906>