Jcl Unit test: Mathefrage

[Andreas13]

Hallo,
für dein Beispiel x:= -3.98; sehen meine Ergebnisse wie folgt aus:
AMath.ArcCsc(-3.98) = -0.25397795477090606400
Math.ArcCsc(-3.98) = -0.25397795477090606400
Diff: AMath - Math = -2.71050543121376E-0020 // Fazit: intern sind sie doch unterschiedlich!

Der exakte Wert mittels Multipräzisions-Arithmetik (die ersten 50 Stellen) lautet:

ArcCsc(-3.98) exakt = -0.253977954770906064152801105213402329055852686874

Diff: Exakt - Math = -0.000000000000000000026373915071569760740558348483 8
Diff: Exakt - AMath = 0.000000000000000000000731139240567850109627971537 9

Fazit: AMath. ArcCsc(x) ist um zwei Stellen genauer als Math.ArcCsc(x).

Vergleiche mal das Ergebnis mit JclMath.ArcCsc(X). In welchem Bespiel stimmen die Quadranten nicht?
Gruß, Andreas

[Andreas13]

Wenn ich meine Zahlen mit Deinen vergleiche, habe ich den Verdacht, daß JclMath.ArcCsc(x) nur mit Double-Zahlen arbeitet, oder wenigstens zeigt CheckEquals(..) nur Double-Ergebnisse an.

[Andreas13]

Gerade fällt mir eine wichtige Frage ein: Kompilierst Du für die 32-Bit-Plattform oder für 64-Bit?
Bei 64-Bit gilt LEIDER nämlich

Delphi-Quellcode:

Type 
  Extended = Double;

[TurboMagic]

Hallo,

danke schon mal für deine Mühen!

Aber:

1. das mit 64 Bit und extended = double ist mir grundsätzlich bewußt.
Das war damals der Deal, sonst gäb's unter 64 Bit keine ASM Unterstützung,
gegen die wurde das eingetauscht

2. Du hast meinen letzten Beitrag zum Thema nicht ganz richtig gelsen.
Du hast wie ich am Anfang auch übersehen, dass die eine Zahl mit - als Vorzeichen
und die andere (die von JCLMath) kein Vorzeichen hat, also positiv ist.
Der Unterschied liegt also nicht in irgendwelcher Nachkommastellen-Präzision!

Schaut man sich den Code von JCLMath und von Math an, sieht man auch, dass da ein
unterschiedliches Rechehverfahren benutzt wird.

Nach deinem Test würde ich aber sagen, dass System.Math recht hat. Oder?

[Andreas13]

Hallo TurboMagic,
in der Jedi Code Library wird ArcCsc(X):= ArcSec(X / Sqrt(X * X -1)); verwendet. System.Math benutzt dagegen  ArcCsc(X):= ArcSin(1 / X); , während AMath einen komplexeren Algorithmus unter Verwendung von ArcTan(1/Sqrt(x^2-1))} favorisiert.

Der Vorzeichenfehler rührt von folgendem Sachverhalte her: Die trigonometrischen Funktionen wie Sekans, Kosekans etc. sind periodische Funktionen: d. h. für unendlich viele Argumente x erhalten wir unendlich oft denselben Funktionswert: z.B. für den Kosekans Csc(x) = Csc(x + 2*Pi).

Ihre Umkehrfunktionen ArkusSekans, ArkusKosekans etc. sind jedoch nicht periodisch. Um eine exakte Zuordnung vornehmen zu können, müßten wir die beiden Terme (= diverse Längen am Einheitskreis) aus denen diese Quotienten bestimmt worden sind, vorzeichengerecht kennen. Ansonsten ist eine Umkehrung der Funktion nur auf den Definitionsbereich der umzukehrenden Funktion beschränkt möglich.

Es ist also nicht gleich – um bei Deinem Beispiel zu bleiben – ob x:= -3.98 z.B. so entstanden ist: -3.98/1 = -3.98 oder +3.98/(-1) = = -3.98 etc. Im ersten Fall liegt der 3. Quadrant vor, im zweiten der 4. Quadrant. Je nach dem, über welche Funktion ArcSec(..), ArcSin(..) oder ArcTan(..) die Umkehrfunktion berechnet wird, landen wir mal im 1., mal im 4. Quadranten. Aber ist es kein Problem, schließlich ist z.B. der Arkuskosekans eine sogenannte ungerade Funktion mit der Eigenschaft ArcCsc(+x) = -ArcCsc(-x). Bilde also einfach den Betrag Abs(..) davon, wenn das Minus stört!
Gruß, Andreas

[TurboMagic]

Danke für die Antwort.
Habe den Test so umgebaut, dass die FUnktionsaufrufe jetzt in abs Aufrufe eingefügt wurden. Dann klappt's natürlich.