OptiVec   Version 8 für C/C++,  Delphi und Lazarus
OptiCode Dr. Martin Sander Software-Entwicklung Brahmsstr. 6 D-32756 Detmold http://www.optivec.de e-mail: optivec@gmx.de	Teil I.A: Handbuch

Dieses HANDBUCH beschreibt die Grundlagen der OptiVec-Bibliotheken und gibt einen Überblick über VectorLib, den ersten Teil von OptiVec. Das objekt-orientierte Interface VecObj wird in Kap. 3 beschrieben. Die übrigen Teile von OptiVec werden in separaten Dateien dokumentiert, siehe MATRIXD.HTM und CMATHD.HTM.
Kap. 1.2 der vorliegenden Datei enthält die Lizenz-Bedingungen der Shareware-Version, Kap. 1.3 diejenigen der registrierten Vollversion.
 
OptiCode™ und OptiVec™ sind Warenzeichen von Dr. Martin Sander Software-Entwicklung. Andere zum Zwecke der Identifikation hier erwähnte Warenzeichen sind Eigentum der jeweiligen Hersteller.
 

Inhaltsverzeichnis

1. Einführung

Dem Ziel der Vereinfachung dienen zwar bereits seit mehr als zwei Jahrzehnten auch die Feldfunktionen von Fortran90 und templatisierte Vektor-Klassen in C++, doch sind dies lediglich Abkürzungen, die vom Compiler wieder in Schleifen übersetzt und entsprechend ineffizient verarbeitet werden. (Ähnliches gilt für die meisten der populären BLAS-Bibliotheken für Fortran). Demgegenüber bietet OptiVec eine hochoptimierte, in Assembler geschriebene Lösung, deren Geschwindigkeit nicht mehr durch die Qualität des Compilers, sondern nur noch durch die echte Geschwindigkeit des Prozessors bestimmt wird. Gegenüber compiliertem Code ergibt sich ein durchschnittlicher Geschwindigkeitsvorteil von einem Faktor 2 bis 3 (für einige Funktionen auch bis zu 8).

Nach unserem Kenntnisstand war OptiVec beim Erscheinen 1996 die erste umfassende Vektor- und Matrix-Bibliothek für PC-Compiler, die praktisch vollständig in Maschinensprache geschrieben wurde.

OptiVec tritt in Konkurrenz zu etlichen teuren integrierten Programmsystemen für wissenschaftliche und Datenverarbeitungs-Anwendungen, ist aber eben nicht ein "geschlossenes" integriertes Paket, sondern zur Verwendung mit den gängigen Programmiersprachen bestimmt, wodurch dem OptiVec-Benutzer die Flexibilität seiner bevorzugten Programmierumgebung erhalten bleibt.

Hier einige Stichworte:

• Alle Operatoren und mathematischen Funktionen von C/C++ und Pascal/Delphi sind in vektorisierter Form implementiert; zusätzlich sind viele weitere mathematische Funktionen aufgenommen, die sonst als mehr oder weniger komplizierte Kombination existierender Funktionen berechnet werden müßten. Ausführungsgeschwindigkeit und numerische Genauigkeit werden hierdurch stark verbessert.
• MatrixLib deckt einen großen Bereich optimierter Matrix-Funktionen ab: Arithmetik, Algebra, Faktorisierungen, Daten-Anpassungen usw.
  TensorLib ist als spätere Erweiterung dieser Konzepte auf multidimensionale Felder geplant.
• Fast-Fourier-Transform-Techniken für effiziente Faltungen/Entfaltungen, Korrelations- und Spektralanalysen, Filterung etc. sind sowohl für ein- als auch zweidimensionale Felder enthalten.
• Es gibt zahlreiche Bausteine für statistische Analyse.
• Ableitungen, Integrale, Interpolationen werden durch die Analysis-Funktionen von VectorLib berechnet.
• Graphik-Funktionen für Plots in cartesischen Koordinaten erlauben die Darstellung von Vektor- und Matrix-Daten.
• Alle Funktionen haben eine übersichtliche, intuitiv verständliche und einfache Syntax.
• Jede Funktion existiert für jeden Daten-Typ, für den dies sinnvoll ist, also meist für alle Ganzzahl-Typen, alle reellen und häufig auch komplexen Fließkomma-Typen. Der Datentyp wird einfach durch das Präfix des Funktionsnamens bestimmt. In der C/C++-Version werden keine impliziten Namensergänzungen ("name mangling") oder andere spezifische Eigenschaften von C++ verwandt. Dadurch kann OptiVec in C ebenso wie in C++ benutzt werden, und dadurch wird gewährleistet, daß Funktionsnamen und -syntax in den OptiVec-Versionen für C/C++ und Pascal/Delphi weitestgehend identisch sind.
• Die Eingabe- und Ausgabe-Vektoren und -Matrizen von OptiVec-Funktionen sind von variabler Größe, und es ist möglich, auch nur einen Teil (z.B. die ersten 100 Elemente, jedes 10. Element usw.) eines Vektors zu verarbeiten – ein weiterer Vorteil gegenüber anderen Ansätzen, bei denen nur ganze Felder verarbeitet werden können.
• Ein objekt-orientiertes Interface für C++, VecObj kapselt alle Vektorfunktionen und bietet noch einfachere Syntax sowie verbesserte Sicherheit der Speicherzugriffe.
• Der Einsatz von OptiVec-Funktionen anstatt Schleifen erlaubt es, Quellcode viel kompakter und lesbarer zu gestalten.
• Zusätzlich zu den komplexen Vektor- und Matrix-Routinen bietet CMATH eine Bibliothek Funktionen für skalare komplexe Zahlen aller drei Fließkomma-Genauigkeiten, sowohl in cartesischen als auch in Polarkoordinaten. Im Vergleich zu anderen erhältlichen komplexen Klassenbibliotheken sowie der Unit Complex von Delphi (bzw. UComplex von Lazarus) ist CMATH durch seine Implementierung in Assembler wesentlich schneller, genauer und stabiler. Außerdem benötigt die C/C++-Version nicht unbedingt C++, sondern kann auch in klassischen C-Modulen verwendet werden (dann mit typenspezifischen Funktions-Präfixen).

Der große Funktions-Umfang, die hohe numerische Genauigkeit und die Einfachkeit der Benutzung machen OptiVec zu einem wertvollen Programmierwerkzeug für wissenschaftlich-technische Datenverarbeitungs-Anwendungen.

Die vorliegende Dokumentation beschreibt die Implementierungen von OptiVec für

• Embarcadero / Borland / CodeGear C++ (alle Versionen von RAD Studio, Borland C++ Builder; sogar Borland C++ Version 5.0 funktioniert noch immer) unter 64-bit oder 32-bit Windows.
• Microsoft Visual C++ (alle Versionen von Visual Studio und Visual C++ bis hinab zu Visual Studio 2005) sowohl für 32-bit als auch für 64-bit-Windows auf PC-Plattformen
• GCC (jeweils aktuelle Version) sowohl für 32-bit als auch für 64-bit-Windows auf PC-Plattformen
• LLVM CLang (jeweils aktuelle Version) sowohl für 32-bit als auch für 64-bit-Windows auf PC-Plattformen
• Delphi 12, 11.x, 10.x, XE-Serien, Version 2010, 2009 für Win32 und Win64 (nicht aber für .NET!)
• Lazarus / FreePascal, ausschließlich 64-bit Windows-Plattform.
• Linux mit GCC oder LLVM CLang (nur 64-bit)

1. Shareware-Versionen
   Es ist nur eine Auswahl an Bibliotheken enthalten:
   1. 64-bit: P8D (Allzweck-Debug-Version, kompatibel bis hinab zu Core2 und AMD64) und
      P9M (Automatisches Multi-Threading, verlangt aktuelle Prozessoren ab Intel Haswell oder AMD Excavator).
   2. 32-bit: P4D (Allzweck-Debug-Version für größtmögliche Prozessor-Kompatibilität bis hinab zu 486DX / Pentium / Athlon).
      Diese Version läuft auf allen 32-bit-Windows-Betriebssystemen sowie im 32-bit-Modus von 64-bit-Windows.
   3. 32-bit Multi-Prozessor-Bibliothek für den Einsatz auf AMD64 x2, Core2 Duo oder deren Mehrkern-Nachfolgern. Außer der durch automatische Verteilung der Rechenlast auf die vorhandenen Prozessorkerne (Auto-Threading) bewirkten Effizienz-Steigerung wird noch zusätzlich durch Einsatz der sog. SSE- und SSE2-Befehle eine Geschwindigkeitssteigerung vieler Fließkomma-Operationen erzielt. Außer Bereichs-Fehlern (DOMAIN) werden alle anderen mathematischen Fehler (Überlauf, Singularität, Genauigkeits-Verlust) ohne Meldung "stillschweigend" durch Setzen des für jede Funktion angegebenen Standardwertes abgefangen.
2. Vollversionen
   Die Bibliotheken sind in vier Prozessor-Versionen enthalten:
   • P4 (größtmögliche Prozessor-Kompatibilität bis hinab zu 486DX / Pentium / Athlon; Benutzung der FPU fü maximale Fließkomma-Genauigkeit und -Sicherheit; für alle 32-bit-Windows-Versionen)
   • P8 (ab Core2xxx oder AMD64xxx)
     Einsatz von SSE, SSE2, SSE3 für deutliche Beschleunigung.
   • P9 (Up-to-date-Prozessoren, ab Intel Core i "Haswell" oder AMD "Excavator")
     nochmals deutliche Beschleunigung durch Einsatz von AVX, AVX2 und FMA3. Diese wird jedoch nur für "schwergewichtige" Funktionen wie VF_FFT tatsächlich erzielt, während der Gebrauch der P9-Bibliothek in Apps mit überwiegend "leichtgewichtigen" Funktionen wie VF_addC, VF_round usw. sogar zu einem Performance-Verlust gegenüber P8 führen kann, weil manche Prozessoren auf Verwendung von AVX2 mit Down-Clocking reagieren! Außerdem profitieren AMD-basierte Computer deutlich weniger als Intel-basierte von dem P9-Bibliotheken, weil (vereinfacht gesagt) Intel der schnellen 256-byte-Einheit eine höhere Priorität einrämt, während AMD die Transistoren eher in eine höhere Zahl von Prozessor-Kernen investiert.
   Diese Versionen sind nochmals unterteilt:
   • Normalversion:
     Optimiert für die Verarbeitung von kleineren Vektoren mit bis zu einigen 100 Elementen und für Anwendungen, die mit nur einem Thread laufen sollen.
   • Debug-Version mit Überprüfung von Dimensions-Konsistenz:
     Um meist sehr schwer zu lokalisierende Speicherfehler zu vermeiden, die durch die Verletzung von Vektor- oder Matrix-Begrenzungen entstehen können, überprüft diese Debug-Version alle in OptiVec-Routinen verarbeiteten Vektoren und Matrizen auf Konsistenz von tatsächlicher und in der jeweiligen Funktion angenommener Größe. Es ist sehr anzuraten, in den anfänglichen Entwicklungs-Stadien einer Anwendung diese Debug-Bibliotheken einzubinnden und erst dann zu den effizienteren Hochleistungs-Bibliotheken zu wechseln, wenn sichergestellt ist, dass keine Speicherfehler mehr übersehen worden sind. Außerdem werde Überlauf-, Singularitäts- und Genauigkeitsverlust-Fehler auf herkömmliche Weise durch eine Fehlermeldung angezeigt (dies im Gegensatz zu den übrigen Bibliotheks-Versionen, die seit Version 6.1 solche Fehler "stillschweigend" durch Setzen des in der Dokumentation jeder Funktion angegebenen Standard-Ergebnisses behandeln.)
   • Multi-Prozessor-Version:
     Für große Vektoren und Matrizen kann die Rechenlast auf mehrere Prozessor-Kerne verteilt und hierdurch theoretisch eine Vervielfachung der Rechenleistung erzielt werden. Die Multi-Prozessor-Version erzeugt daher zusätzliche Arbeits-Threads, die wiederum vom Betriebssystem den vorhandenen Prozessor-Kernen zugeordnet werden. Bei jedem Funktionsaufruf wird geprüft, ob die Verteilung sinnvoll vorgenommen werden kann (Auto-Threading).
     Ob sich der Einsatz der Multi-Prozessor-Version lohnt, hängt sehr stark von der Art der durchgeführten Berechnungen ab. Der Grund hierfür ist der mit Auto-Threading verbundene Aufwand für die Kommunikation zwischen den verschiedenen Threads. Er kann erst ab einer gewissen Mindestgröße der Vektoren und Matrizen "zurückverdient" werden. Für transzendente Funktionen von komplex-zahligen Vektoren ist dies bereits ab einer Größe von ca. 60-80 Elementen der Fall, während die Performance etwa von VF_addV allenfalls ab ca. 10 000 Elementen mit der Zahl der Prozessor-Kerne skaliert (oder auch gar keine Beschleunigung erfährt, wenn der Speicher langsamer ist als die CPU). Im Einzelfall kann die Entscheidung zwischen der Normal- und der Multiprozessor-Version häufig nur durch Ausprobieren getroffen werden.
     Eine mit der Multi-Prozessor-Bibliothek gebundene Anwendung kann problemlos auf einem Ein-Kern-Prozessor laufen. Sie wird allerdings (durch den hier ja völlig sinnlosen Aufwand der Thread-Verteilung) in der Regel 10-20% langsamer ausgeführt als mit der Normal-Bibliothek.
   • CUDA-Version (derzeit nur für Windows):
     Dies ist eine Multi-Prozessor-Version, die noch einen Schritt weitergeht: Sie prüft, ob die Verarbeitung großer Vektoren / Matrizen auf den Prozessor einer CUDA-fähigen Graphik-Karte ausgelagert werden kann. Um diese Bibliotheks-Version zu nutzen, muss natürlich erst einmal eine solche CUDA-Karte (oder Tesla- bzw. Fermi-Board) des Herstellers nVidia vorhanden sein. Außerdem müssen Sie sichergehen, stets den neuesten Treiber (herunterzuladen von www.nvidia.com) zu installieren. Bereits eine billige Graphik-Karte für unter 80 EUR kann bestimmte Operationen mehr als 10-fach beschleunigen; Hochleistungs-Karten (etwa die typischerweise im Gaming-Bereich verwendeten) bringen eine noch weit höhere Beschleunigung! Auf der anderen Seite ist es nicht immer ganz einfach, diese Version zum Laufen zu bringen; daher empfehlen wir sie auch nur zum Gebrauch auf dem eigenen Rechner, nicht aber für Anwendungen, die an andere weitergegeben werden.

Besonderheiten der Versionen für die einzelnen Compiler

• C++ Builder, Embarcadero / CodeGear / Borland C++:
  Sie müssen zwei Bibliotheken einbinden: eine Basis-Bibliothek, die für die jeweilige Compiler-Version und -Konfiguration spezifisch ist, sowie eine Prozessor-spezifische zweite Bibliothek. Beispielsweise würden Sie für den klassischen bcc32-Compiler mit statischer BC-Laufzeitbibliothek und mit breitestmöglicher Prozessor-Unterstützung VCFS.LIB + VCF4W.LIB einbinden. Details zur Bibliotheks-Auswahl finden Sie in Kap. 1.4
• Microsoft Visual C++:
  Die Shareware-Version ist für "multi-thread Debug" und "multi-thread DLL Debug". Die Vollversion enthält zusätzlich die zugehörigen Release-Bibliotheken.
• GCC und LLVM CLang (Windows):
  Abweichend von den Bedingungen für die kommerziellen Compiler stellen wir für die freien Compiler die 32-bit P4D- und die 64-bit P8D-Bibliothek als Freeware zur Verfügung.
  nur GCC: Sowohl für 32-bit als auch für 64-bit werden die gängigen Konfigurationen von GCC mit jeweils einer eigenen Basis-Bibliothek abgedeckt, also Windows- bzw. Posix-Threads und hierfür jeweils die Auswahl zwischen SEH-, Dwarf- oder Setjmp-Longjmp-Exceptions.
• GCC und LLVM CLang (Linux):
  Auch hier steht die 64-bit P8D-Bibliothek als Freeware zur Verfügung.
  Für Single-Thread und Multithread-Anwendungen werden verschiedene Basis-Bibliotheken benötigt: ovlxcbase64s.a bzw. ovlxcbase64m.a.
• Delphi:
  Jede Delphi-Version erfordert ihre eigene zugehörige OptiVec-Version.
• Lazarus / FreePascal:
  Alle OptiVec-Routinen sind als cdecl deklariert und müssen in korrekter Groß- und Kleinschreibung angegeben werden. Technischer Grund hierfür ist, dass Lazarus bei den übrigen Aufruf-Modellen die Namen mit Datentyp-Informationen "dekoriert" und daher die in Assembler geschriebenen und als Object-Dateien gelieferten Routinen nicht finden würde.

Zurück zum Inhaltsverzeichnis

1.1 Warum sich vektorisierte Programmierung auf dem PC lohnt

Vektorisierung war schon immer die Zauberformel für Supercomputer mit ihren aus vielen einzelnen Prozessoren gebildeten Parallel-Architekturen. Auf diesen Architekturen wird versucht, die Rechenlast möglichst gleichmäßig auf alle Prozessoren zu verteilen und so die Ausführungsgeschwindigkeit zu maximieren. Die sogenanten "divide and conquer"-Algorithmen spalten kompliziertere numerische Aufgaben in kleine Schleifen über Vektorelemente auf. Hochgezüchtete Compiler finden dann den effizientesten Weg für die Verteilung der Vektor-Elemente auf die Prozessoren. Viele Compiler für Supercomputer enthalten bereits große Bibliotheken vordefinierter Vektor- und Matrixfunktionen für viele Anwendungszwecke. Diese Vektor- und Matrixfunktionen bieten den besten Weg, maximalen Datendurchsatz zu erzielen.

Es ist offensichtlich, daß die massive Parallelverarbeitung einer Cray auf den meisten PCs mit ihren eher bescheidenen 2, 4 oder allenfalls 8 Prozessor-Kernen nicht in gleicher Weise möglich ist. Auf den ersten Blick mag es daher sinnlos erscheinen, das Konzept der vektorisierten Programmierung auch auf dem PC anzuwenden. Tatsächlich aber sind auch viele vektor-spezifische Optimierungen möglich, selbst wenn nur eine CPU vorhanden ist. Viele dieser Optimierungen können von heutigen Compilern nicht direkt durchgeführt werden. Stattdessen muß der Programmierer auf Maschinensprachen-Niveau heruntergehen. Hand-optimierte, in Maschinensprache geschriebene Vektorfunktionen übertreffen compilierte Schleifen in der Geschwindigkeit durchschnittlich um einen Faktor von 2-3. Dies bedeutet, daß Vektorisierung die Mühe sehr wohl lohnen kann, auch für PC-Programme.

