Warum müsste ein Informatiker eine eigene Version von std :: complex implementieren?

Viele der in der Computerwissenschaft bekannteren C ++ - Bibliotheken wie Eigen , Trilinos und deal.II verwenden das Standardobjekt der C ++ - Headerbibliothek , std::complex<>um komplexe Gleitkommazahlen darzustellen.

In Jack Poulsons Antwort auf eine Frage zu Standardkonstruktoren weist er darauf hin, dass er "aus mehreren Gründen" eine eigene Implementierung von std::complexin Elemental hat . Was sind diese Gründe? Was sind die Vor- und Nachteile dieses Ansatzes?

Ich glaube, diese Diskussion ist mehrfach auf der PETSc-Liste aufgetaucht. Meine Hauptgründe sind:

1. Der C ++ - Standard besagt, dass std :: complex nur für die Datentypen float, double und long double definiert ist. Daher kann es nicht für andere Datentypen wie Quad-Genauigkeit verwendet werden.

2. Die Norm gibt keine Gewähr für die Stabilität der komplexen Arithmetik.

3. Der Standard übernimmt keine Garantie dafür, dass die Daten in einem std :: complex als reale Komponente gefolgt von der imaginären Komponente gespeichert werden. Dies ist für Schnittstellen zu externen Bibliotheken wie BLAS und LAPACK von entscheidender Bedeutung. Dies gilt für alle wichtigen Implementierungen, aber ich würde es vorziehen, dies sicherstellen zu können.

4. Ich bevorzuge es, die realen und imaginären Komponenten direkt manipulieren zu können. std :: complex erschwert dies unnötig.

5. Ich möchte irgendwann eine allgemeinere Version haben, bei der der Datentyp nur ein Ring sein muss, anstatt ein Feld zu benötigen. Dies würde die Gaußschen Ganzzahlen einschließen.

Ich verwende es std::complex<>in meinen Programmen und muss bei jedem neuen Compiler oder Compiler-Upgrade mit Compiler-Flags und Workaround kämpfen. Ich werde versuchen, diese Kämpfe in chronologischer Reihenfolge wiederzugeben:

1. std::norm$|z|^2$$|z|$-ffast-math
2. Der Intel ICC-Compiler unter Linux (oder Linker) wurde std::argunter bestimmten Konfigurationen zu einem Nicht-Opt- Compiler kompiliert (Link-Kompatibilität mit einer bestimmten GCC-Version). Das Problem tauchte zu oft auf und std::argmusste durch ersetzt werden atan2(imag(),real()). Aber es war allzu leicht, dies beim Schreiben von neuem Code zu vergessen.
3. Der Typ std::complexverwendet andere Aufrufkonventionen (= ABI) als der integrierte C99-Komplextyp und der integrierte Fortran-Komplextyp für neuere gcc-Versionen.
4. Das -ffast-mathCompile-Flag interagiert auf unerwartete Weise mit der Behandlung von Gleitkomma-Ausnahmen. Was passiert, ist, dass der Compiler Divisionen aus Schleifen zieht und dadurch division by zerozur Laufzeit Ausnahmen verursacht . Diese Ausnahmen wären niemals innerhalb der Schleife aufgetreten, da die entsprechende Aufteilung aufgrund der umgebenden Logik nicht erfolgte. Das war wirklich schlecht, denn es war eine Bibliothek, die getrennt von dem Programm kompiliert wurde, das die Gleitkomma-Ausnahmebehandlung (unter Verwendung verschiedener Kompilierungsflags) verwendete und auf diese Probleme stieß (die entsprechenden Teams saßen also in entgegengesetzten Teilen der Welt) Dieses Problem verursachte wirklich schlimme Probleme. Dies wurde behoben, indem die vom Compiler verwendete Optimierung mit größerer Sorgfalt von Hand durchgeführt wurde.
5. Die Bibliothek wurde Teil des Programms und verwendete das -ffast-mathCompile-Flag nicht mehr . Nach einem Upgrade auf eine neuere gcc-Version sank die Leistung um einen großen Faktor. Ich habe dieses Problem noch nicht im Detail untersucht, befürchte jedoch, dass es mit Anhang G zu C99 zusammenhängt . Ich muss zugeben, dass ich durch diese seltsame Definition der Multiplikation für komplexe Zahlen völlig verwirrt bin, und es scheint sogar verschiedene Versionen davon zu geben, mit der Behauptung, dass die anderen Versionen falsch sind. Ich hoffe, dass das -fcx-limited-rangeCompile-Flag das Problem lösen wird, da es ein weiteres Problem mit -ffast-mathdieser neueren gcc-Version zu geben scheint .
6. Das -ffast-mathCompile-Flag macht das Verhalten NaNfür neuere Versionen von gcc (auch wenn isnanes betroffen ist) völlig unvorhersehbar . Die einzige Problemumgehung scheint darin zu bestehen, jegliches Auftreten NaNim Programm zu vermeiden , das den Zweck für die Existenz von zunichte macht NaN.

Nun können Sie sich fragen, ob ich die eingebauten komplexen Typen std::complexaus diesen Gründen verwerfen möchte. Ich werde bei den eingebauten Typen bleiben, solange ich bei C ++ bleibe. Für den Fall, dass C ++ für das wissenschaftliche Rechnen völlig unbrauchbar werden sollte, würde ich eher in Betracht ziehen, auf eine Sprache umzuschalten, die die für das wissenschaftliche Rechnen relevanten Aspekte besser berücksichtigt.