1.1.1 Allgemeine Optimierungs-Strategien von OptiVec

Hier sind die wichtigsten Optimierungs-Strategien, die in OptiVec zur Steigerung der Performance auf eingesetzt werden – unabhängig von der Zahl der Prozessor-Kerne:

Preload von Konstanten
Anstatt Konstanten für jeden einzelnen Funktionsaufruf innerhalb einer Schleife neu zu laden und wieder zu entladen, werden sie nur einmalig zu Beginn einer Vektor-Funktion geladen und stehen für die Verarbeitung sämtlicher Vektor-Elemente zur Verfügung.

Volle XMM- und FPU-AusnutzungWo immer nötig und sinnvoll, werden alle acht XMM-Register (in der 64-bit-Version sogar sechzehn) bzw. alle acht Coprozessor-Register eingesetzt (für einen Compiler ist es schon eine hervorragende Leistung, die Buchführung für vier Coprozessor-Register zu beherrschen).

Prefetch von Gruppen von Vektor-Elementen
Ab dem Pentium III stehen sehr nützliche "Prefetch"-Befehle zur Verfügung, die es erlauben, Daten schon genügend im voraus aus dem Hauptspeicher in den Prozessor zu laden, so daß sie gleich zur Verfügung stehen, wenn sie verarbeitet werden sollen.

Verwendung von SIMD-Befehlen
Man mag sich wundern, warum diese Strategie nicht gleich an erster Stelle genannt ist. Seit Einführung der SSE oder "Streaming Single-Instruction-Multiple-Data Extensions" mit dem Pentium III und zahlreichen Verbesserungen und Erweiterungen in jeder neuen Prozessor-Generation ist hier explizite Unterstützung für Vektor-Programmierung gegeben. Auf den ersten Blick sollten sie also die Vektor-Programmierung auf dem PC geradezu revolutionieren. Angesichts einer immer noch vorhandenen Diskrepanz zwischen Prozessor- und Datenbus-Geschwindigkeit sind aber viele der einfachen arithmetischen Operationen in ihrer Geschwindigkeit durch den Datenfluß begrenzt. Hier können SIMD-Befehle nur noch zu einem geringeren Geschwindigkeitsvorteil führen, als man eigentlich erwarten würde. Für kompliziertere Operationen wiederum können SIMD-Befehle oft gar nicht verwendet werden, wenn nämlich entweder bedingte Verzweigungen für jedes Vektor-Element individuell erforderlich sind, oder auch dann, wenn ohne die interne extended-Genauigkeit der FPU umständlichere Algorithmen gewählt werden müßten. OptiVec macht daher von den SSE-Befehlen überall dort Gebrauch, wo ein wirklicher Geschwindigkeitsvorteil erzielt werden kann. Man beachte allerdings, dass Operationen wie Matrix-Multiplikation oder Fourier-Transformation in float-Präzision zugunsten des hier möglichen erheblichen Geschwindigkeitsgewinnes einen Genauigkeitsverlust von 1-2 Stellen in Kauf nehmen. Wer demgegenüber auf maximale Genauigkeit Wert legen muss, sollte daher stets die ausschließlich FPU-Befehle verwendende P4-Version einsetzen.

Superscalar schedulingDurch sorgfältige Anordnung der Befehls-Folge können die parallelen Integer-Pipes und fadd/fmul-Einheiten moderner Prozessoren (seit Pentium) bestmöglich ausgenutzt werden.

Loop-unrolling
Auch dort, wo SIMD-Befehle nicht angewandt werden können oder wo eine optimale Ausnutzung der parallelen Prozessor-Pipes nicht für einzelne Vektor-Elemente erzielt werden kann, werden die Vektor-Elemente oft zu zweit, zu viert oder noch mehreren verarbeitet. Hierdurch werden einerseits die parallelen Pipes beschäftigt, andererseits auch der relative Anteil des Schleifen-Managements an der gesamten Ausführungszeit zurückgedrängt. Im Zusammenhang mit den oben beschriebenen "Prefetch"-Mechanismen wird die Schleifengröße möglichst an die Cache-Zeilengröße angepaßt.

Vereinfachte Adressierung
Die Adressierung von Vektor- und erst recht von Matrix-Elementen stellt noch immer eine Hauptquelle für ineffizienten Code heutiger Compiler dar. Durch Hin- und Herschaltung zwischen Eingabe- und Ausgabe-Vektoren wird eine große Zahl redundanter Adressierungs-Operationen ausgeführt. Durch die ebenso strikte wie einfache Definition "Verarbeitung von hier bis da" können die OptiVec-Funktionen den Aufwand für die Adressierung von Array-Elementen auf das nötige Minimum reduzieren.

Ersatz von Fließkomma- durch Ganzzahl-Befehle
Eine Reihe von Fließkomma-Operationen (wie Kopieren, Austauschen, Vergleich mit Sollwerten) kann wahlweise mit Ganzzahl- oder Fließkomma-Prozessorbefehlen implementiert werden. Hier wird natürlich die jeweils schnellste Methode angewandt.

Strikte Genauigkeits-Kontrolle
C/C++-Compiler wandeln eine float-Zahl oft in double um – 32-bit-Pascal/Delphi sogar in extended – bevor sie an eine mathematische Funktion übergeben wird. Diese Behandlung war einmal sinnvoll, als Festplattenspeicher zu teuer war, um in den .LIB-Dateien separate Funktionen für alle Datentypen einzuschließen. Auf heutigen PCs ist sie schlicht ineffizient. Konsequenterweise werden in den OptiVec-Routinen keine solchen impliziten Umwandlungen durchgeführt. Hier wird eine float-Funktion auch nur in float- (also einfacher) Genauigkeit berechnet, unter Verzicht auf die soundsovielte Stelle nach dem Komma, die ohnehin sofort wieder abgeschnitten wird. Zusätzlich kann V_setFPAccuracy( 1 ); aufgerufen werden, um die FPU auf einfache Genauigkeit umzuschalten, falls man sich generell mit dieser begnügen möchte. Hierdurch kann die Ausführungsgeschwindigkeit etwas gesteigert werden. Seien Sie aber darauf gefasst, dass die Genauigkeit Ihrer Endergebnisse noch deutlich unter der float-Spezifikation liegen kann, wenn schon die Zwischenergebnisse nur einfach-genau berechnet werden. Details werden bei V_setFPAccuracy aufgeführt.

Inline-Coding
Alle externen Funktionsaufrufe sind aus den Schleifen eliminiert. Dadurch wird die Ausführungszeit der "call / ret"-Paare sowie die Zeit für die Übergabe der Funktionsargumente eingespart.

Cache-line-Matching lokaler Variablen
Der Level−1-Cache aktueller Prozessoren ist in Zeilen von je 64 Byte organisiert (bei den Vorgängern waren es 32 Byte). Viele OptiVec-Funktionen benötigen doppelt- oder extended-genaue Variablen auf dem Stack (vor allem für Ganzzahl/Fließkomma-Umwandlungen oder für Bereichsprüfungen). 32-bit-Compiler und -Linker richten den Stack an 4-Byte-Grenzen aus. Es besteht also die Gefahr, dass die 8 Bytes einer double oder die 10 bytes einer extended beim Speichern auf dem Stack eine 64-Byte-Grenze überschreiten. Dies wiederum würde zu starken Geschwindigkeits-Einbußen durch Cache-Zeilenumbrüche führen. Um diese zu vermeiden, richten alle OptiVec-Funktionen, für die dies eine Rolle spielt, ihre lokalen Variablen an 8-Byte- (für double), 16-Byte- (für extended) bzw. 64-Byte-Grenzen aus (XMM- und YMM-Werte).

Ungeschützte und bereichsreduzierte Funktionen
OptiVec bietet alternative Formen einiger mathematischer Funktionen, bei denen man zwischen der geschützten Variante mit Fehlerbehandlung und einer ungeschützten Variante ohne Fehlerdetektion währen kann. In einigen Funktionen, die ganzzahlige Potenzen ausrechnen, erlaubt die Abwesenheit der Fehlerdetektion eine viel effizientere Codierung. Ähnliches gilt für die Sinus- und Cosinus-Funktion für mit Sicherheit zwischen -2p und +2p liegenden Argumenten. In diesen Spezialfällen kann die Ausführungszeit um bis zu 40% reduziert werden, abhängig von der Hardware-Umgebung. Dieser Geschwindigkeitsgewinn wird allerdings durch erhöhtes Risiko erkauft: Falls auch nur ein einziges Vektorelement außerhalb des gültigen Bereiches liegt, stürzen die ungeschützten und bereichsreduzierten Funktionen ohne Warnung einfach ab.

1.1.2 Multi-Prozessor-Optimierung

Multithread Support
Moderne Betriebssysteme erlauben es, innerhalb eines Programmes parallel laufende Threads auf die vorhandenen Prozessorkerne zu verteilen so die Performance gegenüber Single-Thread-Verarbeitung zu vervielfachen. Hierfür muß aber sichergestellt sein, daß in parallelen Threads laufende Funktionen sich nicht gegenseitig ihre Zwischenergebnisse überschreiben. Mit sehr wenigen Ausnahmen (namentlich den Plotting-Funktionen) sind alle übrigen OptiVec-Funktionen re-entrant, also darauf ausgerichtet, parallel zueinander laufen zu können.

Bei der Entwicklung Ihrer Multi-Thread-Anwendung stehen Ihnen zwei grundsätzlich verschiedene Optionen zur Verfügung: Funktionale Parallelität und Daten-Parallelität.

Funktionelle Parallelität
Verschiedene Threads führen verschiedene Aufgaben aus – sie unterscheiden sich in ihrer Funktion. Als Beispiel denke man an eine Anwendung, bei der ein Thread Benutzer-Ein- und Ausgaben abarbeitet, während ein anderer Thread Hintergrund-Berechnungen durchführt. Selbst auf einer Ein-Kern-CPU kann diese Art des Multi-Threading durch die vom Betriebssystem bewirkte ständige Umschaltung zwischen den beiden Threads Vorteile bieten (z.B., dass das Benutzer-Interface nicht blockiert, während die Hintergrundberechnungen ausgeführt werden, sondern weiterhin Eingaben annehmen kann). Auf einem Mehr-Prozessor-Computer können die zwei (oder mehr) Threads tatsächlich gleichzeitig auf den verschiedenen Prozessor-Kernen laufen. Normalerweise ist die Lastverteilung zwischen den Prozessoren bei funktionellem Multi-Threading alles andere als perfekt: Oft läuft ein Prozessor unter Volllast, während ein anderer arbeitslos auf Eingaben wartet. Dennoch ist diese Art des Multi-Threading die beste Option für Anwendungen, die nur kleine bis mittelgroße Vektoren und Matrizen umfassen.

Daten-Parallelität
Um die Lastverteilung zwischen den vorhandenen Prozessor-Kernen zu verbessern und so den Datendurchsatz zu maximieren, kann die klassische Parallelverarbeitung angewandt werden: Die Daten-Vektoren und -Matrizen werden in kleinere Teile zerlegt, und jeder Thread arbeitet einen solchen Teil ab. Die Brauchbarkeit dieses Ansatzes wird dadurch beschränkt, dass der Aufwand für die Verteilung der Daten auf die verschiedenen Threads und für die dabei nötige Kommunikation der Threads untereinander ziemlich hoch ist. Außerdem lassen sich die Daten niemals vollständig parallelisieren; es verbleibt immer ein gewisser Teil der Aufgaben, der nur sequentiell abgearbeitet werden kann. Daher lohnt sich Daten-Parallelität nur für größere Vektoren und Matrizen. Typische Schwellen-Größen, ab denen die Leistung mehrerer Prozessoren den für die Verteilung auf sie nötigen Aufwand "zurückverdient", reichen von unter 100 (bei mathematischen Funktionen komplex-zahliger Vektoren) bis zu über 10.000 Elementen (bei den einfachen arithmetischen Funktionen). Erst wenn die Vektoren / Matrizen deutlich größer als diese Schwellenwerte sind, kommt die erhöhte Leistung voll zum Tragen. Dann erst nähert sich die Beschleunigung dem theoretischen Grenzwert einer Verdopplung, Vervierfachung usw. an.

1.1.3 Unterstützung für CUDA-Hardware

• Einleuchtenderweise können die cudaOptiVec-Bibliotheken nur mit CUDA-fähiger Hardware benutzt werden. Das bedeutet, dass nur Graphikkarten und Boards von NVIDIA unterstützt werden.
• Schon Graphikkarten für unter 80 EUR können die Performance für einige Funktionen um einen Faktor von 10 steigern, Hochleistungs-Karten noch um wesentlich mehr. Umgekehrt kann die Kombination einer High-End CPU mit einer Low-End Graphikkarte (wie sie häufig in Laptops zu finden ist) nur wenig vom Einsatz der cudaOptiVec-Bibliotheken profitieren.
• Die Kosten für das Hin-und-Herschieben von Daten zwischen Haupt- und Graphik-Speicher (in den für CUDA gebräuchlichen Termini: "Host"- und "Device"-Memory) sind so hoch, dass sie nur für ziemlich große Vektoren und Matrizen wieder eingespielt werden können. So lohnt sich der CUDA-Einsatz für mathematische Funktionen wie sin oder exp erst ab mehreren 1000 Vektor-Elementen.
• Der Gebrauch von CUDA mit OptiVec kann sich sehr einfach gestalten, indem einfach anstelle der "normalen" OptiVec-Bibliotheken die cudaOptiVec-Bibliotheken eingebunden werden. Es sind nicht einmal Modifikationen des Quell-Codes notwendig.
• Wenn Sie allerdings doch die Mühe auf sich nehmen wollen, Ihren Quellcode anzupassen, gibt es Wege, um die Performance sehr deutlich gegenüber dieser einfachsten Vorgehensweise zu steigern. Hierfür bieten die cudaOptiVec-Bibliotheken verschiedene Sets von Funktionen, die sich durch ihre Präfixe unterscheiden:
  • VF_, VFx_ etc. (die "normalen" Präfixe): Automatischer Gebrauch von CUDA. Alle OptiVec-Funktionen machen eine Abschätzung, ob sich die Auslagerung auf den Graphikprozessor (in CUDA-Diktion: "Device") lohnt, und entscheiden sich dementsprechend, CUDA zu nutzen oder doch auf der CPU (dem "Host") zu bleiben. Dieser Entscheidungs-Mechanismus ist allerdings alles andere als vollkommen, da er nicht auf einfache Weise "wissen" kann, wie gut und schnell die Graphikkarte relativ zur CPU tatsächlich ist.
  • VFcu_, VFxcu_, etc. (mit "cu" hinter dem originalen Präfix, direkt vor dem Unterstrich): Erzwingt Auslagerung auf den CUDA Device. Der Gebrauch dieser Präfixe macht am meisten Sinn, wenn der automatische Entscheidungs-Mechanismus ausgeschaltet ist durch Aufruf von V_setAutoCudaUse( 0 );
  • cudaVF_, cudaVFx_, etc. (mit vorangestelltem "cuda" vor dem originalen Präfix): Verarbeitet Daten auf dem CUDA Device, die sich bereits im Device-Memory befinden (oder in pinned Host-Memory). Um diese Präfixe zu verwenden, muss der Speichertransfer zwischen Haupt- und Device-Speicher selbst vorgenommen werden. cudaOptiVec stellt die nötigen Interface-Funktionen hierfür (als Spezialisierungen der entsprechenden CUDA-Runtime-Funktionen) zur Verfügung.
• NVIDIA hat die Unterstützung für 32-bit eingestellt. Während die 64-bit cudaOptiVec-Bibliotheken jeweils auf der neuesten CUDA-Version basieren, mussten die 32-bit cudaOptiVec-Bibliotheken daher mit der veralteten CUDA-Version 8.0 erstellt werden und werden demnächst ganz entfallen müssen.
• NVIDIA kann jederzeit die Lizenzbedingungen für ihre CUDA-Bibliotheken ändern. Wir erwarten zwar, dass NVIDIA die bisherige offene Politik beibehält; es kann aber von unserer Seite keine Garantie geben, dass OptiVec dauerhaft CUDA unterstützen kann.
• Eine Schritt-für-Schritt-Einführung für die Benutzung von OptiVec mit CUDA befindet sich in CudaOptiVecD.HTM.

1.1.4 Auswahl der passenden OptiVec-Bibliothek

Für mittlere bis große Vektoren und Matrizen auf Mehrkern-Rechnern bietet sich die Verwendung der multi-core-optimierten Bibliotheken an. Diese verteilen für jede einzelne Funktion die Arbeitslast über die vorhandenen Prozessor-Kerne (Auto-Threading). Sie werden durch den Buchstaben "M" gekennzeichnet, also z.B. OVVC8M.LIB  ,  ovgc64_9m.lib, etc. Diese Bibliotheken sind für Multiprozessor-Computer wie AMD64 X2, Intel i5, Core2Duo oder Workstations mit mehreren Prozessoren gedacht.
Die CUDA-Bibliotheks-Versionen basieren auf den "M"-Bibliotheken und lagern die Verarbeitung nur für sehr große Vektoren auf die Graphik-Karte aus. Sie sind durch den Buchstaben "C" markiert, z.B.  OVBC64_8C.LIB.
Die "M"- und "C"- Bibliotheken laufen immer noch auf Ein-Kern-Computern. Durch die "Bürokratie-Verluste" beim Thread-Management sind sie hier aber deutlich langsamer als die Allzweck-Bibliotheken. Obwohl die "M"-Bibliotheken im Hinblick auf mittlere bis größere Vektoren entwickelt wurden, sind die Einbußen bei Verwendung mit kleinen Vektoren nicht sehr hoch, da die OptiVec Thread-Engine eine Funktion automatisch in einem einzelnen Thread ausführt, wenn die Vektor-Größe nicht ausreicht, um den Verteilungs-Aufwand durch die Parallel-Ausführung (oder gar durch die Auslagerung auf den Graphik-Prozessor) wieder aufzuholen.
Wenn Sie die "M"- oder "C"-Bibliotheken verwenden, muss Ihr Programm zu Beginn V_initMT( nVorhandeneProzKerne ) aufrufen.

Zurück zum Inhaltsverzeichnis

Die folgenden Lizenzbedingungen gelten für die Shareware-Version von OptiVec. Die Lizenzbedingungen für die registrierte Vollversion finden Sie in Kap. 1.3. Dies ist die Shareware-Version von OptiVec ("SOFTWARE").
Ihre Nutzung unterliegt den folgenden Lizenzbedingungen:

1. Sie dürfen diese SOFTWARE gebührenfrei für einen Zeitraum von 90 Tagen auf einem Rechner testen.
2. Sonderbedingung für die 32-bit P4D und die 64-bit P8D Bibliotheken für GCC und für LLVM CLang: Diese Bibliotheken sind Freeware. Sie dürfen kostenfrei und zeitlich unbegrenzt genutzt werden, sowohl in nicht-kommerziellen als auch in kommerziellen Anwendungen. Mit diesen Bibliotheken erstellte Anwendungen dürfen unbegrenzt an Dritte weitergegeben werden.
3. Mit der Shareware-Version dieser SOFTWARE erstellte Anwendungen sind nur auf demselben Rechner lauffähig, auf dem die SOFTWARE installiert wurde. Sie können und dürfen nicht an Dritte weitergegeben werden. Nach dem Ende der Test-Zeit sind sie nicht mehr ausführbar.
4. Falls Sie die SOFTWARE nach Ablauf der Testzeit weiterbenutzen und/oder Anwendungen, die Funktionen dieser SOFTWARE enthalten, zu gewerblichen Zwecken verwenden möchten, müssen Sie die registrierte Vollversion erwerben (siehe Kap. 1.3).
5. Die SOFTWARE wird auf "as is"-Basis zur Verfügung gestellt. Jegliche explizite oder implizite Garantieleistungen sind ausdrücklich ausgeschlossen.
6. Trotz sorgfältigen Testens können keinerlei Zusicherungen bezüglich des fehlerfreien Funktionierens, der Eignung für einen bestimmten Zweck oder der Marktgängigkeit gemacht werden.
7. Daher darf diese SOFTWARE nicht in Umgebungen oder unter Umständen eingesetzt werden, unter denen Fehler der SOFTWARE zu größeren materiellen Verlusten oder gar zu Schäden an Leib und Leben führen könnten.
8. Zurück-Entwickeln (Reverse engineering), Dekompilieren und Entassemblieren der SOFTWARE sind nicht gestattet. Selbstverständlich dürfen Sie aber die in Ihre eigenen Programme eingebundenen Funktionen der SOFTWARE mit Hilfe von Debuggern (wie z.B. den mit den Compilern von Borland oder Microsoft gelieferten) inspizieren.

Zurück zum Inhaltsverzeichnis

1.3 Registrierte Vollversion

1.3.1 Preise und Bestellmöglichkeiten

Preisliste

Die Preise incl. deutscher MWSt gelten innerhalb Deutschlands sowie für private Besteller innerhalb der EU. Falls Sie eine Europäische VAT ID besitzen oder von außerhalb der Europäischen Union bestellen, entfällt die deutsche MWSt. Dafür muß vom Erwerber der in seinem Heimatland gültige Satz abgeführt werden, bei Lieferung außerhalb der EU gegebenenfalls auch noch Import-Zoll.

Bestellungen bitte über www.optivec.de/order/ oder mit diesem Bestell-Formular an

OptiCode –Dr. Martin Sander Software Entwicklung
Brahmsstr. 6
D-32756 Detmold
optivec@gmx.de

Zurück zum Inhaltsverzeichnis

1.3.2 Lizenzbedingungen für die registrierte Vollversion

Nach Zahlung der im Kaufpreis enthaltenen Lizenzgebühr dürfen Sie die SOFTWARE für unbegrenzte Zeit benutzen, sofern Sie das Copyright nicht verletzen und die folgenden Regeln einhalten:

1. Die SOFTWARE darf auf jedem hierfür geeigneten Computer verwandt werden, solange nicht mehr als eine Person sie gleichzeitig benutzt. Wenn mehrere Personen die SOFTWARE auf einem oder mehreren Computern gleichzeitig benutzen wollen (z.B. in einem Netzwerk), ist eine Mehrfach-Lizenz zu erwerben.
   
2. Sie dürfen zum persönlichen Gebrauch Backup-Kopien der gelieferten Datenträger machen. Sie dürfen die SOFTWARE nicht verleihen oder vermieten. Sie dürfen sie jedoch auf Dauer an einen anderen übertragen, sofern Sie die Original-Datenträger vollständig weitergeben und alle von Ihnen gemachten Kopien vernichten und sofern sich der Empfänger mit diesen Lizenzbedingungen einverstanden erklärt.
   
3. Zurück-Entwickeln (Reverse engineering), Dekompilieren und Entassemblieren der SOFTWARE sind nicht gestattet. Selbstverständlich dürfen Sie aber die in Ihre eigenen Programme eingebundenen Funktionen der SOFTWARE mit Hilfe von Debuggern (wie z.B. den mit den Compilern von Borland oder Microsoft gelieferten) inspizieren.
   
4. Falls Sie die ermäßigte Lizenzgebühr für die Schulversion anstelle der vollen Gebühr für die kommerzielle Version der SOFTWARE in Anspruch genommen haben, ist der Einsatz der SOFTWARE auf private Nutzung sowie Nutzung zum Zwecke der Ausbildung beschränkt. In diesem Falle darf die SOFTWARE nicht für kommerzielle Zwecke und nicht für andere staatliche Aufgaben als Erziehung und Ausbildung eingesetzt werden.
   Anwendungen, die Funktionen dieser SOFTWARE verwenden, dürfen nur dann gebührenfrei weitergegeben werden (ohne Laufzeit-Lizenz), wenn sie mit der kommerziellen Version erstellt wurden. Außerdem müssen die Funktionen der SOFTWARE permanent in die jeweilige Anwendung eingebunden sein und dürfen dem Benutzer der Anwendung nicht als Bibliothek entgegentreten.
   
5. Die SOFTWARE darf nicht in Umgebungen oder unter Umständen eingesetzt werden, unter denen eventuelle Fehler der SOFTWARE zu einer Gefahr für irgendjemandes Leib und Leben oder zu größeren materiellen Verlusten führen könnten.
   
6. Die Haftung von OptiCode ist durch die beigefügte Beschränkte Garantie eingeschränkt. In jedem Fall ist die Haftung von OptiCode auf den Betrag beschränkt, den Sie tatsächlich für die Benutzung der SOFTWARE bezahlt haben.

1. OptiCode garantiert, daß die magnetischen oder optischen Medien, auf denen die SOFTWARE aufgezeichnet ist, sowie die gedruckte Dokumentation bei normaler Benutzung frei von Material- und Verarbeitungsfehlern sind. Ferner wird garantiert, daß die SOFTWARE selbst im Wesentlichen gemäß der begleitenden gedruckten Dokumentation arbeitet.
   
2. Die obigen Garantien gelten für einen Zeitraum von sechs Monaten ab Empfangsdatum.
   
3. Die gesamte Haftung von OptiCode und Ihr alleiniger Anspruch als Kunde besteht nach Wahl von OptiCode entweder in der Rückerstattung des bezahlten Preises oder in dem Ersatz der obiger Garantie nicht genügenden und an OptiCode (unter Nachweis des rechtmäßigen Erwerbs) zurückgegebenen Teile.
   
4. Trotz sorgfältigen Testens kann nicht garantiert werden, daß die SOFTWARE oder die Dokumentation vollständig frei von Fehlern sind.
   
5. Alle impliziten Garantien, z.B. bezüglich Marktgängigkeit oder Eignung für einen bestimmten Zweck, sind auf die oben explizit gegebenen Garantien beschränkt.
   
6. OptiCode ist nicht für Folgeschäden (uneingeschränkt eingeschlossen sind Schäden aus entgangenem Gewinn, Betriebsunterbrechung, Verlust von geschäftlichen Informationen oder Daten oder aus anderem finanziellen Verlust) ersatzpflichtig, die aufgrund der Benutzung dieses Produktes oder der Unfähigkeit, es zu verwenden, entstehen, selbst wenn OptiCode von der Möglichkeit eines solchen Schadens unterrichtet worden ist. Dieser Ausschluß gilt nicht für Schäden, die durch Vorsatz oder grobe Fahrlässigkeit auf seiten von OptiCode verursacht wurden. Ansprüche, die auf unabdingbaren gesetzlichen Vorschriften zur Produkthaftung beruhen, bleiben ebenfalls unberührt.

Zurück zum Inhaltsverzeichnis

1.4 Installation und Start

1.4.1 OptiVec für C++ Builder (Embarcadero / Borland C++)

Sie müssen nicht nur eine, sondern zwei OptiVec-Bibliotheken einschließen. Die erste, die "Basis-Bibliothek", enthält das Interface zwischen OptiVec und der BC-Laufzeitbibliothek. Bitte beachten Sie die notwendige Unterscheidung zwischen Verwendung der statischen und der dynamischen Laufzeitbibliothek in 32-bit:
 

Plattform	Compiler	statische Laufzeitbibliothek	Laufzeitbibliothek als DLL
Win64	bcc64, ab RAD Studio 12 (2023)	ovbcbase64.a	ovbcbase64.a
	bcc64, alle Versionen bis RAD Studio 11.x	ovbcx64.a	ovbcx64.a
Win32	"klassischer" Borland Compiler bcc32 ab RAD Studio / BCB 12 (2023)	ovbcbase32s.lib	ovbcbase32d.lib
	ältere Versionen bis einschl. 11.x	vcfs.lib	vcfd.lib
	CLang-Borland Compiler bcc32c ab RAD Studio 12	ovbcbase32cs.lib	ovbcbase32cd.lib
	RAD Studio 10.x, 11.x	ovbc10_11base32cs.lib	ovbc10_11base32cd.lib

Die zweite einzubindende Bibliothek wiederum ist entscheidet über die Prozessor-Unterstützung. Sie ist aber unabhängig von der jeweiligen Projekt-Konfiguration.
 

Plattform	Compiler	Prozessor	Allzweck	Debug	Autothreading (MP)	MP + CUDA
Win64	bcc64	P9: Haswell+ / Excavator+	OVVC64_9.a	----	OVBC64_9M.a	OVBC64_9C.a
	bcc64	P8: AMD64xxx, Core2xxx	OVBC64_8.a	OVBC64_8D.a	OVBC64_8M.a	OVBC64_8C.a
Win32	bcc32 (klassisch)	P8: AMD64xxx, Core2xxx	VCF8W.LIB	----	VCF8M.LIB	VCF8C.LIB
		P4: Max Kompatibilität, FPU-Genauigkeit	VCF4W.LIB	VCF4D.LIB	VCF4M.LIB	----
	bcc32c (CLang) ab C++ Builder 10.1 Berlin	P8: AMD64xxx, Core2xxx	ovbc32c_8.lib	----	ovbc32c_8m.lib	ovbc32c_8c.lib
		P4: Max Kompatibilität, FPU-Genauigkeit	ovbc32c_4.lib	ovbc32c_4d.lib	ovbc32c_4m.lib	----
	bcc32c (CLang) bis C++ Builder 10 Seattle	P8: AMD64xxx, Core2xxx	VCF8W.LIB	----	VCF8M.LIB	VCF8C.LIB
		P4: Max Kompatibilität, FPU-Genauigkeit	VCF4W.LIB	VCF4D.LIB	VCF4M.LIB	----

 
Um die "C"-Bibliotheken (Mehrkern+CUDA) zu nutzen, müssen Sie außerdem die Import-Bibliothek OVBCCU32.lib (32-bit) oder OVBCCU64.a (64-bit) einschließen und sicherstellen, dass sich die entsprechende DLL, OVBCCU32.DLL oder OVBCCU64.DLL entweder in dem Verzeichnis befindet, in dem Sie Ihr ausfürbares Programm erstellen, oder in einem anderen Verzeichnis, dass in der Windows-Umgebungsvariablen PATH aufgeführt ist. Sollten Sie unter 64-bit noch Unterstützung für alte CUDA-Hardware (Compute Capability 3.5, 5.0, 6.0) benötigen, schließen Sie OVBCCULEG64.a anstelle von OVBCCU64.a ein, die auf die DLL OVBCCULEG64.DLL verweist.

Alle in früheren Versionen von OptiVec gültigen Einschränkungen für die Verwendung mit dem 32-bit CLang-Borland-Compiler bcc32c.exe sind aufgehoben.

Fortsetzung mit Kap. 1.5 Deklaration von OptiVec-Funktionen in C/C++

1.4.2 OptiVec für Visual C++ (Microsoft Visual Studio)

Man beachte, dass es eine gewisse Inkonsistenz in den Konfigurations-Bezeichnungen von Visual Studio gibt: Die Standard-Konfigurationen "Debug" und "Release" binden die Laufzeitbibliothek und MFC als DLL ein, stellen also die in früheren Versionen "Debug DLL" und "Release DLL" genannten Konfigurationen dar. Das bedeutet, dass die OptiVec-Basisbibliotheken OVVC??MDD.lib und OVVC??MDR.lib mit diesen Konfigurationen zu benutzen sind. Außerdem muss sichergestellt sein, dass die Laufzeit- und MFC-DLL's auf jedem Rechner installiert sind, auf dem eine so erstellte Anwendung laufen soll. Für viele Anwendungen empfiehlt es sich daher, Project / Properties / Configuration Properties / C/C++ / Code Generation / Runtime Library in "Multi-Thread Debug (/MTd)" oder "Multi-Thread Release (MT)" zu ändern, um durch statisches Linken die DLL-Redistributables zu vermeiden. Dies ist in der "DebugStatic"-Konfiguration in den Demo-Dateien von OptiVec so realisiert.

Als zweites fügen Sie nun die prozessor-spezifische OptiVec-Bibliothek gemäß folgender Tabelle hinzu:

Prozessor	Allzweck-Bibliothek	Debug-Bibliothek	MP / Mehr-Kern	Mehr-Kern + CUDA	64-bit Allgemein	64-bit Debug	64-bit Mehrkern	64-bit MP + CUDA
P9: Haswell+ / Excavator+	----	----	----	----	OVVC64_9.LIB	----	OVVC64_9M.LIB	OVVC64_9C.LIB
P8: AMD64xxx, Core2xxx	OVVC8.LIB	----	OVVC8M.LIB	OVVC8C.LIB	OVVC64_8.LIB	OVVC64_8D.LIB	OVVC64_8M.LIB	OVVC64_8C.LIB
P4: FPU-Genauigkeit, 486DX/Pentium	OVVC4.LIB	OVVC4D.LIB	OVVC4M.LIB	----	----	----	----	----

 
Die Bilbiotheken für Mehrprozessor-Systeme funktionieren sowohl auf Workstations mit diskreten Prozessoren der genannten Entwicklungsstufe als auch auf Mehrkern-Prozessoren (AMD64x2, Core2 Duo usw.). Damit OptiVec sowohl in Anwendungen mit MFC als auch ohne MFC verwenden werden kann, ruft es selbst nur direkt die Windows-API auf, nicht aber über den Umweg von MFC. Wenn Sie nun aber MFC verwenden (sei es als statische Bibliothek, sei es als DLL), bindet Visual C++ die benötigte Import-Bibliothek user32.lib standardmäßig nicht mit ein. Sie müssen dies daher explizit selbst tun: Die Zeile Projekt / Einstellungen / Linker / Kategorie: Allgemein / Objekt- und Bibliothek-Module muß den Eintrag user32.lib erhalten. Andernfalls würde der Linker den Fehler "error LNK2001: Nichtaufgeloestes externes Symbol __imp__MessageBoxA@??" melden.

Um die "C"-Bibliotheken (Mehrkern+CUDA) zu nutzen, müssen Sie außerdem die Import-Bibliothek OVVCCU32.lib (32-bit) oder OVVCCU64.lib (64-bit) einschließen und sicherstellen, dass sich die entsprechende DLL, OVVCCU32.DLL oder OVVCCU64.DLL entweder in dem Verzeichnis befindet, in dem Sie Ihr ausfürbares Programm erstellen, oder in einem anderen Verzeichnis, dass in der Windows-Umgebungsvariablen PATH aufgeführt ist. Sollten Sie unter 64-bit noch Unterstützung für alte CUDA-Hardware (Compute Capability 3.5, 5.0, 6.0) benötigen, schließen Sie OVVCCULEG64.lib anstelle von OVVCCU64.lib ein, die auf die DLL OVVCCULEG64.DLL verweist.

Fortsetzung mit Kap. 1.5 Deklaration von OptiVec-Funktionen in C/C++

1.4.3 OptiVec für GCC (GNU Compiler Collection), Windows

Nun wählen Sie die zweite, Prozessor-spezifische OptiVec-Bibliothek aus der nächsten Tabelle:

Prozessor	32-bit Allzweck	Debug	MP / Mehr-Kern	Mehr-Kern + CUDA	64-bit Allgemein	64-bit Debug	64-bit Mehrkern	64-bit MP + CUDA
P9: Haswell+ / Excavator+	----	----	----	----	ovgc64_9.lib	----	ovgc64_9m.lib	ovgc64_9c.lib
P8: AMD64xxx, Core2xxx	ovgc32_8.lib	----	ovgc32_8m.lib	ovgc32_8c.lib	ovgc64_8.lib	ovgc64_8d.lib	ovgc64_8m.LIB	ovgc64_8c.lib
P4: FPU-Genauigkeit, 486DX/Pentium	ovgc32_4.lib	ovgc32_4d.lib	ovgc32_4m.lib	----	----	----	----	----

 
Die Bilbiotheken für Mehrprozessor-Systeme funktionieren sowohl auf Workstations mit diskreten Prozessoren der genannten Entwicklungsstufe als auch auf Mehrkern-Prozessoren (AMD64x2, Core2 Duo usw.).

Um die "C"-Bibliotheken (Mehrkern+CUDA) zu nutzen, müssen Sie zusätzlich die DLL's ovgccu32.dll (32-bit) oder ovgccu64.dll (64-bit) an den Linker übergeben. Sollten Sie unter 64-bit noch Unterstützung für alte CUDA-Hardware (Compute Capability 3.5, 5.0, 6.0) benötigen, schließen Sie ovgcculeg64.dll anstelle von ovgccu64.dll ein. Anders als alle anderen Compiler benötigt GCC keine Import-Bibliothek, sondern kann direkt gegen die DLL linken (und sich die Import-Tabelle dabei selbst erstellen). Außerdem müssen Sie sicherstellen, dass die genannten DLLs sich entweder in dem Verzeichnis befinden, in dem Sie Ihr ausfürbares Programm erstellen, oder in einem anderen Verzeichnis, dass in der Windows-Umgebungsvariablen PATH aufgeführt ist.

Ein sehr wichtiger Punkt, den es bei der Arbeit mit GCC zu beachten gilt, ist, dass der Linker gegenseitige Abhängigkeiten zwischen eingeschlossenen Bibliotheken nicht selbständig auflöst. Da die Basis-Bibliothek und die Prozessor-spezifische Bibliothek von OptiVec aber gegenseitige Abhängigkeiten enthalten, bedeutet dies, dass die beiden paarweise mindestens zweimal eingeschlossen werden müssen. Wenn Sie Linker-Fehler über nicht gefundene OptiVec-Funktionsnamen erhalten, schließen Sie einfach dasselbe Bibliotheken-Paar noch ein weiteres Mal ein. Das Makefile für die Demo-Programme mag als Beispiel dienen.

GCC ist der einzige unter den "großen" Compilern, der in 64-bit den aus 80-bit Fließkommazahlen bestehenden Datentyp long double bzw. extended unterstützt. (Die anderen Compiler benutzen in 64-bit long double / extended einfach als Synonym für double). Dies ist ein sehr wertvolles Feature von GCC, da die zusätzliche Genauigkeit und Reichweite gelegentlich eine bedeutende Vereinfachung darstellen können. OptiVec unterstützt diesen Datentyp mit den VE_, VCE_, VPE_, ME_, und MCE_ Funktionen.

Die Linux-Version von OptiVec ist weiter unten beschrieben.

Fortsetzung mit Kap. 1.5 Deklaration von OptiVec-Funktionen in C/C++

1.4.4 OptiVec für LLVM CLang

Um die "C"-Bibliotheken (Mehrkern+CUDA) zu nutzen, müssen Sie zusätzlich die Importbibliotheken ovvccu32.lib (32-bit) oder ovvccu64.lib (64-bit) an den Linker übergeben, die auf ovvccu32.dll bzw. ovvccu64.dll verweisen. Sollten Sie unter 64-bit noch Unterstützung für alte CUDA-Hardware (Compute Capability 3.5, 5.0, 6.0) benötigen, schließen Sie ovvcculeg64.lib anstelle von ovvccu64.lib ein, die auf die DLL ovvcculeg64.dll verweist. Außerdem müssen Sie sicherstellen, dass die genannten DLLs sich entweder in dem Verzeichnis befinden, in dem Sie Ihr ausfürbares Programm erstellen, oder in einem anderen Verzeichnis, dass in der Windows-Umgebungsvariablen PATH aufgeführt ist. Falls Sie sich über den auf Visual C++ hinweisenden Bibliotheksnamen ovvccu??.lib wundern – in der Tat werden die cudaOptiVec-Bibliotheken für Visual C++ auch für CLang verwendet.

Die Linux-Version von OptiVec ist weiter unten beschrieben.

Fortsetzung mit Kap. 1.5 Deklaration von OptiVec-Funktionen in C/C++

1.4.5 OptiVec für Delphi

Um die "C"-Units (Mehrkern+CUDA) zu nutzen, müssen Sie außerdem sicherstellen, dass sich OVDCU32.DLL (32-bit), OVDCU64.DLL (64-bit) oder OVDCULEG64.DLL (64-bit für alte CUDA-Devices mit Compute Cap. 3.5, 5.0, 6.0) entweder in dem Verzeichnis befindet, in dem Sie Ihr ausfürbares Programm erstellen, oder in einem anderen Verzeichnis, dass in der Windows-Umgebungsvariablen PATH aufgeführt ist.

Fortsetzung mit Kap. 1.5.2 Deklaration von OptiVec-Funktionen in Pascal / Delphi

1.4.6 OptiVec für Lazarus / FreePascal

Um die "C"-Units (Mehrkern+CUDA) zu nutzen, müssen Sie außerdem sicherstellen, dass sich OVDCU64.DLL (für aktuelle CUDA-Devices) oder OVDCULEG64.DLL (für alte CUDA-Devices mit Compute Capability 3.5, 5.0, 6.0) entweder in dem Verzeichnis befindet, in dem Sie Ihr ausfürbares Programm erstellen, oder in einem anderen Verzeichnis, dass in der Windows-Umgebungsvariablen PATH aufgeführt ist.

Fortsetzung mit Kap. 1.5.2 Deklaration von OptiVec-Funktionen in Pascal / Delphi

1.4.7 OptiVec für Linux mit GCC oder CLang

Dann wähle man die zweite, prozessor-spezifische OptiVec-Bibliothek aus folgender Tabelle:

Processor	Allgemein	Debug	Multi-Proc. Auto-Threading
P9: Haswell+ / Excavator+	ovlxc64_9.a	----	ovlxc64_9m.a
P8: AMD64xxx, Core2xxx	ovlxc64_8.a	ovlxc64_8d.a	ovlxc64_8m.a

 
Die Autothreading-Bibliotheken können nur gemeinsam mit der Basis-Bibliothek ovlxcbase64m.a verwendet werden und erfordern die Linker-Option -lpthread.

Ein sehr wichtiger Punkt, den es bei der Arbeit mit Linux-GCC und -CLang zu beachten gilt, ist, dass der Linker gegenseitige Abhängigkeiten zwischen eingeschlossenen Bibliotheken nicht selbständig auflöst. Da die Basis-Bibliothek und die Prozessor-spezifische Bibliothek von OptiVec aber gegenseitige Abhängigkeiten enthalten, bedeutet dies, dass die beiden paarweise mindestens zweimal eingeschlossen werden müssen. Wenn Sie Linker-Fehler über nicht gefundene OptiVec-Funktionsnamen erhalten, schließen Sie einfach dasselbe Bibliotheken-Paar noch ein weiteres Mal ein. Das Makefile für die Demo-Programme mag als Beispiel dienen.

1.5 Deklaration von OptiVec-Funktionen

1.5.1 Deklaration von OptiVec-Funktionen in C/C++

1.5.2 Deklaration von OptiVec-Funktionen in Pascal / Delphi

1.6 Beispiel-Programme

• C++ Builder (Embarcadero / Borland C++):
  12, 11.x, 10.x, XE3 oder höher: Öffnen Sie die Projektgrouppe VDEMO.groupproj (64-bit und klassischer Borland-Compiler 32-bit) oder VDemo_BCC32C.groupproj (Clang-unterstützter Compiler BCC32C; nur 32-bit).
  Alternativ (für ältere Versionen: immer) öffnen Sie die einzelnen Projekte:
  VDEMO.cbproj,   FITDEMO.cbproj,  MANDEL.cbproj sind Projekte für RAD Studio 12, 11.x, 10.x, XE-Serie, 2010, 2009
  Die *.bdsproj Projekte sind für BDS 2006 und 2007
  VDEMOB6.BPR, FITDEMOB6.BPR und MANDELB6.BPR sind für BC++ Builder 6+.
• Microsoft Visual C++:
  Je nach Version von Visual Studio öffnen Sie VDEMO_VS2019.sln, VDEMO_VS2015.sln usw.
  Möglicherweisen konvertiert Visual Studio die Projektmappe in ein neueres Format. Bestätigen Sie die Umwandlung, wenn das Programm Sie dazu auffordert.
• GCC unter Windows:
  Das Make-File "makefile." enthält die fünf Targets VDemo, VSpeedDemo, FitDemo, Mandel und CDemo. Es ist füt die Verwendung mit GNU-Make gedacht. Bevor Sie make aufrufen, sollten Sie im makefile den Pfad zum GCC-Compiler korrekt setzen.
• LLVM CLang unter Windows:
  Prinzipiell sollte CLang in der Lage sein, alle Windows DLL's zu verwenden. Dies scheint aber mit den derzeitigen Versionen im Falle von GDI32.DLL nicht der Fall zu sein. Da alle OptiVec- Demo-Programme auf Graphik-Ausgabe zur Darstellung von Ergebnissen angewiesen sind, sind diese Demo-Programme leider für CLang nicht erhältlich, solange dieser CLang-Fehler nicht behoben ist. Das Make-File "makefile." enthält daher nur die drei Targets VSpeedDemo, FitDemo und CDemo.
• Delphi:
  Öffnen Sie VDemoD.groupproj. Diese Projekt-Gruppe enthält die Projekte VDEMO.dproj, VSpeedDemo.dproj, FITDEMO.dproj, CDEMO.dproj und MANDEL.dproj
• Lazarus / FreePascal:
  Hier öffnen Sie VDEMO.lpi, VSpeedDemo.lpi, FITDEMO.lpi, CDEMO.lpi oder MANDEL.lpi.
• Linux mit GCC oder CLang:
  Das Make-File "makefile." enthält die drei Targets VSpeedDemo, FitDemo und CDemo (Groß- und Kleinschreibung beachten!).

Zurück zum Inhaltsverzeichnis

2. Elemente von VectorLib-Funktionen

2.1 Synonyme einiger Datentypen

a) nur C/C++:

64-bit-Integers (__int64 in BC++ Builder und MS Visual C++, Int64 in Delphi, früher einmal Comp in Turbo Pascal) werden in OptiVec als quad (für "quadruple integer", also Vierfach-Integer) bezeichnet.
Der Datentyp quad ist in 32-bit immer vorzeichenbehaftet; nur für Win64 bietet OptiVec den Datentyp uquad als vorzeichenlosen 64-bit Ganzzahltyp.

• Nur Borland C++ vor C++ Builder 2006: Da diese älteren BC-Versionen keine direkte Unterstützung für 64-bit Integers boten, ist hier der Typ quad als struct von zwei 32-bit-Werten implementiert. Fließkommazahlen – vorzugsweise der über eine 64-bit-Mantisse verfügende Typ long double – zur " müssen zur Vermittlung" eingesetzt werden. Hierzu dienen die Funktionen setquad,   quadtod und _quadtold. Alternativ können die beiden 32-bit-Teile auch einzeln zugewiesen werden, z.B.:.
  xq.Hi = 0x00000001UL;
  xq.Lo = 0x2468ABCDUL;

Der Pascal/Delphi-Benutzern wohlbekannte Datentyp extended wird in der Borland C++-Version von OptiVec als Synonym für long double verwendet. Da weder Visual C++ noch die meisten 64-bit-Compiler 80-bit-Fließkommazahlen unterstützen, ist extended hier als double definiert.
Der Grund für die Einführung des Typs extended ist, daß alle OptiVec-Funktionen identische Namen in C/C++ und Pascal/Delphi haben sollen. Die Funktions-Präfixe aber sind vom Datentyp der verarbeiteten Vektoren abgeleitet (s.u.). Der Buchstabe "L" (der vielleicht für long double stehen könnte) ist bereits durch long int und unsigned long überbelegt. So bietet sich der Buchstabe "E" für extended an, was den zusätzlichen Vorteil der Nähe zu den Buchstaben "D" für double und "F" für float hat. Es ist vorgesehen, in der Zukunft 128-bit-Fließkommazahlen (__fp128 / __float128) als "G" für Great und Half Floats (__fp16) als "H" ihren Platz ebenfalls in alphabetischer Nachbarschaft finden zu lassen.

b) nur Pascal/Delphi:

Aus "historischen" Gründen weisen die Ganzzahl-Datentypen eine etwas konfuse Nomenklatur in Pascal/Delphi auf. Um die vom Datentyp abgeleiteten Präfixe mit der C/C++-Version von OptiVec kompatibel zu machen, definieren wir eine Anzahl von Synonymen, wie in der folgenden Tabelle beschrieben:

type	Pascal/Delphi-Name	Synonym	abgeleitetes Präfix
8 bit signed	ShortInt	ByteInt	VBI_
8 bit unsigned	Byte	UByte	VUB_
16 bit signed	SmallInt		VSI_
16 bit unsigned	Word	USmall	VUS_
32 bit signed	LongInt		VLI_
32 bit unsigned		ULong	VUL_
64 bit signed	Int64	QuadInt	VQI_
64 bit unsigned	UInt64	UQuad	VUQ_
16/32 bit signed	Integer		VI_
16/32 bit unsigned	Cardinal	UInt	VU_

UQuads existieren nur in der 64-bit-Version. Für Win32 gibt es nur den vorzeichenbehafteten Typ Quad.

Um einen Bool'schen Datentyp derselben Größe wie Integer zur Verfügung zu haben, definieren wir den Typ IntBool. Er ist äquivalent mit LongBool. Man findet den Typ IntBool vor allem als Rückgabewert vieler mathematischer VectorLib-Funktionen.

2.2 Komplexe Zahlen:
Die Datentypen fComplex, dComplex, eComplex, fPolar, dPolar und ePolar

Unsere Ziele sind

• komplexe Zahlen in allen drei Genauigkeiten für C, C++, Pascal und Delphi zur Verfügung zu stellen
• sowohl cartesische als auch Polar-Koordinaten zu unterstützen
• eine saubere, effiziente Implementierung in Assembler zu liefern (anstelle der gebräuchlichen C++ Templates)
• und eine einfache, kompakte und konsistente Nomenklatur einzuführen.

Die entsprechenden Definitionen für Pascal/Delphi sind in der Unit VecLib enthalten:
type fComplex = record Re, Im: Float; end;
type dComplex = record Re, Im: Double; end;
type eComplex = record Re, Im: Extended; end;
type fPolar = record Mag, Arg: Float; end;
type dPolar = record Mag, Arg: Double; end;
type ePolar = record Mag, Arg: Extended; end;

Komplexe Zahlen werden initialisiert, indem ihrem Real- und Imaginärteil bzw. ihrem Mag- und Arg-Teil die gewünschten Werte zugewiesen werden, z.B.:
z.Re  = 3.0; z.Im  = 5.7;
p.Mag = 8.8; p.Arg = 3.14;
(Für Pascal/Delphi muß der Zuweisungs-Operator natürlich ":=" geschrieben werden).
Alternativ kann die Initialisierung auch mittels der Funktionen fcplx oder fpolr durchgeführt werden:
C/C++:
z = fcplx( 3.0, 5.7 );
p = fpolr( 4.0, 0.7 );

Pascal/Delphi:
fcplx( z, 3.0, 5.7 );
fpolr( p, 3.0, 5.7 );
oder:
z := fcplx( 3.0, 5.7 );
p := fpolr( 3.0, 5.7 );

Für doppelt-genaue komplexe Zahlen gebrauche man dcplx und dpolr, für extended-genaue ecplx und epolr.
Zeiger auf komplexe Felder oder Vektoren werden mithilfe der Datentypen cfVector, cdVector und ceVector (für cartesisch-komplexe Vektoren) sowie pfVector, pdVector und peVector (für Vektoren komplexer Zahlen in Polarkoordinaten) definiert, wie unten beschrieben.

2.3 Vektoren und Arrays:
Die Datentypen fVector, dVector, eVector,
cfVector, cdVector, ceVector, pfVector, pdVector, peVector,
iVector, biVector, siVector, liVector, qiVector,
uVector, ubVector, usVector, ulVector, uqVector und uiVector

Die Basis aller VectorLib-Funktionen bilden die Vektor-Datentypen, die in <VecLib.h> bzw. der Unit VecLib definiert und unten aufgelistet sind. Im Unterschied zu den statischen Arrays, die immer eine beim Compilieren festgelegte Größe besitzen, arbeiten die VectorLib-Typen mit dynamischer Speicherzuweisung und daher mit variablen Größen. Wegen dieser Flexibilität empfehlen wir den vorzugsweisen Gebrauch der letzteren. Hier sind sie also:
 

C/C++ typedef float * fVector typedef double * dVector typedef extended * eVector typedef fComplex * cfVector typedef dComplex * cdVector typedef eComplex * ceVector typedef fPolar * pfVector typedef dPolar * pdVector typedef ePolar * peVector typedef int * iVector typedef byte * biVector typedef short * siVector typedef long * liVector typedef quad * qiVector typedef unsigned * uVector typedef unsigned byte * ubVector typedef unsigned short * usVector typedef unsigned long * ulVector typedef uquad * uqVector typedef ui * uiVector

Pascal/Delphi type fVector = ^Float; type dVector = ^Double; type eVector = ^Extended; type cfVector = ^fComplex; type cdVector = ^dComplex; type ceVector = ^eComplex; type pfVector = ^fPolar; type pdVector = ^dPolar; type peVector = ^ePolar type iVector = ^Integer; type biVector = ^ByteInt; type siVector = ^SmallInt; type liVector = ^LongInt; type qiVector = ^QuadInt; type uVector = ^UInt; type ubVector = ^UByte; type usVector = ^USmall; type ulVector = ^ULong; type uqVector = ^UQuad;

Intern handelt es sich also bei einem Datentyp wie fVector um einen "Zeiger auf float". Man sollte ihn sich allerdings lieber als "float-Vector" vorstellen.
 

N.B.: In der Windows-Programmierung wird häufig der Buchstabe "l" oder "L" eingesetzt, um long int-Variablen zu bezeichnen. Um Verwechslungen vorzubeugen, wird hier für long int stets das aus zwei Buchstaben bestehende Kürzel "li" oder "LI" verwendet und für unsigned long das Kürzel "ul" oder "UL". Konflikte mit den Präfixen für long double-Vektoren werden durch Ableitung deren Kürzel vom Alias-Namen extended und den Gebrauch von "e", "ce", "E" und "CE" umgangen, wie bereits oben und auch in den folgenden Abschnitten beschrieben.

 
Delphi bietet zusätzlich auch dynamisch allozierte Arrays, die ebenfalls als Argumente an OptiVec-Funktionen übergeben werden können. Die folgende Tabelle vergleicht die Zeiger-basierten Vektoren von VectorLib mit den verschiedenen Array-Typen von Pascal/Delphi:
 

	OptiVec-Vektoren	Pascal/Delphi-Arrays (statisch/dynamisch)
Ausrichtung des ersten Elements	an 64-byte-Grenze für optimale Cache-Zeilen-Anpassung	2- oder 4-byte-Grenze (kann Zeilenumbruchs-Strafzyklen für double, QuadInt zur Folge haben)
Ausrichtung folgender Elemente	gepackt (d.h. keine Dummy-Bytes zwischen Elementen, auch nicht für 10- und 20-bit-Typen)	Arrays müssen in Delphi als "packed" deklariert werden, um kompatibel mit OptiVec zu sein
Index-Bereichsprüfung	keine	automatisch mittels eingebauter Größeninformation
dynamische Speicherzuweisung	function VF_vector,  VF_vector0	procedure SetLength
Initialisierung mit 0	optional durch Aufruf von VF_vector0	immer
Freigabe	function V_free,  V_freeAll	procedure Finalize
einzelne Elemente lesen	function VF_element: a := VF_element(X,5); typecast in Array ebenfalls möglich: a := fArray(X)[5];	Index in eckigen Klammern: a := X[5];
einzelne Elemente schreiben	function VF_setElement: VF_setElement(X,5,a); typecast in Array ebenfalls möglich: fArray(X)[5] := a;	Index in eckigen Klammern: X[5] := a;
Übergabe an OptiVec-Funktion	direkt: VF_equ1( X, sz );	Adress-Operator: VF_equ1( @X, sz );
Übergabe von Subvektor an OptiVec-Funktion	function VF_Pelement: VF_equC( VF_Pelement(X,10), sz−10, 3.7);	Adress-Operator: VF_equC( @X[10], sz−10, 3.7 );

 
Zusammenfassend läßt sich sagen, daß die Pascal/Delphi-Arrays etwas bequemer zu verwenden und durch die Index-Bereichsprüfung auch sicherer sind, während die Zeiger-basierten OptiVec-Vektoren schneller verarbeitet werden können (durch die bessere Speicherausrichtung und den Fortfall der Index-Bereichsüberprüfung).

Zurück zum Inhaltsverzeichnis

2.4 Vektor-Funktionen reeller Zahlen:
Die Präfixe VF_,  VD_ und VE_

Zum Präfix VF_ gehören Argumente vom Typ float und fVector, zu VD_ gehören double und dVector und natürlich entsprechend zu VE_ extended und eVector als Argumente und Rückgabewerte.

In den folgenden Kapiteln und in der Funktionsreferenz ist meist nur die VF_- Version einer Funktion explizit beschrieben. Die VD_- und VE_-Versionen sind dieser exakt analog. Man hat nur "fVector" durch "dVector" bzw. "eVector" zu ersetzen und "float" durch "double" bzw. "extended".

Zurück zum Inhaltsverzeichnis

2.5 Komplexe Funktionen:
Die Präfixe VCF_,  VCD_,  VCE_,  VPF_,  VPD_ und VPE_

Rückgabewerte der komplexen Datentypen sind in Pascal/Delphi nicht möglich. Daher unterscheidet sich die Syntax komplexer Funktionen, die Werte zurückgeben, in C/C++ und Pascal/Delphi.

Im Unterschied zu der Sorglosigkeit, mit der komplex-mathematische Funktionen meist behandelt werden, sind die komplexen Funktionen von OptiVec so geschrieben, daß die volle Genauigkeit über den gesamten für den jeweiligen Datentyp legalen Bereich von Eingabe-/Ausgabewerten gewährleistet ist.

Wie bereits erwähnt, sind die nicht-vektorisierten komplexen Funktionen in der Datei CMATHD.HTM beschrieben.

Zurück zum Inhaltsverzeichnis

2.6 Funktionen der Ganzzahl-Datentypen:
Die Präfixe VI_,  VBI_,  VSI_,  VLI_,  VQI_,
VU_,  VUB_,  VUS_,  VUL_,  VUQ_ und VUI_

Für die vorzeichenlosen Ganzzahl-Typen gilt analog:
Präfix VUB_: Datentyp unsigned char (unsigned byte) / UByte,
Präfix VUS_: Datentyp unsigned short / USmall,
Präfix VU_: Datentyp unsigned / UInt,
Präfix VUL_: Datentyp unsigned long / ULong, (32-bit für Windows, 64-bit für Linux)
Präfix VUQ_: Datentyp uquad / UQuad (nur für Win64 und Linux),
Präfix VUI_: Datentyp ui.

Man erschrecke nicht vor dieser Vielfalt. Es gehört zu den Stärken moderner Computer-Sprachen, über diese vielen Datentypen zu verfügen. Gleichzeitig kann diese Stärke natürlich eine Schwäche bedeuten, denn sie verführt zu einem Programmierstil, in dem die Datentypen so lange vermischt werden, bis der Durchblick verloren geht. Im Normalfall sollten die VI_-,  VLI_-,  VU_- und VUI_- Versionen vollauf genügen. Es ist aber nicht schlecht zu wissen, daß noch mehr zur Verfügung stehen, wenn man sie denn benötigt.

Sofern sie existieren, sind die mit Ganzzahlen arbeitenden VectorLib-Funktionen gemeinsam mit ihren Fließkomma-Schwestern besprochen. Auch auf die Gefahr hin, Sie zu langweilen: Die VI_-Version gewinnt man aus der VF_-Version durch Ersatz aller "float"-Parameter durch "int" und aller "fVector" durch "iVector". Gleiches gilt für alle anderen Ganzzahl-Typen.

Zurück zum Inhaltsverzeichnis

2.7 Gemeinsame Funktionen mehrerer Datentypen: Das PräfixV_

Zurück zum Inhaltsverzeichnis

3. Nur C++: VecObj, das objekt-orientierte Interface für VectorLib

• automatische Speicherzuweisung und -freigabe
• vereinfachte Vektor-Behandlung
• stark vermindertes Risiko von Speicherfehlern
• erhöhte Sicherheit des Speicherzugriffs
• intuitive überladene Operatoren
• einfachere Funktionsaufrufe

• erhöhter Aufwand für den Compiler
• größerer Overhead (wie für jeden gekapselten C++-Code!) und als Folge hiervon
• erhöhte Programmcode-Länge
• leicht verminderte Rechengeschwindigkeit
• Vektoren können derzeit nur als Ganzes, nicht in Teilen verarbeitet werden

MS Visual C++ und Borland C++ Builder (nicht aber frühere Borland C++-Versionen): Die Direktive
"using namespace OptiVec;"
sollte entweder im Funktionskörper jeder ein tVecObj verwendenden Funktion oder im globalen Deklarationsteil eines Programmes auftauchen. Der Platz in den einzelnen Funktionskörpern ist sicherer, da er potentielle Namespace-Konflikte mit anderen Funktionen vermeidet.
Die Vektor-Objekte werden als classes vector<T> implementiert, die die Vektor-Adresse (den Zeiger) und seine Größe size kapseln.
Für einfachere Verwendung wurden diesen Klassen Alias-Namen zugewiesen als fVecObj, dVecObj usw., wobei der Datentyp wie sonst in OptiVec durch den ersten oder die ersten beiden Buchstaben des Klassennamens angezeigt wird.

Alle VectorLib für einen bestimmten Datentyp definierten Funktionen sind als Member-Funktionen der betreffenden class tVecObj enthalten.
Die Konstruktoren können vier Formen annehmen:
vector(); // kein Speicher zugewiesen; size auf 0 gesetzt
vector( ui size ); // Vektor von size Elementen erzeugt
vector( ui size, T fill ); // desgleichen, aber mit "fill" initialisiert
vector( vector<T> init ); // erzeugt eine Kopie des Vektors "init"

Für alle Vektor-Klassen sind die arithmetischen Operatoren
+    -    *    /    +=    -=    *=    /=
definiert, mit der Ausnahme, daß für die polar-komplexen Vektor-Klassen nur Multiplikationen und Divisionen, nicht aber Addition und Subtraktion unterstützt werden. Diese Operatoren stellen den einzigen Fall dar, in dem das Ergebnis einer Berechnung direkt einem Vektor-Objekt zugewiesen werden kann, wie z.B.
fVecObj Z = X + Y; oder
fVecObj Z = X * 3.5;
Man beachte aber, daß die Syntax-Regeln von C++ eine wirklich effiziente Implementierung dieser Operatoren nicht zulassen. Die arithmetischen Member-Funktionen sind wesentlich schneller. Wenn es auf Rechengeschwindigkeit ankommt, benutze man daher die letzteren anstelle der Operatoren-Syntax:
fVecObj Z.addV( X, Y ); oder
fVecObj Z.mulC( X, 3.5 );

Der Operator * bedeutet Multiplikation der einzelnen Elemente miteinander und nicht das Skalarprodukt zwier Vektoren.

Alle übrigen arithmetischen und mathematischen Funktionen können nur als Member-Funktion des betreffenden Ausgabe-Vektors aufgerufen werden, wie z.B. Y.exp(X). Obwohl es sicher logischer wäre, auch diese Funktionen so zu definieren, daß man stattdessen "Y = exp(X)" schreiben könnte, wurde die Syntax der Member-Funktionen gewählt, da sie wesentlich effizienter implementiert werden kann: Der einzige Weg, die zweite Variante zu implementieren, besteht darin, das Ergebnis der jeweiligen Funktion in einem temporären Vektor zwischenzuspeichern, der anschließend in Y kopiert wird. Hierdurch werden Rechenaufwand und Speicheranforderungen erhöht. Wir sind aber an Ihrer Meinung interessiert: Würden Sie trotzdem die Syntax "Y = func(X);" gegenüber der Member-Funktions-Syntax "Y.func(X);" vorziehen und ihre Nachteile in Kauf nehmen wollen? Bitte senden Sie uns Ihren Kommentar an support@optivec.com. Diese Syntax könnte in späteren Versionen von VecObj zur Verfügung gestellt werden.

Während die meisten VecObj-Funktionen Member-Funktionen des Ausgabe-Vektors sind, gibt es einige Funktionen, die gar keinen Ausgabe-Vektor haben. In diesen Fällen sind die Funktionen Member-Funktionen eines Eingabe-Vektors.
Beispiel: s = X.mean();.

Sollten Sie einmal in die Lage kommen, ein VecObj-Vektorobjekt mit einer "klassischen" C-VectorLib-Funktion verarbeiten zu wollen (z.B., um nur einen Teil zu verarbeiten), rufen Sie bitte die Member-Funktionen
getSize() für die Vektorlänge,
getVector() für den Zeiger (vom Typ tVector)  oder
Pelement( n ), um einen Zeiger auf das n'te Element zu bekommen.

Die Syntax aller VecObj-Funktionen wird in FUNKREF.HTM zusammen mit den zugrundeliegenden VectorLib-Funktionen behandelt, die von tVecObj gekapselt werden.

Zurück zum Inhaltsverzeichnis

4. VectorLib-Funktionen: Ein kurzer Überblick

4.1 Erzeugung, Initialisierung und Freigabe von Vektoren

Daß den bereits in C und C++ reichlich vorhandenen Operatoren und Funktionen für diese Zwecke (malloc, calloc, free, new, LocalAlloc, GlobalAlloc usw.) hier noch mehr hinzugefügt werden, hat seinen Grund darin, daß für jedes Speichermodell und jede Umgebung automatisch die optimale Methode gewählt werden soll. Die Implementation von VF_vector usw. paßt sich also der jeweiligen Umgebung an, was der Portabilität der Programme zugute kommt.

Performance-Tips:

• Die mittels VF_vector usw. erzeugten Vektoren sind an 64-Byte-Grenzen ausgerichtet zur optimalen Anpassung an die Cache-Zeilengröße der Prozessoren. Im Gegensatz hierzu sind statische Arrays ebenso wie die über den Operator new oder die Standard-Allokationsfunktionen malloc, calloc, GetMem, LocalAlloc, GlobalAlloc etc. erzeugten dynamischen Arrays nur an 4-Byte-Grenzen ausgerichtet. Für optimale Performance sollten Sie daher über VF_vector etc. erzeugte Vektoren verwenden.
• Die in der P6-Version verwendeten SIMD-Befehle verlangen an 16-Byte-Grenzen ausgerichtete Daten. Wiederum gilt: Benutzen Sie die dynamischen Vektoren von OptiVec, um die verlangte Ausrichtung zu garantieren. Die Geschwindigkeits-Einbuße bei Verwendung nicht korrekt ausgerichteter Daten beträgt bis zu 25%.
• Anstatt vieler kleiner Vektoren sollten Sie besser einen großen Vektor allozieren und die kleinen Vektoren als Teile des großen definieren, also z.B.:
  

  C/C++: X = VF_vector( 3*size); Z = (Y = X+size) + size;

  Pascal/Delphi: X := VF_vector( 3*size ); Y := VF_Pelement( X, size ); Z := VF_Pelement( Y, size );

  Runden Sie aber gegebenenfalls size so auf, daß size*sizeof( data type ) ein Vielfaches von 32 oder besser 64 wird.
• Vermeiden Sie zu häufige Allokation und Deallokation. Versuchen Sie lieber, Vektoren wiederzuverwenden.

Zur Initialisierung ganzer Vektoren (nach der Zuweisung von Speicherplatz!) mit bestimmten Werten stehen die folgenden Funktionen zur Verfügung:

VF_equ0	setzt alle Elemente gleich 0
VCF_Reequ0	setzt alle Realteile gleich 0, wobei die Imaginärteile unverändert bleiben
VCF_Imequ0	setzt alle Imaginärteile gleich 0, wobei die Realteile unverändert bleiben
VF_equ1	setzt alle Elemente gleich 1
VF_equm1	setzt alle Elemente gleich −1
VF_equC	setzt alle Elemente gleich C
VF_equV	macht einen Vektor zur Kopie eines anderen
VFx_equV	erweiterte Version des Gleichheitsoperators: Yi = a * Xi + b
VF_ramp	"Rampe": Xi = a * i + b.
VUI_ramp	"Index-Rampe": Xi = i  (nur VUI_ und VU_-Versionen)
VF_randomLC	Zufallszahlen hoher Qualität
VF_random	vereinfachte Form von VF_randomLC für Zufallszahlen hoher Qualität
VF_noiseLC	weißes Rauschen
VF_noise	vereinfachte Form von VF_noiseLC für weißes Rauschen
VF_comb	"Kamm", der an äquidistanten Punkten gleich einer Konstanten C und ansonsten 0 ist.

 

Die folgenden Funktionen dienen dem Zugriff auf einzelne Vektor-Elemente: 

VF_Pelement	gibt einen Zeiger auf das durch seinen Index bestimmte Vektor-Element zurück
VF_element	gibt ein bestimmtes Vektor-Element zurück
VF_getElement	kopiert ein bestimmtes Vektor-Element in eine Variable
VF_setElement	setzt ein Vektor-Element auf einen neuen Wert
VF_accElement	X[i] += c; addiert einen Wert zu einem Vektor-Element
VF_decElement	X[i] -= c; subtrahiert einen Wert von einem Vektor-Element

 
Die folgenden Funktionen generieren Fenster zur Verwendung in der Spektrenanalyse (siehe VF_spectrum):

VF_Hann	Hann-Fenster
VF_Parzen	Parzen-Fenster
VF_Welch	Welch-Fenster

 
Komplexe Vektoren können mittels der folgenden Funktionen initialisiert werden:

VF_ReImtoC	zwei reelle Vektoren, Re und Im, zu einem cartesisch-komplexen Vektor zusammenfassen
VF_RetoC	Realteil eines cartesisch-komplexen Vektors überschreiben
VF_ImtoC	Imaginärteil eines cartesisch-komplexen Vektors überschreiben
VF_PolartoC	Cartesisch-komplexen Vektor aus Polarkoordinaten konstruieren, die als getrennte Vektoren Mag und Arg vorliegen
VF_MagArgtoP	zwei reelle Vektoren, Mag und Arg, zu einem polar-komplexen Vektor zusammenfassen
VF_MagArgtoPrincipal	zwei reelle Vektoren, Mag und Arg, zu einem polar-komplexen Vektor zusammenfassen und die Zeigerwinkel auf den Hauptwert normieren: -p < Arg ≤ +p
VF_MagtoP	Mag-Teil eines polar-komplexen Vektors überschreiben
VF_ArgtoP	Arg-Teil eines polar-komplexen Vektors überschreiben
VF_ReImtoP	Polar-komplexen Vektor aus cartesischen Koordinaten konstruieren, die als getrennte Vektoren Re und Im vorliegen

Zurück zum Inhaltsverzeichnis

4.2 Index-orientierte Manipulationen

Operationen, die nur auf eine Untermenge von Elementen (z.B. auf jedes vierte, zehnte o.ä.) angewandt werden sollen, werden durch die Funktionsfamilie VF_subvector_... zur Verfügung gestellt, wobei die drei Punkte für ein Suffix stehen, daß die jeweilige Operation bezeichnet:

VF_subvector_equC Xi*samp = C,   i=0,...subsize−1 VF_subvector_addC Xi*samp += C,   i=0,...subsize−1 VF_subvector_subC Xi*samp -= C,   i=0,...subsize−1 VF_subvector_subrC Xi*samp = C - Xi*samp,   i=0,...subsize−1 VF_subvector_mulC Xi*samp *= C,   i=0,...subsize−1 VF_subvector_divC Xi*samp /= C,   i=0,...subsize−1 VF_subvector_divrC Xi*samp = C / Xi*samp,   i=0,...subsize−1

VF_subvector_equV Yi*samp = Yi,   i=0,...subsize−1 VF_subvector_addV Xi*samp += Yi,   i=0,...subsize−1 VF_subvector_subV Xi*samp -= Yi,   i=0,...subsize−1 VF_subvector_subrV Xi*samp = Yi - Xi*samp,   i=0,...subsize−1 VF_subvector_mulV Xi*samp *= Yi,   i=0,...subsize−1 VF_subvector_divV Xi*samp /= Yi,   i=0,...subsize−1 VF_subvector_divrV Xi*samp = Yi / Xi*samp,   i=0,...subsize−1

 

Dem Durchsuchen von Tabellen nach bestimmten Werten dienen:

VF_searchC	sucht das einem Wert C am nächsten kommende Element eines Vektors, wobei ein Parameter mode darüber entscheidet, ob das absolut nächste, das nächste "größere-oder-gleiche" oder das nächste "kleinere-oder-gleiche" gewählt werden
VF_searchV	dasselbe für ein ganzes Feld von Suchwerten

 
An Interpolations-Routinen stellt OptiVec zur Verfügung:

VF_polyinterpol	Polynom-Interpolation
VF_ratinterpol	rationale Interpolation
VF_natCubSplineInterpol	"natürliche" kubische Spline-Interpolation
VF_splineinterpol	allgemeine kubische Spline-Interpolation

 

Zurück zum Inhaltsverzeichnis

4.3 Datentyp-Umwandlungen

Zurück zum Inhaltsverzeichnis

4.4 Nähere Informationen zur Ganzzahl-Arithmetik

So wird man im Datentyp short / SmallInt als Ergebnis der Multiplikation 5 * 20000 die vielleicht unerwartete Zahl -31072 erhalten. Das "korrekte" Resultat, 100000, übersteigt den darstellbaren Bereich von short/SmallInt-Zahlen, -32768 ≤ x ≤ +32767. short / SmallInt sind 16-bit-Zahlen, also ist n = 16 und 2ⁿ = 65536. Man kann sich das Zustandekommen des erhaltenen Resultates also so vorstellen, als ob der Prozessor 2 * 65536 = 131072 von 100000 abgezogen hätte, was -31072 ergibt.

Überlaufende Zwischenergebnisse werden nicht durch nachfolgende Operationen "geheilt". Das Ergebnis der Berechnung von (5 * 20000) / 4 ist nicht – wie man vielleicht hoffen könnte – +25000, sondern -7768.

Zurück zum Inhaltsverzeichnis

4.5 Grundfunktionen komplexer Vektoren

Zurück zum Inhaltsverzeichnis

4.6 Mathematische Funktionen

Mit Ausnahme der einfachen arithmetischen Funktionen (Addition, Subtraktion etc.), existieren die mathematischen Funktionen nur für die Fließkomma-Datentypen. Die meisten mathematischen Funktionen von VectorLib sind als vektorisierte Versionen der entsprechenden Funktionen von ANSI-C oder Pascal zu verstehen oder von diesen abgeleitet. In C/C++ werden Fehler grundsätzlich über die vom Compiler zur Verfügung gestellten (oder vom Anwender selbst geschriebenen) Funktionen _matherr und (bei Borland C++) _matherrl behandelt. In Pascal/Delphi bietet OptiVec dem Anwender die Möglichkeit, das Verhalten im Fehlerfall über die Funktion V_setFPErrorHandling festzulegen.
Zusätzlich zu dieser Fehlerbehandlung "pro Element" wird noch durch den Rückgabewert der Vektor-Funktion angegeben, ob die Berechnung für alle Elemente erfolgreich war oder ob irgendein Fehler auftrat. Im Falle fehlerfreier Verarbeitung ist der Rückgabewert FALSE (0), sonst TRUE (irgendeine Zahl ungleich 0).

Zurück zum Inhaltsverzeichnis

4.6.1 Rundung

Zurück zum Inhaltsverzeichnis

4.6.2 Vergleiche

Die zweite Möglichkeit ist, dass –durch einen Unterstrich abgesetzt –die zu testende Bedingung angegeben wird. Das Resultat ist TRUE oder FALSE und wird als 1 oder 0, wieder in demselben Datentyp wie die Eingabe-Vektoren, gespeichert. Der Ergebnis-Vektor kann dann beispielsweise in Zeitreihen-Analyse-Aufgaben mit dem Eingabe-Vektor multipliziert werden, um nicht-konforme Eingabe-Elemente zu eliminieren. Beispiele sind:
 

VF_cmp_eq0  /  _eqC  /  _eqV	Xi =  0  /  C  /  Yi ?   (engl. "equal")
VF_cmp_ne0  /  _neC  /  _neV	Xi ≠ 0  /  C  /  Yi ?   (engl. "not equal")
VF_cmp_gt0  /  _gtC  /  _gtV	Xi > 0  /  C  /  Yi ?   (engl. "greater than")
VF_cmp_ge0  /  _geC  /  _geV	Xi ≥ 0  /  C  /  Yi ?   (engl. "greater or equal")
VF_cmp_lt0  /  _ltC  /  _ltV	Xi < 0  /  C  /  Yi ?   (engl. "less than")
VF_cmp_le0  /  _leC  /  _leV	Xi ≤ 0  /  C  /  Yi ?   (engl. "less or equal")
VF_cmp_stV	Xi ≈  Yi ?   (engl. "similar to")
VF_cmp_dtV	Xi ≉ Yi ?   (engl. "dissimilar to")

Als dritte Möglichkeit schießlich können die Indizes derjenigen Elemente in einem Index-Array abgelegt werden, für die die Bedingung als TRUE gefunden wurde, z.B.:
 

VF_cmp_neCind	Indizes der Elemente Xi != C
VD_cmp_lt0ind	Indizes der Elemente Xi < 0
VE_cmp_geVind	Indizes der Elemente Xi ≥ Yi

Während die eben beschriebenen einfachen Vergleichsfunktionen nur bezüglich einer einzigen Grenze testen, existieren einige Funktionen, die feststellen, ob Vektorelemente in einen durch zwei Grenzpunkte bestimmten Bereich fallen:
 

VF_cmp_inclrange0C	TRUE für 0 ≤ x ≤ C (C positiv), 0 ≥ x ≥ C (C negativ)
VF_cmp_exclrange0C	TRUE für 0 < x < C (C positiv), 0 > x > C (C negativ)
VF_cmp_inclrangeCC	TRUE für CLo ≤ x ≤ CHi
VF_cmp_exclrangeCC	TRUE für CLo < x < CHi
VF_cmp_inclrange0Cind	Indizes der Elemente 0 ≤ Xi ≤ C  (C positiv) oder  0 ≥ Xi > C  (C negativ)
VF_cmp_exclrange0Cind	Indizes der Elemente 0 < Xi < C  (C positiv) oder  0 > Xi > C  (C negativ)
VF_cmp_inclrangeCCind	Indizes der Elemente CLo ≤ Xi ≤ CHi
VF_cmp_exclrangeCCind	Indizes der Elemente CLo < Xi < CHi

Interessiert nicht das Ergebnis für jedes einzelne Vektor-Element, sondern nur die Anzahl der Elemente, so erhält man diese durch die Funktionen der VF_cnt_...-Familie ("cnt" kurz für engl. "to count" = "zählen"), z.B.:

VF_cnt_eq0	Anzahl der Elemente Xi = 0
VF_cnt_gtC	Anzahl der Elemente Xi > C
VF_cnt_inclrangeCC	Anzahl der Elemente CLo ≤ Xi ≤ CHi
VF_cnt_leV	Anzahl der Elemente Xi ≤ Yi
VF_cmp_ne0  /  _neC  /  _neV	Xi != 0  /  C  /  Yi ?   (engl. "not equal")

Um zu testen, ob sich in einer Tabelle bestimmte Werte finden, können die folgenden Funktionen benutzt werden:

VF_iselementC	TRUE, wenn C ein Element der als Eingabevektor übergebenen Tabelle ist
VF_iselementV	prüft für jedes Element von X, ob es in der Tabelle Tab enthalten ist

Zurück zum Inhaltsverzeichnis 

4.6.3 Direkte Bit-Manipulationen

Zurück zum Inhaltsverzeichnis

4.6.4 Arithmetische Grundfunktionen, Akkumulation

Neben diesen Grundfunktionen sind auch häufig gebrauchte Kombinationen von Addition und Division sowie die Pythagoras-Formel aufgenommen:
 

VF_reldiffC Yi = (Xi − C)  /  |C| VF_reldevC Yi = |Xi − C|  /  |C| VF_hypC Yi = Xi  /  (Xi + C) VF_redC Yi = (Xi * C)  /  (Xi + C) VF_visC Yi = (Xi − C)  /  (Xi + C) VF_hypotC Yi = sqrt( Xi² + C² )

VF_reldiffV Zi = (Xi − Yi)  /  max(|Xi|, |Yi|) VF_reldevV Zi = |Xi − Yi|  /  max(|Xi|, |Yi|) VF_hypV Zi = Xi  /  (Xi + Yi) VF_redV Zi = (Xi * Yi)  /  (Xi + Yi) VF_visV Zi = (Xi - Yi)  /  (Xi + Yi) VF_hypotV Zi = sqrt( Xi² + Yi²)

Die Funktionen in der rechten Kolumne der obigen beiden Abschnitte existieren zusätzlich noch in erweiterter Form. Diese wird durch durch das Präfix "VFx_" angegeben (das "x" stammt aus der englischen Bezeichnung "expanded"). Hier wird die jeweilige Funktion nicht für X_i selbst, sondern für (a * X_i + b) berechnet, z.B.
 

VFx_addV	Zi = (a * Xi + b) + Yi
VFx_divrV	Zi = Yi  /  (a * Xi + b)

Für die vier Grundrechenarten existiert noch eine weitere Spezialform, bei der das Ergebnis mit einem konstanten Faktor multipliziert wird. Diese "skalierte" Version wird durch den zusätzlichen Buchstaben "s" im Präfix angegeben:
 

VFs_addV	Zi = C * (Xi + Yi)
VFs_subV	Zi = C * (Xi - Yi)
VFs_mulV	Zi = C * (Xi * Yi)
VFs_divV	Zi = C * (Xi / Yi)

Unter den weiteren einfachen arithmetischen Operationen seien genannt:
 

VF_maxC	setzt Yi gleich Xi oder C, je nachdem, welcher von beiden Werten der größere ist
VF_minC	wählt den kleineren Wert aus Xi und C
VF_maxV	wählt den größeren Wert aus Xi und Yi und speichert ihn als Zi
VF_minV	wählt den kleineren Wert aus Xi und Yi und speichert ihn als Zi
VF_limit	führt eine Begrenzung des Zahlenbereiches durch
VF_flush0	setzt alle Werte unterhalb eines als Parameter übergebenen Absolut-Schwellenwertes gleich 0
VF_flushInv	berechnet das Inverse aller Werte oberhalb eines als Parameter übergebenen Absolut-Schwellenwertes und setzt das Ergebnis für alle anderen gleich 0
VF_absHuge	ersetzt negative Polstellen durch positive
VF_intfrac	spaltet Zahlen in ihre Ganzzahl- und Bruchzahl-Anteile auf
VF_mantexp	trennt Zahlen in Mantisse und Exponent

Während allgemein alle OptiVec-Funktionen Ein- und Ausgabe-Vektoren desselben Datentyps verarbeiten, existieren die arithmetischen Funktionen auch für "gemischte" Operationen zwischen Fließkomma- und Ganzzahltypen, wobei das Ergenis stets in dem Fließkomma-Typ gespeichert wird, z.B.:
 

VF_addVI	fVector Z = fVector X + iVector Y
VD_mulVUL	dVector Z = dVector X * ulVector Y
VE_divrVBI	eVector Z = biVector Y / eVector X

In ähnlicher Weise existieren Funktionen für die Akkumulation von Daten in entweder demselben oder in höher-genauen Datentypen. Diese Funktionen entsprechen der Operation Y += X. Beispiele sind:
 

VF_accV	fVector Y += fVector X
VD_accVF	dVector Y += fVector X
VF_accVI	fVector Y += iVector X
VQI_accVLI	qiVector Y += liVector X

Innerhalb der Fließkomma-Datentypen besteht zusätzlich die Möglichkeit, gleich zwei Vektoren auf einmal zu akkumulieren:

VF_acc2V	fVector Y += fVector X1 + fVector X2
VD_acc2VF	dVector Y += fVector X1 + fVector X2

Ebenfalls nur innerhalb der Fließkomma-Datentypen existieren Funktionen zur Akkumulation von Quadraten und Produkten:

VF_accV2	fVector Y += fVector X2
VD_accVF2	dVector Y += fVector X2
VCF_accVmulVconj	cfVector Y += cfVector X * cfVector Y*

Zurück zum Inhaltsverzeichnis 

4.6.5 Geometrische Vektor-Arithmetik

Werden andererseits die Koordinaten mehrerer Punkte in einer Ebene entweder in zwei getrennten Vektoren X und Y oder in einem komplexen Vektor gespeichert, so existiert eine Funktion zur Rotation dieser Koordinaten:

VF_rotateCoordinates	Rotation der durch zwei Vektoren X und Y angegebenen Koordinaten mehrer Punkte in einer Ebene gegen den Uhrzeigersinn; die neuen Koordinaten werden als Xrot und Yrot gespeichert.
VCF_rotateCoordinates	Rotation der durch Real- und Imaginärteil des komplexen Vektors XY angegebenen Koordinaten mehrer Punkte in einer Ebene gegen den Uhrzeigersinn; die neuen Koordinaten werden als Real- und Imaginärteil des komplexen Vektors XYrot gespeichert.

Zurück zum Inhaltsverzeichnis 

4.6.6 Potenzen

Während bei allen eben genannten Funktionen spezifizierte Potenzen beliebiger Zahlen erhalten werden, ist es bei der nun folgenden Gruppe von Funktionen umgekehrt:
 

VF_pow10	reelle Potenzen von 10
VF_ipow10	ganzzahlige Potenzen von 10 (als Fließkomma-Zahlen gespeichert)
VF_pow2	reelle Potenzen von 2
VF_ipow2	ganzzahlige Potenzen von 2 (als Fließkomma-Zahlen gespeichert)
VF_exp	Exponentialfunktion
VF_exp10	Exponentialfunktion zur Basis 10 (identisch mit VF_pow10)
VF_exp2	Exponentialfunktion zur Basis 10 (identisch mit VF_pow2)
VF_expArbBase	Exponentialfunktion zu beliebiger Basis

 
Alle diese Funktionen existieren auch in der erweiterten "VFx_"-Form, wie z.B.
VFx_square: Y_i = (a * X_i + b)² 
Die erweiterte Form der ungeschützten Funktionen hat das Präfix VFux_.

Die äquivalenten Funktionen für komplex-zahlige Vektoren sind ebenfalls vorhanden, sowohl für cartesische als auch in Polarkoordinaten. Zusätzlich werden zwei Spezialfälle behandelt:
 

VCF_powReExpo	reelle Potenzen komplexer Zahlen
VCF_exptoP	übernimmt einen cartesischen Eingabevektor und gibt dessen Exponentialfunktion in Polarkoordinaten zurück

Zurück zum Inhaltsverzeichnis 

4.6.7 Exponential- und Hyperbel-Funktionen

Zurück zum Inhaltsverzeichnis 

4.6.8 Logarithmen

Als Sonderform des Zehner-Logarithmus ist die Formel für die Optische Dichte, OD = log10( X0/X ) anzusehen. Aufgrund ihrer Bedeutung in der experimentellen naturwissenschaftlichen Arbeit ist sie hier in mehreren Varianten aufgenommen, von denen einige Beispiele in der folgenden Tabelle zusammengefaßt sind: 

VF_OD	OD = log10( X0/X ) für fVector als Eingabe und als Ausgabe
VF_ODwDark	Optische Dichte mit Dunkelstrom-Korrektur: OD = log10( (X0−X0Dark) / (X−XDark) ) für fVector als Eingabe und als Ausgabe
VUS_ODtoF	OD in float / Single-Genauigkeit für usVector als Eingabe
VUL_ODtoD	OD in double-Genauigkeit für ulVector als Eingabe
VQI_ODtoEwDark	OD mit Dunkelstrom-Korrektur in extended-Genauigkeit für qiVector als Eingabe

Zurück zum Inhaltsverzeichnis 

4.6.9 Trigonometrische Funktionen

Die Quadrate der trigonometrischen Funktionen werden gebildet durch:
 

VF_sin2	Sinus²
VFr_sin2	Sinus² für -2p ≤ Xi ≤ +2p
VF_cos2	Cosinus²
VFr_cos2	Cosinus² für -2p ≤ Xi ≤ +2p
VF_sincos2	Sinus² und Cosinus² gleichzeitig
VFr_sincos2	Sinus² und Cosinus² für -2p ≤ Xi ≤ +2p
VF_tan2	Tangens²
VF_cot2	Cotangens²
VF_sec2	Secans²
VF_cosec2	Cosecans²

 
Ein sehr effizienter Weg zur Berechnung trigonometrischer Funktionen für Argumente, die sich als gebrochenzahlige Vielfache von p (PI) darstellen lassen, wird durch die Funktionen mit dem Suffix "rpi" (für "rationale Vielfache von p") bereitgestellt. Hier ist r = p / q, wobei q konstant und p durch die Eingabevektor-Elemente gegeben ist:
 

VF_sinrpi	Sinus von p/q * p
VF_cosrpi	Cosinus von p/q * p
VF_sincosrpi	Sinus und Cosinus von p/q * p at once
VF_tanrpi	Tangens von p/q * p
VF_cotrpi	Cotangens von p/q * p
VF_secrpi	Secans von p/q * p
VF_cosecrpi	Cosecans von p/q * p

Spezialisierte Versionen gebrauchen Tabellen, um häufig vorkommende Werte direkt zu lesen, anstatt sie berechnen zu müssen. Die werden durch die Suffixe "rpi2" (Vielfache von p dividiert durch eine ganzzahlige Potenz von 2) und "rpi3" (Vielfache von p dividiert durch ein ganzzahliges Vielfaches von 3) bezeichnet. Beispiele sind:
 

VF_sinrpi2	Sinus von p / 2n * p
VF_tanrpi3	Tangens von p / (3*n) * p

Zwei spezielle trigonometrische Funktionen sind: 

VF_sinc	Sinc-Funktion, Yi = sin( Xi ) / Xi
VF_Kepler	Kepler-Funktion (zeitabhängige Winkelposition eines Himmelskörpers nach dem Zweiten Keplerschen Gesetz bei gegebener Umlaufzeit und Exzentrizität)

Vektorisierte inverse trigonometrische Funktionen (die "Arcus"-Funktionen) stehen zur Verfügung als: 

VF_asin	Arcus-Sinus
VF_acos	Arcus-Cosinus
VF_atan	Arcus-Tangens
VF_atan2	Arcus-Tangens von Quotienten, Zi = atan( Yi / Xi )

Zurück zum Inhaltsverzeichnis 

4.7 Analysis

Die komplexen Äquivalente der zuletzt genannten Gruppe von Funktionen sind:
 

VCF_maxReIm	größter Real- und größter Imaginärteil einzeln
VCF_minReIm	kleinster Real- und kleinster Imaginärteil einzeln
VCF_absmaxReIm	betragsmäßig größter Real- und Imaginärteil einzeln
VCF_absminReIm	betragsmäßig kleinster Real- und Imaginärteil einzeln
VCF_absmax	größter Absolutwert (Zeigerlänge; dies ist eine reelle Zahl)
VCF_absmin	kleinster Absolutwert (Zeigerlänge)
VCF_cabsmax	komplexe Zahl mit dem größten Absolutwert
VCF_cabsmin	komplexe Zahl mit dem kleinsten Absolutwert
VCF_sabsmax	komplexe Zahl mit der größten Summe |Re| + |Im|
VCF_sabsmin	komplexe Zahl mit der kleinsten Summe |Re| + |Im|
VCF_absmaxind	größter Absolutwert und sein Index
VCF_absminind	kleinster Absolutwert und sein Index

Summen, Produkte usw. werden durch die in chapter 4.9 als Statistik-Funktionen zusammengefaßten Routinen gebildet.

Zur Berechnung des Schwerpunktes eines Vektors stehen zwei Funktionen zur Verfügung:
 

VF_centerOfGravityInd	Schwerpunkt eines Vektors in Form eines interpolierten Element-Indexes
VF_centerOfGravityV	Schwerpunkt eines Y-Vektors bei explizit gegebener X-Achse

Zurück zum Inhaltsverzeichnis 

4.8 Signalverarbeitung:
Fourier-Transformations-Techniken

Alle genannten Funktionen benötigen intern zusätzlichen Pufferspeicher, den sie selbst allozieren und wieder freigeben. Um diese Ineffizienz bei wiederholten Aufrufen umgehen zu können, existiert von allen diesen Funktionen eine durch das Präfix VFb_ gekennzeichnete Version, die einen Zeiger auf vom Aufrufer zur Verfügung gestellten Pufferspeicher als zusätzliches Argument übernimmt. Die notwendige Mindestgröße des Pufferspeichers ist in FUNKREF.HTM für jede Funktion einzeln angegeben.

Obwohl sie keine Fourier-Transformation benutzen, sollen in diesem Zusammenhang die Funktionen VF_biquad für bi-quadratische Audio-Filterung sowie VF_smooth (engl. to smooth = glätten) als einer etwas groben Form der Frequenzfilterung genannt werden.

Zurück zum Inhaltsverzeichnis 

4.9 Statistische Funktionen und Bausteine

Zurück zum Inhaltsverzeichnis 

4.10 Datenanpassung

Eine detaillierte Beschreibung der verschiedenen Konzepte zur Datenanpassung an die unterschiedlichen Klassen von Modellfunktionen wird in Kap. 13 von MATRIXD.HTM gegeben. Daher genüge an dieser Stelle eine tabellarische Zusammenfassung der vorhandenen X-Y-Anpassungsroutinen:
 

VF_linregress	lineare Regression von X-Y-Daten mit gleicher Wichtung aller Datenpunkte
VF_linregresswW	dasselbe mit ungleicher Wichtung
VF_polyfit	Koeffizienten eines Polynoms an vorhandene X-Y-Daten anpassen
VF_polyfitwW	dasselbe mit ungleicher Wichtung der Datenpunkte
VF_polyfitOdd	Koeffizienten eines nur aus ungeraden Termen bestehenden Polynoms an vorhandene X-Y-Daten anpassen
VF_polyfitOddwW	dasselbe mit ungleicher Wichtung der Datenpunkte
VF_polyfitEven	Koeffizienten eines nur aus geraden Termen bestehenden Polynoms an vorhandene X-Y-Daten anpassen
VF_polyfitEvenwW	dasselbe mit ungleicher Wichtung der Datenpunkte
VF_linfit	Koeffizienten einer beliebigen, in ihren Parametern linearen Funktion an vorhandene X-Y-Daten anpassen
VF_linfitwW	dasselbe mit ungleicher Wichtung der Datenpunkte
VF_nonlinfit	Koeffizienten einer beliebigen, möglicherweise nicht-linearen Funktion an vorhandene X-Y-Daten anpassen
VF_nonlinfitwW	dasselbe mit ungleicher Wichtung der Datenpunkte
VF_multiLinfit	mehrere X-Y-Datensätze gleichzeitig an eine gemeinsame lineare Funktion anpassen
VF_multiLinfitwW	dasselbe mit ungleicher Wichtung der Datenpunkte
VF_multiNonlinfit	mehrere X-Y-Datensätze gleichzeitig an eine gemeinsame nicht-lineare Funktion anpassen
VF_multiNonlinfitwW	dasselbe mit ungleicher Wichtung der Datenpunkte

Zurück zum Inhaltsverzeichnis 

4.11 Input und Output

Die folgenden Funktionen modifizieren die Standardeinstellung für VF_write,   VF_nwrite und VI_read:
 

VF_setWriteFormat	bestimmtes Ausgabeformat vorgeben
VF_setWriteSeparate	Trennzeichen zwischen aufeinander folgenden Element für VF_write vorgeben
VF_setNWriteSeparate	Trennzeichen zwischen den durch VF_nwrite geschriebenen Spalten definieren
V_setRadix	für die ganzzahligen V.._read-Funktionen eine andere als die als Standard angenommene Basis 10 einstellen.

Zurück zum Inhaltsverzeichnis 

4.12 Graphik

VectorLib unterscheidet zwei Arten von Plot-Funktionen: AutoPlot und DataPlot. Alle AutoPlot-Funktionen (z.B. VF_xyAutoPlot) führen die folgenden Schritte durch:

1. Definition eines geeigneten Viewports innerhalb des standardmäßig eingestellten oder mittels V_setPlotRegion gewählten Fensterausschnitts
2. Löschen des vorhandenen Viewport-Inhalts
3. Erzeugung eines cartesischen Koordinatensystems mit geeigneter Achsenskalierung
4. Unterteilung und Beschriftung der Achsen entweder linear oder logarithmisch, entsprechend dem Suffix der gewählten AutoPlot-Funktion:

   V?_autoPlot (kein Suffix):	sowohl X-Achse als auch Y-Achse linear.
   V?_autoPlot_xlg_ylin:	X-Achse logarithmisch, Y-Achse linear.
   V?_autoPlot_xlg_ylg:	sowohl X-Achse also auch Y-Achse logarithmisch.
   V?_autoPlot_xlin_ylg:	X-Achse linear, Y-Achse logarithmisch.

5. Auftragung der Daten gemäß den an die jeweilige Funktion übergebenen Parametern

Vektoren aus cartesisch-komplexen Zahlen werden in der komplexen Ebene dargestellt, d.h. die Imaginärteile gegen die Realteile aufgetragen. Hierzu dienen
 

VCF_autoPlot	Auftragung eines cartesisch-komplexen Vektors
VCF_2AutoPlot	gleichzeitige Auftragung zweier komplexer Vektoren
VCF_dataPlot	Hinzufügung eines weiteren komplexen Vektors zu einer bestehenden Auftragung

Funktionen zur Auftragung polar-komplexer Vektoren sind derzeit nicht enthalten.
Es ist möglich, mehrere Koordinatensysteme in ein-und-dasselbe Fenster zu zeichnen. Die Position jedes Koordinatensystems muss über die oben erwähnte Funktion V_setPlotRegion spezifiziert werden. Dem Umschalten zwischen ver- schiedenen Koordinatensystemen (z.B. um neue DataPlots hinzuzufügen) dienen die folgenden Funktionen:
 

V_continuePlot	Wiederherstellung des zuletzt für einen Plot verwendeten Viewports und der zugehörigen Achsen-Skalierungen
V_getCoordSystem	Speichern der Position und Skalierungen eines Koordinatensystems
V_setCoordSystem	Wiederherstellung von Position und Skalierungen eines Koordinatensystems. Diese müssen zuvor mittels V_getCoordSystem gespeichert worden sein.

Zurück zum Inhaltsverzeichnis 

5. Fehlerbehandlung

5.1 Allgemeines

Die Produktions-Bibliotheken von OptiVec behandeln alle mathematischen Fehler (Überlauf, Singularitäten, Bereichsfehler, Genauigkeits-Verlust) "stillschweigend" und setzen die Programmausführung mit einem wenn möglich in den darstellbaren Bereich hinein korrigierten Ergebnis fort.
Die Debug-Bibliotheken zeigen Fehler zusätzlich durch Ausgabe einer Meldung an. Wie unten noch näher erklärt, kann mit Hilfe der Funktion V_setFPErrorHandling eingestellt werden, welche Fehler tatsächlich gemeldet werden. Die Funktion V_setErrorEventFile wiederum erlaubt die Auswahl zwischen Meldungs-Ausgabe in eine Datei, ein Popup-Window oder ein Text-Fenster.
Eine Folge identischer Fehler innerhalb ein- und derselben OptiVec-Funktion führt immer nur zu einer einzigen Meldung. Nachfolgende identische Meldungen werden unterdrückt.

Dem Abfangen und Behandeln von Fehlern sind allerdings Grenzen gesetzt, insbesondere für den Überlauf-Schutz innerhalb der extended-, teilweise auch der double-Versionen von OptiVec-Funktionen. Der Programmierer sollte generell darauf achten, dass konstante Paramater bei der Übergabe an Funktionen sicherheitshalber nicht größer als 1.E32 für float / Single, 1.E150 für double und 1.E2000 für extended sind.

In den "erweiterten" Versionen aller extended-genauen Funktionen (also denen mit den Präfixen VEx_ und VCEx_; z.B. VEx_exp) wird generell kein Überlauf-Schutz für die Berechnung des Zwischenergebnisses A*X_i+B gewährt, sondern nur für den Kern der Funktion selbst und für die abschließende Multiplikation mit dem Skalierungsfaktor C.

Zwischen Fließkomma- und Ganzzahlen besteht ein grundsätzlicher Unterschied bezüglich OVERFLOW- und DOMAIN- Fehlern: Für Fließkommazahlen sind dies ernst zu nehmende (OVERFLOW) bzw. zur Unbrauchbarkeit des Ergebnisses führende (DOMAIN) Fehler. Demgegenüber wird für Ganzzahlen eine implizite modulo-2ⁿ-Arithmetik verwendet, bei der diese "Fehler" gar nicht als solche betrachtet werden. Im Gegenteil: Häufig wird sogar der Überlauf als schnelles Mittel der modulo-Division ausgenutzt. In den folgenden beiden Abschnitten wird die Fehlerbehandlung von Fließkomma- und Ganzzahlen detailliert dargestellt.

Zurück zum Inhaltsverzeichnis

5.2 Ganzzahl-Fehler

Nur 32-bit-Versionen (also nicht für 64-bit):
Alle Funktionen, in denen INTEGER OVERFLOW (z.B. in VI_ramp,  VI_mulV, etc.) oder INTEGER DOMAIN-Fehler (z.B. in V_ItoU für negative X-Werte) auftreten können, existieren in zwei Varianten: Die Normalversion wendet implizite modulo-2ⁿ-Arithmetik an und wandelt vorzeichenbehaftete und vorzeichenlose Typen gemäß ihrem Bitmuster ineinander um. Für die 16-bit- und 32-bit-Ganzzahltypen (nicht aber für 8-bit und 64-bit) gibt es eine zweite Version, die zwar auch modulo-2ⁿ-Arithmetik anwendet, Fehler aber detektiert. Diese zweite Variante wird durch den Buchstaben "o" (für "OVERFLOW-Detektion") im Präfix angegeben: VIo_,  VSIo_,  VULo_, usw. Für die Ganzzahl-Datentypumwandlungsfunktionen wird das Präfix V_ zu Vo_ erweitert. Was im Falle eines Fehlers zu geschehen hat, wird durch einen Aufruf der Funktion V_setIntErrorHandling festgelegt. Diese benötigt ein Argument des Typs V_ihand (definiert in <VecLib.h> bzw. in der Unit VecLib), das drei verschiedene Werte annehmen kann:
 

ierrNote	Ausgabe einer Fehlermeldung und Fortsetzung des Programmes
ierrAbort	Ausgabe einer Fehlermeldung und Abbruch des Programmes
ierrIgnore	Fehler ignorieren; mit dieser Option läßt sich die Fehlerbehandlung für einzelne Stellen im Programm wieder ausschalten.

Obwohl ein Aufruf von
V_setIntErrorHandling( ierrIgnore );
im Prinzip verwedet werden kann, um die Fehlerbehandlung auszuschalten, ist es stets besser, einfach die Normalversion (Präfix VI_) anstelle der VIo_-Version mit überbrückter Fehlerbehandlung zu verwenden, da die Normalversion immer um ein Vielfaches schneller ist.

nur C/C++:
Um die Überlauf-abfangede Variante nicht nur für einzelne Funktionsaufrufe, sondern überall zu verwenden, ist der einfachste Weg, die symbolische Konstante V_trapIntError im Programmkopf vor(!) Einschluß von <VecLib.h> zu definieren, z.B.
#define V_trapIntError 1
#include <VIstd.h>
#include <VImath.h>
.....
main() /* oder WinMain() oder OwlMain() */
{
  siVector SI1, SI2;
  I1 = VSI_vector( 1000 ); SI2 = VSI_vector( 1000 );
  V_setIntErrorHandling( ierrNote );
  VSI_ramp( SI1, 1000, 0, 50 ); /* hier wird ein Überlauf auftreten! */
  V_setIntErrorHandling( ierrIgnore );
  VSI_mulC( SI2, SI1, 1000, 5 );
    /* hier entsteht zwar eine ganze Serie von Überläufen, die aber alle ignoriert werden */
  ....
}

Zurück zum Inhaltsverzeichnis

5.3 Fließkomma-Fehler

Für jede Funktion werden die möglichen Fehlerarten, die abgefangen und behandelt werden, in der Funktions-Referenz aufgeführt. Alle von mathematischen ANSI C- oder Pascal/Delphi-Funktionen abgeleiteten VectorLib-Funktionen (also diejenigen, deren Deklaration sich in <V?math.h> bzw. den Units V?math findet) führen eine vollständige Fehlerbehandlung für jedes Vektorelement durch. Über diese Fehlerbehandlung "pro Element" hinaus wird mit Hilfe des Rückgabewertes angegeben, ob insgesamt irgendein Fehler auftrat oder nicht. Ein Rückgabewert von FALSE (0) bedeutet Fehlerfreiheit; Rückgabewerte von TRUE (ungleich 0) zeigen aufgetretene (und behandelte) Fehler an.

Nur für Debug-Bibliotheken: Wie oben bereits erwähnt, kann durch Aufruf von V_setFPErrorHandling eingestellt werden, welche Fehlerarten zu einer Meldung und welche ggf. zu einem Programm-Abbruch führen. Die vorhandenen Optionen werden durch vordefinierte Konstanten fperrXXX gesetzt:

Konstante	Bedeutung
fperrIgnore	Sämtliche Fließkommafehler stillschweigend behandeln
fperrNoteDOMAIN	Bereichsfehler melden
fperrAbortDOMAIN	Meldung und Programmabbruch bei Bereichsfehlern
fperrNoteSING	Singularitäten (meist Divisionen durch 0) melden
fperrAbortSING	Meldung und Programmabbruch bei Singularitäten
fperrNoteOVERFLOW	Überlauf melden
fperrAbortOVERFLOW	Meldung und Programmabbruch bei Überlauf
fperrNoteTLOSS	Totalen Genauigkeitsverlust (z.B. bei sin(1.e30)) melden
fperrAbortTLOSS	Meldung und Programmabbruch bei Totalem Genauigkeitsverlust
fperrDefault	Standardeinstellung = fperrAbortDOMAIN + fperrNoteSING + fperrNoteOVERFLOW

 
Beim Aufruf von V_setFPErrorHandling sollten diese Konstanten addiert oder mit dem OR-Operator verknüpft werden. Man beachte, dass dies nur die Behandlung von Fehlern beeinflußt, die innerhalb von OptiVec-Funktionen auftreten. Die zu C/C++ oder Pascal/Delphi gehörenden Standard-Funktionen bleiben hiervon unberührt.

Bei der nun folgenden Beschreibung der einzelnen möglichen Fehler wird als "HUGE_VAL" der größte im jeweiligen Datentyp darstellbare Wert bezeichnet, also MAX_FLT,  MAX_DBL oder MAX_LDBL, je nach Typ. Ähnlich wird mit "TINY_VAL" der kleinste eben noch darstellbare Wert ungleich 0 bezeichnet. Dies ist nicht dasselbe wie MIN_VAL, welches der kleinste mit voller Genauigkeit darstellbare Wert ist.

• DOMAIN-Fehler (Argument außerhalb des Bereiches, für den eine Funktion definiert ist, also z.B. Logarithmen von negativen Zahlen) führen meist zum Resultat NAN ("not-a-number", die IEEE-Nicht-Zahl). Das Auftreten von DOMAIN-Fehlern resultiert meist aus Programmier-Fehlern. Für den Notfall besteht allerdings eine Möglichkeit, NAN durch eine beliebige Zahl zu ersetzen: VF_replaceNAN. Hierdurch kann verhindert werden, dass eine nachfolgende Operation mit dem gerade zu einer NAN gemachten Vektorelement zu einer Hardware-Exception, also einem Absturz führt.
  N.B.: Die Pseudo-Zahlen INF und NAN sind nicht als Argumente für OptiVec-Funktionen zugelassen. Ihre Anwesenheit kann zu einem Programmabbruch durch einen Hardware-Interrupt führen.
• SING-Fehler (Singularitäten, also explizite oder implizite Divisionen durch 0) werden als Extremfall des Überlaufs betrachtet (OVERFLOW-Fehler, s. unten). Das Ergebnis wird in den meisten Fällen auf ±HUGE_VAL gesetzt.
• OVERFLOW (Überlauf) dürfte die am häufigsten vorkommende Sorte von Fließkomma-Fehlern sein. Das Resultat wird – je nach Vorzeichen – auf +HUGE_VAL oder −HUGE_VAL gesetzt. In vielen Fällen dürfte die Fortsetzung des Programmes noch zu brauchbaren Resultaten führen.
• TLOSS-Fehler (totaler Genauigkeitsverlust) sind meist weniger schwerwiegend; hinter ihnen könnten sich aber auch die schwereren oben genannten Fehler verbergen. Beispielsweise ist der Cosecans als Kehrwert des Sinus für ganzzahlige Vielfache von p nicht definiert, so dass der "vollständig ungenaue" Wert auch zu einem SING- oder OVERFLOW-Fehler gehören könnte.
  Andererseits nimmt die Sinus-Funktion nur Werte zwischen −1 und +1 an für alle Argumente. Daher ziehen wir es vor, das "vollständig ungenaue" Resultat einer Sinus-Berechnung "stillschweigend" als 0.0 anzusehen (manche Compiler wählen NAN, die "Nicht-Zahl", als Resultat, was sicherlich noch weniger korrekt ist als die willkürliche Wahl von 0.0, denn das Ergebnis der Sinus-Funktion ist eben immer eine Zahl und keine Nicht-Zahl).
  Generell wählt OptiVec als Resultat im Falle von TLOSS-Fehlern den Mittelwert der Funktionswerte für Argumente +0.0 und −0.0.
• UNDERFLOW-Fehler (Unterlauf) werden nicht detektiert. Die Fließkomma-Einheiten der gängigen Prozessoren setzen das Resultat im Falle von UNDERFLOW-Fehlern zunächst auf nicht-normalisierte Zahlen (s. Kap. 5.4) und schließlich auf 0.0. Man wird kaum eine andere Behandlung wünschen können.
• Wie alle (nicht-vektorisierten) mathematischen Funktionen von C/C++ und Pascal/Delphi detektieren auch OptiVec-Funktionen niemals PLOSS-Fehler (partieller Genauigkeitsverlust); Genauigkeitsprobleme werden schlicht ignoriert. Dies mag Mathematikern die Haare zu Berge stehen lassen, ist aber so üblich und ohne größeren Aufwand auch nicht zu ändern.

Zurück zum Inhaltsverzeichnis

5.4 Die Behandlung nicht-normalisierter Zahlen

Bei der Bildung des Kehrwertes allerdings folgt ein Überlauf, und hier wird die etwas akademische Unterscheidung zwischen SING- und OVERFLOW-Fehlern fallengelassen und ein SING-Fehler angezeigt, als ob es sich um eine Division um exakt 0 handelte.

Andererseits geben Denormals als Argumente von einigen Funktionen, beispielsweise log, völlig vernünftige Ergebnisse, während exakt 0 als Argument zu einem SING-Fehler führt. Leider behandeln die meisten Compiler auch für diese Funktionen Denormals als 0. Wir schließen uns dem nicht an und berechnen lieber das Ergebnis.

Zurück zum Inhaltsverzeichnis

5.5 Fortgeschrittene Fehlerbehandlung: Meldungen in eine Datei schreiben

Man mag dies umgehen wollen. Eine einfache Lösung dieses Problems besteht in der Funktion V_setErrorEventFile. Diese Funktion benötigt als Argumente den Namen der gewünschten Ereignis-Datei ("Log-File") und einen Schalter, ScreenAndFile, der darüber entscheidet, ob Fehlermeldungen ausschließlich in die Datei (ScreenAndFile = 0) oder außerdem noch in einer Meldungs-Box (ScreenAndFile = 1) bzw. bei Console-Programmen auch auf dem Bildschirm (ScreenAndFile = 2) auszugeben sind.

Beispiel:
V_setErrorEventFile( "MyLogFil.TXT", 0 );  /* C/C++ */
V_setErrorEventFile( 'MyLogFil.TXT', 0 );  (* Pascal/Delphi *)
Hier werden alle folgenden Fehlermeldungen nur in das Log-File MyLogFil.TXT geschrieben, aber keine auf dem Bildschirm angezeigt.
Durch Aufruf von V_setErrorEventFile( "NULL", 0 ) (C/C++) bzw. V_setErrorEventFile( 'nil', 0 ) (Pascal/Delphi) lassen sich sogar jegliche OptiVec-Meldungen vollständig unterdrücken (so sinnvoll dies auch immer sein mag).
Die Ausgabe in die Log-Datei wird beendet durch V_closeErrorEventFile. Diese letztere Funktion hat keine Argumente und gibt auch nichts zurück. Anschließend erfolgt die Ausgabe eventueller Meldungen entsprechend dem bei Erzeugung der Log-Datei angegebenen Wert von ScreenAndFile.

Man beachte, dass die beschriebene Umleitung von Fehlermeldungen nur für Fehler gilt, die innerhalb von OptiVec-Funktionen auftreten. Es steht dem Nutzer aber frei, eigene Fehlermeldungen mit der von OptiVec benutzten Funktion V_printErrorMsg auszugeben.

Einige Konfigurationen der von OptiVec unterstützten Compiler erlauben nicht den vollen Umfang der oben angegebenen Optionen. Bei manchen fehlt entweder die Ausgabe in eine Message-Box oder die Ausgabe auf den Konsolen-Bildschirm. In diesen Fällen wird ggf. eine Fehlermeldung ausgegeben und die Ausgabe auf die jeweils andere Option umgeleitet.

Zurück zum Inhaltsverzeichnis

5.6 OptiVec-Fehlermeldungen

(00) OptiVec/CMATH not installed correctly (must use INSTALL.EXE !)

Nur in der Shareware-Version: Anscheinend führen Sie ein Programm, das OptiVec-Funktionen enthält, auf einem anderen Rechner aus als dem, wo Sie OptiVec installiert haben; die Weitergabe von Anwendungen, die OptiVec-Funktionen enthalten, ist aber nur mit der registrierten Vollversion möglich.
Oder OptiVec wurde durch bloßes Kopieren von Dateien installiert. Dies ist nicht möglich, da INSTALL.EXE die Uhr für die Testzeit startet. Installieren Sie OptiVec daher immer durch INSTALL.EXE.

(0) Trial period for OptiVec/CMATH has expired!

Nur in der Shareware-Version: Die Testzeit ist abgelaufen. Wir hoffen, Sie haben sich von den Vorzügen der Programmierung mit OptiVec überzeugen können und würden uns sehr über Ihre Registrierung freuen!

(1) Not enough memory.

("Nicht genug Speicherplatz")
Sie versuchen, Speicher zuzuweisen, aber es ist nicht mehr genügend vorhanden. Dieser Fehler könnte aus einem falschen Parameter size beim Aufruf von VF_vector resultieren. Ist dieser korrekt, so kämen als Grund insbesondere "vergessene Vektoren" in Schleifen in Frage, die alloziert, aber niemals freigegeben werden. Man versuche die folgenden Lösungen:
* Schnellstmögliche Freigabe aller nicht mehr gebrauchten Vektoren. Gehen Sie sicher, dass alle innerhalb eines Unterprogrammes erzeugten Vektoren wieder freigegeben werden, bevor das Unterprogramm verlassen wird.
* Lagern Sie Daten zwischendurch mittels VF_store auf Festplatte aus und lesen sie mit VF_recall wieder ein, wenn sie gebraucht werden. Diese Methode ist langsam und sollte nur im Notfall angewandt werden.

(2) Vector > 4 GB not possible (32-bit).

("Vektor > 4 GB nicht möglich"; nur 32-bit)
* Offenbar versuchen Sie einen Vektor zu erzeugen, dessen Größe das Maximum von 4 GB übersteigt. Wechseln Sie zu 64-bit!

(3) Vectors/matrices must not be identical.

("Vektoren/Matrizen dürfen nicht identisch sein")
Bei einigen Funktionen, wo mehr als ein Eingangs-Vektor (bzw. -Matrix) verwandt wird, um mehr als einen Ergebnis-Vektor zu berechnen, muss darauf geachtet werden, welcher Ergebnis-Vektor welchen Eingangs-Vektor überschreiben darf oder eben nicht. Vergleiche die Beschreibung der jeweiligen Funktion.

(4) Cannot use requested format (too many entries per line).

("Kann verlangtes Format nicht verwenden – zu viele Einträge pro Zeile.")
Dieser Fehler taucht bei den Ausgabe-Funktionen (VF_print usw.) auf. Der Parameter nperline wurde zu groß für den jeweiligen Datentyp und die zur Verfügung stehende Zeilenlänge angegeben. Die Funktion wählt automatisch die maximal mögliche Zahl der Einträge pro Zeile und setzt hiermit die Ausführung des Programmes fort.

(5) X-values of table must be distinct.

("X-Werte der Tabelle müssen unterschiedlich sein")
Die Interpolations-Routinen benötigen Tabellen, die gemäß ihren X-Werten geordnet sind. Jeder X-Wert darf nur einmal vorkommen, da unmöglich zu ein- und demselben X-Wert verschiedene Y-Werte gehören können.

(6) Not possible with fewer than n elements.

("Nicht möglich mit weniger als n Elementen")
Einige Funktionen verlangen das Vorhandensein einer minimalen Anzahl von n Vektor-Elementen.

(7) Not possible with more than n elements.

("Nicht möglich mit mehr als n Elementen")
Einige Funktionen begrenzen die Verarbeitung auf eine bestimmte Anzahl von n Vektor-Elementen (z.B. VF_polyinterpol, wo bis zu 10 Tabellen-Elemente für die Interpolation herangezogen werden können).

(8) Size must be an integer power of 2.

("Größe muss eine ganzzahlige Potenz von 2 sein")
Für alle Funktionen, die – explizit oder implizit – Fast-Fourier-Transform-Methoden anwenden, muss die Vektorgröße eine ganzzahlige Potenz von 2 sein. Man vergrößere oder verkleinere den/die Vektoren, um diese Bedingung zu erfüllen.

(9) Invalid parameter(s).

("Ungültige(r) Parameter")
In einigen Funktionen ist der zulässige Bereich eines oder mehrerer Eingabe-Parameter beschränkt. In anderen wiederum sind bestimmte Kombinationen von Eingabe-Parametern nicht erlaubt. So können Sie beispielsweise keine 9-Punkt-Interpolation mit nur 5 Datenpunkten durchführen.

(10) Cannot scale symbols by more than a factor of 50.

("Kann Symbole nicht mehr als fünfzigfach vergrößern." Nur Windows)
Die in den Plot-Funktionen von VectorLib verwendeten Symbole können nicht um mehr als einen Faktor 50 vergrößert werden (was allerdings bereits bedeutet, den ganzen Bildschirm mit einem einzigen Symbol zu füllen). Die Ausführung des Programmes wird nach dieser Meldung mit dem – immer noch ziemlich unsinnigen – Wert von 30 fortgesetzt.

(11) Cannot use line thicker than 500 pixels.

("Kann keine Linienstärke von mehr als 500 Pixels verwenden.")
Die Linienstärke in den Plot-Funktionen von VectorLib kann nicht dicker als 500 Pixels sein (was ohnehin ein ziemlich unsinniger Wert ist). Die Ausführung des Programmes wird nach dieser Meldung mit dem Wert von 500 fortgesetzt.

(12) Cannot free non-existent vector.

("Kann nicht-existierenden Vektor nicht freigeben.")
Sie haben V_free oder V_nfree für einen Vektor aufgerufen, dem gar kein Speicher zugeordnet ist. Die Ausführung des Programmes wird nach dieser Meldung fortgesetzt, ohne dass irgendetwas freigegeben wird. Dieser Fehler kann zwar harmlos sein (z.B., wenn Sie einen Vektor schon freigegeben haben, dies aber noch einmal versuchen). Hinter ihm könnten sich aber auch ernsthaftere Probleme verbergen, insbesondere das versehentliche Überschreiben der Vektor-Variable durch ein Speicher-Leck, z.B. beim Aufruf von Vektor- oder Matrix-Funktionen mit falschen Größen. Letzteres Problem lässt sich durch Verwendung der OptiVec-Debug-Bibliotheken detektieren und lokalisieren.

(21) Invalid dimension(s).

("Ungültige Dimension(en).")
Auf die eine oder andere Weise erfüllen die Dimensionen von Ein- und Ausgabematrizen nicht die in der jeweiligen Funktionsbeschreibung genannten Bedingungen.

(22) Matrix is singular.

("Matrix ist singulär.")
In einer Funktion, die reguläre Eingabematrizen verlangt, wurde eine singuläre Matrix angetroffen. Sie sollten eine alternative Funktion verwenden, die für die Behandlung auch (nahezu) singulärer Matrizen ausgelegt ist.

(23) No convergence achieved.

("Keine Konvergenz erzielt.")
Einige iterative Matrix-Methoden können in sehr seltenen Fällen scheitern, indem auch nach zahlreichen Iterations-Durchläufen keine Konvergenz erreicht wurde.

(24) Only the first n elements of each row can be printed.

("Kann nur die ersten n Elemente jeder Zeile ausgeben.")
Dieser Fehler taucht bei den Matrix-Ausgabefunktionen (MF_print usw.) auf, wenn die Zahl der Spalten größer ist als auf den Bildschirm paßt. Die Funktion wählt automatisch die maximal mögliche Spaltenzahl und schneidet die Zeilen am Bildschirmrand ab.

Zurück zum Inhaltsverzeichnis

6. Wenn etwas schiefgeht

• Sie müssen die Wahl von Prozessor, Umgebung und OptiVec-Bibliothek in Übereinstimmung bringen. Mit der Bibliothek VCF4W.LIB (32-bit-Bibliothek für C++ Builder) beispielsweise werden Sie in 64-bit nicht viel Freude haben. Auch mit dem "falschen" Compiler können OptiVec-Bibliotheken nicht laufen.
• Vektoren der Größe 0 sind verboten. Alle Funktionen gehen stillschweigend davon aus, dass mindestens ein Element vorhanden ist und verschwenden Ihre Computer-Zeit nicht damit, dies zu testen.
• Es reicht nicht aus, Vektoren nur zu deklarieren; ihnen muss auch Speicher zugewiesen werden. (siehe VF_vector). Wenn Sie die entsprechende Warnung nicht gerade ausgeschaltet haben, wird auch der Compiler Sie darauf hinweisen ("possible use of xxx before definition").
• Konstante Parameter sollten eine Größe von 1.E32 für float / Single, 1.E150 für double und von 1.E2000 für extended nicht überschreiten. (Das müßte eigentlich reichen!)

Obwohl OptiVec gründlich getestet worden ist, besteht natürlich immer die Möglichkeit, dass ein Problem unserer Aufmerksamkeit entgangen ist. Sollten Sie das Gefühl haben, auf ein solches Problem zu stoßen, so versuchen Sie doch bitte, die zu seinem Auftauchen führenden Bedingungen so genau wie möglich zu spezifizieren, und lassen Sie es uns unter support@optivec.com wissen!

Zurück zum Inhaltsverzeichnis

7. Die Include-Dateien und Units von OptiVec

Nur C/C++: Man deklariere den Gebrauch von OptiVec-Funktionen mit #include-Anweisungen. Falls Sie MFC (Microsoft Foundation Classes) oder Borlands uralte OWL (ObjectWindows Library) verwenden, müssen die MFC- oder OWL-Include-Dateien vor(!) denen von OptiVec eingeschlossen werden.

Nur Pascal/Delphi: Man deklariere den Gebrauch von OptiVec-Funktionen mit der uses-Anweisung.
 

Include-Datei (Suffix .H) oder Unit	Inhalt
VecLib	grundlegenden Definitionen der Datentypen und die Prototypen der allen Datentypen gemeinsamen Funktionen (das sind diejenigen mit dem Präfix V_) mit Ausnahme der Graphik-Routinen
VFstd, VDstd, VEstd	"Standard-Operationen" für Fließkomma-Zahlen: Erzeugung und Initialisierung von Vektoren, Index-orientierte Manipulationen, Datentyp-Umwandlungen, I/O-Operationen, Statistik, Analysis, geometrische Vektor-Arithmetik und alle auf der Fourier-Transformation basierenden Funktionen.
VCFstd, VCDstd, VCEstd, VPFstd, VPDstd, VPEstd	Standard-Operationen für cartesisch- und polar-komplexe Vektoren
VIstd, VBIstd, VSIstd, VLIstd, VQIstd	Standard-Operationen für Ganzzahl-Vektoren mit Vorzeichen
VUstd, VUBstd, VUSstd, VULstd, VUQstd, VUIstd	Standard-Operationen für vorzeichenlose Ganzzahl-Vektoren
VFmath, VDmath, VEmath	Algebraische, arithmetische und mathematische Funktionen für Fließkomma-Vektoren
VCFmath, VCDmath, VCEmath, VPFmath, VPDmath, VPEmath	Arithmetische und mathematische Funktionen für komplexe Vektoren
VImath, VBImath, VSImath, VLImath, VQImath	Arithmetische und mathematische Funktionen für vorzeichenbehaftete Ganzzahl-Vektoren
VUmath, VUBmath, VUSmath, VULmath, VUQmath, VUImath	Arithmetische und mathematische Funktionen für vorzeichenlose Ganzzahl-Vektoren
Vgraph	Graphik-Funktionen für alle Datentypen
VFNLFIT, VDNLFIT, VENLFIT	Nicht-lineare Datenanpassungs-Funktionen (nur Pascal/Delphi; in C/C++ befinden sie sich in M?std)
VFMNLFIT, VDMNLFIT, VEMNLFIT	Nicht-lineare Datenanpassungs-Funktionen für Mehrfach-Datensätze (nur Pascal/Delphi; in C/C++ befinden sie sich in M?std)
MFstd, MDstd, MEstd	Matrix-Operationen für reelle Matrizen
MCFstd, MCDstd, MCEstd	Matrix-Operationen für cartesisch-komplexe Matrizen
Mgraph	graphische Darstellung von Matrizen aller Datentypen
MFNLFIT, MDNLFIT, MENLFIT	Nicht-lineare Datenanpassungs-Funktionen für Datensätze Z = f(X, Y)  (nur Pascal/Delphi; in C/C++ befinden sie sich in M?std)
MFMNLFIT, MDMNLFIT, MEMNLFIT	Nicht-lineare Datenanpassungs-Funktionen für Mehrfach-Datensätze Z = f(X, Y)  (nur Pascal/Delphi; in C/C++ befinden sie sich in M?std)
NEWCPLX	komplexe Klassenbibliothek CMATH; nur C++
CMATH	komplexe Bibliothek CMATH für Pascal/Delphi und C
CFMATH, CDMATH, CEMATH	nur C/C++: typenspezifische Teile von CMATH
OVXMATH	Einige skalare mathematische Funktionen, die intern von anderen OptiVec-Funktionen benötigt werden; sie stehen allgemein für Anwendungen zur Verfügung (siehe Kap. 9). C/C++: die Sinus-, Cosecans- und Tangens-Tabellen für VF_sinrpi2 etc. befinden sich ebenfalls hier.
FSINTAB2, DSINTAB2, ESINTAB3, FSINTAB3, DSINTAB3, ESINTAB3	Sinus-Tabellen (nur Pascal/Delphi; für C/C++ befinden sie sich in OVXMATH)
FCSCTAB2, DCSCTAB2, ECSCTAB3, FCSCTAB3, DCSCTAB3, ECSCTAB3	Cosecans-Tabellen (nur Pascal/Delphi; für C/C++ befinden sie sich in OVXMATH)
FTANTAB2, DTANTAB2, ETANTAB3, FTANTAB3, DTANTAB3, ETANTAB3	Tangens-Tabellen (nur Pascal/Delphi; für C/C++ befinden sie sich in OVXMATH)
VecObj	grundlegende Definitionen für VecObj, das Objekt-orientierte Interface für C++
fVecObj, dVecObj, eVecObj	Member-Funktionen von VecObj für reelle Vektor-Objekte (nur C++)
cfVecObj, cdVecObj, ceVecObj pfVecObj, pdVecObj, peVecObj	Member-Funktionen von VecObj für komplexe Vektor-Objekte (nur C++)
iVecObj, biVecObj, siVecObj, liVecObj, qiVecObj	Member-Funktionen von VecObj für vorzeichenbehaftete Ganzzahl-Vektor-Objekte (nur C++)
uVecObj, ubVecObj, usVecObj, ulVecObj, uiVecObj	Member-Funktionen von VecObj für vorzeichenlose Ganzzahl-Vektor-Objekte (nur C++)
OptiVec	schließt das gesamte OptiVec-Paket ein (nur C++)
VecAll	schließt alle VectorLib- und CMATH-Funktionen ein (nur C oder C++)
MatAll	schließt alle MatrixLib-Funktionen ein (nur C oder C++)

 

Zurück zum Inhaltsverzeichnis

E N D E