MatrixLib  

Site Index:

MatrixLib

Inhaltsverzeichnis

1. Einführung

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

1.1 Matrix-Datentypen

Wir empfehlen, in Ihren Programmen ausschließlich mit diesen dynamisch allozierten Matrizen zu arbeiten. Es ist aber möglich, statische Matrizen, die z.B. als
float MX[4][6]; (für C/C++), oder
MX: array[0..3][0..5] of Single; (für Pascal/Delphi)
definiert wurden, in allen MatrixLib-Funktionen zu verwenden. Die einzige Ausnahme stellen die multiLinfit-Funktionen und multiNonlinfit-Routionen dar.

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

1.2 Präfixe von MatrixLib-Funktionen

• MFdia_ bedeutet, daß die Funktion eine Diagonalmatrix erwartet, also eine quadratische Matrix mit Elementen ungleich 0 nur auf der Diagonalen. Da es für eine solche Matrix keinen Sinn macht, alle Nullen der Nicht-Diagonalelemente explizit zu speichern, wird eine Diagonalmatrix als Vektor gespeichert, der lediglich die Diagonalelemente enthält.
   
• MFsym_ zeigt eine Funktion an, die eine symmetrische Matrix als Argument erwartet. Zur Zeit machen nur MFsym_eigenvalues sowie MFsym_sqrt Gebrauch von dieser Annahme.
   
• MFtrd_ bedeutet eine Funktion einer Tridiagonalmatrix, also einer Quadratmatrix, die nicht-verschwindende Elemente nur auf der Diagonalen plus-minus einer Spalte besitzt. Eine tridiagonale Matrix wird als Matrix von drei Zeilen eingegeben. Diese drei Zeilen stellen die drei Vektoren dar, die tatsächlich Elemente ungleich Null besitzen. Die Original-Matrix
   

  d0	u0	0	···
  l1	d1	u1	0	···
  0	l2	d2	u2	0	···
  			···
  			lN-2	dN-2	uN-2
  			0	lN-1	dN-1

   
  wird also komprimiert in die Form
   

  u0	u1	u2	···	uN-2	*
  d0	d1	d2	···	dN-2	dN-1
  *	l1	l2	···	lN-2	lN-1

   
  Die mit einem Stern markierten Elemente l₀ und u_N-1, bleiben undefiniert und werden niemals benutzt.

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

1.3 C/C++ -spezifisch:

1.3.1 MatObj, das objekt-orientierte Interface für Matrix-Funktionen

Ähnlich den Alias-Namen der Vektor-Objekte erhalten die Matrix-Objekte die Alternativ-Namen fMatObj, dMatObj usw., wobei wie immer der Datentyp durch die ersten ein oder zwei Buchstaben des Klassen-Namens angegeben wird.

Die Matrix-Konstruktoren sind:
matrix(); // kein Speicher zugewiesen; Dimensionen auf 0 gesetzt
matrix( unsigned ht, unsigned len ); // [ht * len] Matrix erzeugt
matrix( unsigned ht, unsigned len, T fill ); // desgleichen, aber mit "fill" initialisiert
matrix( matrix <T> init ); // erzeugt eine Kopie der Matrix "init"

Für die Matrix-Klassen sind die arithmetischen Operatoren
+    -    *    +=    -=    *=
definiert.
Während der Vektor-Vektor-Operator * sich auf die Element-weise Multiplikation bezieht, bedeuten der Operator * für Matrix-Matrix, Matrix-Vektor und Vektor-Matrix die "echte" Matrizen-Multiplikation.

Sollten Sie einmal in die Lage kommen, ein MatObj-Matrixobjekt mit einer "klassischen" C-MatrixLib-Funktion verarbeiten zu wollen, benutzen Sie bitte die Member-Funktionen
getHt() und getLen(), um die Dimensionen auszulesen, getMatrix für den Matrix-Zeiger vom Datentyp fMatrix usw., oder getM0, um den Vektor M[0] vom Datentyp fVector usw. zu erhalten.

Die Syntax aller MatObj-Funktionen wird unten bei allen MatrixLib-Funktionen mit angegeben, so weit sie von tMatObj gekapselt werden.

Die strikte Kontrolle der Matrix-Dimensionen auf Konsistenz führt zu einigen Besonderheiten gegenüber den "normalen" MF_-Funktionen:

• Mit den MF_-Funktionen ist is möglich, eine große Matrix als Zwischenspeicher für kleinere Matrizen zu verwenden. Beispielsweise könnten eine [n * n]- und eine [m * n]-Matrix nacheinander denselben Speicherplatz nutzen, ohne daß eine Neu-Belegung von Speicher nötig wäre (m < n: eine oder mehrere Zeilen bleiben einfach ungenutzt). Dies ist nicht möglich mit MatObj, da hier die Matrix-Dimensionen gekapselt sind und daher keine Unterscheidung zwischen "tatsächlichen" und "genutzten" Dimensionen getroffen werden kann.
• Es ist nicht einmal möglich, beispielsweise eine nicht-quadratische Matrix mit ihrer Transponierten zu überschreiben (selbst wenn Sie bereit wären, auf die Integrität der Zeilenzeiger zu verzichten, und obwohl, die Größe der Matrix natürlich gleichbleibt).
• Alle MatObj-Funktionen mit dem Präfix Dia_... verlangen quadratische Matrizen (ht = len), während MF_Dia_...-Funktionen im Prinzip auch mit nicht-quadratischen Matrizen verwendet werden können, solange der Parameter "len" im Funktionsaufruf der jeweils kleineren Dimension entspricht.
• Die multifit-Funktionen sind nicht in den Klassen gekapselt, da die structs VF_EXPERIMENT und MF_EXPERIMENT ohnehin Zeiger anstatt Objekten enthalten müssen.

1.3.2 Alternative Aufruf-Form von Matrix-Funktionen mit direkten Zeigern

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

1.4 Pascal/Delphi- spezifisch:

Delphi 4 oder höher:
Ab Version 4 bietet Delphi dynamische Felder. Im eindimensionalen Fall werden diese als "array of Single", "array of Double", usw. deklariert. Die VecLib-unit enthält Kurzdefinizitionen für diese Felder als fArray, dArray, usw. Durch einfaches type-casting von fArray in fVector können diese mit allen VectorLib-Funktionen verwendet werden.

Im zweidimensionalen Fall ist die Situation leider etwas komplizierter. Dynamische 2-D-Felder werden in Delphi als "array of fArray", "array of dArray" usw. deklariert. Auch hierfür bietet die VecLib-unit Kurzdefinitionen: f2DArray, d2DArray, usw. Aus der beschriebenen Implementation zweidimensionaler Felder in Delphi ergibt sich, daß jede Zeile einer Matrix als separater Vektor gespeichert wird. Dies hat zur Folge, daß die Matrix-Elemente nicht mehr innerhalb eines zusammenhängenden Speicherbereiches abgelegt werden, was sich wiederum sehr ungünstig auf die Performance von Matrix-Funktionen auswirkt und verhindert, daß Delphi-2DArrays direkt in MatrixLib-Funktionen eingesetzt werden können. Stattdessen müssen sie in "echte" Matrizen kopiert werden mittels MF_2DArrayToMatrix usw., bevor sie an MatrixLib-Funktionen übergeben werden können. Die Rück-Umwandlung wird durch MF_MatrixTo2DArray bewerkstelligt.

Die folgenden Kapitel bieten eine kurze Übersicht aller MatrixLib-Funktionen, geordnet nach ihrer Funktionalität. Am Schluß dieser Datei enthält Kap. 16 eine detaillierte Beschreibung der einzelnen Funktionen in alphabetischer Ordnung.

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

2. Dynamische Allokation von Matrizen

Nur C/C++-Version:
Die dynamisch allozierten Matrizen von OptiVec können genau wie zweidimensionale statische Felder von C/C++ adressiert werden. Angenommen, Sie deklarieren z.B. eine fMatrix X; und eine Variable float a;, dann können Sie eine Zuweisung schreiben der Art:
a = MX[3][5];

Sowohl C/C++- als auch Pascal/Delphi-Version:
Es gibt zwei Funktionen zur Adressierung einzelner Elemente. Diese Funktionen bieten die einzige Möglichkeit der Adressierung in Pascal/Delphi und werden außerdem benötigt, um die in der Zeigerarithmetik älterer Borland C++-Versionen enthaltenen Fehler zu umgehen:

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

3. Initialisierung von Matrizen

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

4. Datatyp-Umwandlungen

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

5. Symmetrie-Operationen (Transposition, Rotation, , Spiegelung),
Interpolation, Erweiterung, Verkleinerung, Extraktion sowie Initialisierung von Teilen von Matrizen

nur C++ mit dynamisch allozierten Matrizen:
Fall MA durch Spalten-Einfügung oder -Löschung von MB überschrieben wird, geht die Möglichkeit verloren, einzelne Matrix-Elemente als MB[i][j] anzusprechen. Der Grund hierfür ist, daß die Zeilen-Zeiger der Ausgabe-Matrix immer noch dieselben wie in der Eingabe-Matrix bleiben. Dann bieten nur noch MF_element und MF_Pelement Zugang zu den einzelnen Elementen. Falls auf der anderen Seite ausschließlich Zeilen eingefügt oder gelöscht werden, bleiben die Zeilen-Zeiger gültig.

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

6. Arithmetische Operationen einer einzelnen Zeile, Spalte oder der Diagonalen

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

7. Operationen, die auf alle Zeilen oder alle Spalten gleichzeitig oder auf die Diagonale wirken
Berechnung des Schwerpunktes

Man beachte, daß die Multiplikation aller Zeilen oder aller Spalten mit ein- und demselben Vektor äquivalent zur Multiplikation mit einer Diagonal-Matrix ist. Diese Operation wird durch MF_mulMdia und MF_TmulMdia bewerkstelligt.
Zu allen oben aufgeführten Maximum-Funktionen (...max,  ...absmax) existieren die entsprechenden Minimum-Funktionen und sind als ...min bzw. ...absmin benannt.
Für komplexe Zahlen lassen sich verschiedene Kriterien zur Definition eines Maximums definieren. Die folgende Tabelle faßt die existierenden Maximum-Funktionen für komplexe Matrizen zusammen. Natürlich existieren auch hier die entsprechenden Minimum-Funktionen.
 

Zur Berechnung des Schwerpunktes einer Matrix stehen zwei Funktionen zur Verfügung:
 

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

8. Operationen von zwei Zeilen oder zwei Spalten

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

9. Arithmetik ganzer Matrizen: Addition und Multiplikation

b) Matrix-Multiplikation

c) Multiplikation von allgemeinen Matrizen mit Diagonalmatrizen und umgekehrt
Die Diagonalmatrix wird an die jeweilige Funktion als Vektor übergeben, der nur aus den Diagonalelementen besteht.

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

10. Lineare Algebra

Hier sind zunächst die einfachen Funktionen:

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

11. Eigenwerte und Eigenvektoren, Quadratwurzel

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

12. Zwei-dimensionale Fourier-Transform-Methoden

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

13. Datenanpassung (Fitting)

Im folgenden werden die verschiedenen Klassen von Modellfunktionen einzeln besprochen. Das einfachste Modell besteht aus einer Geraden:
Y_i = a * X_i + b;
Die Anpassung von Y = f(X)-Daten an eine Gerade heißt "lineare Regression" und wird durch VF_linregress durchgeführt.
Die nächst-höhere Stufe von Modellfunktionen stellen Polynome dar, die im folgenden Absatz besprochen werden:

13.1 Polynome

13.2 Allgemeine Lineare Modell-Funktionen

void LinModel( fVector BasFuncs, float x, unsigned nfuncs )
{
  BasFuncs[0] = sin(x);
  BasFuncs[1] = cos(x);
}

Man beachte, daß die Koeffizienten a_i in der Modellfunktion gar nicht auftauchen. Das Argument nfuncs (das im obigen Beispiel ignoriert wird) ermöglicht es, eine variable Anzahl von Basisfunktionen zu verwenden. Man kann außerdem Anpassungsparameter "an" und "aus" schalten, d.h. zwischen "freien" und "eingefrorenen" Parametern wechseln. Hierfür übernimmt die Routine VF_linfit einen "Status"-Vektor als Argument. Für alle Elemente des Parameter-Vektors, die als frei behandelt werden sollen, muß der entsprechende "Status"-Eintrag auf 1 gesetzt werden. Setzt man Status_i gleich 0, so wird der entsprechende Parameter a_i auf seinem Anfangswert eingefroren. Eingefrorene Werte müssen vor Aufruf von VF_linfit initialisiert werden.
Intern verwendet VF_linfit einen SVD-Algorithmus, um eine Lösung selbst für (nahezu) singuläre lineare Gleichungssysteme zu erhalten. Koeffizienten a_i, deren Signifikanz unter einer bestimmten Schwelle Thresh liegt, werden dabei gleich 0 anstatt Unendlich gesetzt. Die Schwelle kann durch Aufruf von VF_setLinfitNeglect modifiert werden. Um den aktuell eingestellten Schwellenwert zu lesen, rufe man VF_getLinfitNeglect.

Nachdem bereits oben bemerkt wurde, daß Funktionen wie
y = sin(a₀x)+ cos(a₁x)
ihre eigene Behandlung erfordern, erreichen wir die letzte und allgemeinste Klasse von Modellfunktionen:

13.3 Nicht-lineare Modelle

• Der Levenberg-Marquardt-Methode und der
• Downhill-Simplex-Methode nach Nelder und Mead.

void NonlinModel( fVector Y, fVector X, ui size, fVector A)
{
  for( ui i=0; i<size; i++ )
  Y[i] = sin( A[0]*X[i] ) + cos( A[1]*X[i] );
}

Aus der beschriebenen Arbeitsweise der Anpassungs-Routine wird klar, dass sie den größten Teil der Rechenzeit in Ihrer Modellfunktion (und deren Ableitungen, siehe unten) verbringen wird. Daher sollte diese weitestmöglich mit Hilfe der in OptiVec bereitgestellten Vektor-Funktionen optimiert werden. Hierzu könnten Sie vor dem Aufruf von VF_nonlinfit einen fVector YHelp bereitstellen (entweder global mittels VF_vector alloziert oder bei kleineren Vektoren auch lokal auf dem Stack). Dann können Sie schreiben:

void OptNonlinModel( fVector Y, fVector X, ui size, fVector A)
{
  VFx_sin( YHelp, X, size, A[0], 0.0, 1.0 );
  VFx_cos( Y,     X, size, A[1], 0.0, 1.0 );
  VF_addV( Y, Y, YHelp, size );
}

Der Parameter-Vektor "A", den Sie als Argument an VF_nonlinfit übergeben, wird im Verlauf des Anpassungs-Prozesses immer weiter verbessert. Beim Aufruf von VF_nonlinfit muss "A" mit bereits möglichst "guten" Werten der Parameter initialisiert sein. Je besser Sie diese "raten", umso schneller wird VF_nonlinfit konvergieren. Raten Sie gar zu schlecht, kann die Konvergenz wesentlich langsamer oder im schlimmsten Fall auch überhaupt nicht erreicht werden.

Alle nonlinfit-Funktionen geben den Anpassungstest-Wert (für Anpassung nach kleinsten Fehlerquadraten: c², chi-Quadrat; für Anpassung nach kleinstem Absolut-Fehler: |c|, chiabs) des besten Parameter-Satzes "A" zurück.
Um die Anpassung durchführen zu können, benötigen diese Funktionen nicht nur die Modellfunktion selbst, sondern auch noch deren partielle Ableitungen nach den einzelnen Koeffizienten. Hierfür dient das Argument "Derivatives", das an alle nonlinfit-Funktionen übergeben werden muss. Falls Sie die partiellen Ableitungen in analytischer Form kennen, sollte Derivatives auf eine Funktion zeigen, die diese berechnet. Kennen Sie sie nicht, setzen Sie beim Funktionsaufruf Derivatives = NULL (nil in Pascal/Delphi). Im letzteren Fall werden alle Ableitungen numerisch innerhalb der Routinen bestimmt. In Fällen, wo Sie zwar einige, aber nicht alle der partiellen Ableitungen von Y nach den Koeffizienten a_i kennen, können Sie dY / da_i selbst berechnen, wo immer Sie die analytische Formel kennen, und VF_nonlinfit_autoDeriv für die übrigen Koeffizienten aufrufen. Um diese Möglichkeiten zu demonstrieren, sei hier erneut unser nicht-lineares sinus- und cosinus-Beispiel bemüht:

void DerivModel( fVector dYdAi, fVector X, ui size, unsigned iPar, fVector A, VF_NONLINFITWORKSPACE *ws )
{
  switch( iPar )
  {
    case 0:
      for( ui i=0; i<size; i++ )
        dYdAi[i] = X[i] * cos( A[0]*X[i] );
      break;
    case 1: /* wir kennen diese Ableitung zwar; aber nehmen wir einmal an, dies wäre nicht der Fall: */
      VF_nonlinfit_autoDeriv( dYdAi, X, size:UIntSize; ipar, A, ws );
  }
}

Bevor Sie allerdings VF_nonlinfit_autoDeriv tatsächlich einsetzen, sollten Sie alle Anstrengungen unternehmen, eine eventuell existierende analytische Lösung herauszufinden: Die für die numerische Ableitung notwendige Zahl von Funktionsaufrufen kann Ihre Anpassung leicht um einen Faktor von 3 bis 10 verlangsamen! Ohnehin sollten, ähnlich wie oben die Modellfunktion, auch deren Ableitungen möglichst mit Hilfe von Vektorfunktionen programmiert werden. Die optimierte Version von DerivModel lautet dann wie folgt:

void OptDerivModel( fVector dYdAi, fVector X, ui size, unsigned iPar, fVector A, VF_NONLINFITWORKSPACE *ws )
{
  switch( iPar )
  {
    case 0:
      VFx_cos( dYdAi, X, size, A[0], 0.0, 1.0 );
      VF_mulV( dYdAi, dYdAi, X, size ); break;
    case 1:
      VFx_sin( dYdAi, X, size, A[1], 0.0, -1.0 );
      VF_mulV( dYdAi, dYdAi, X, size );
  }
}

Vollständige Beispiele für Anpassung an Polynome, allgemeine lineare und allgemeine nicht-lineare Modelle sind in den Dateien FITDEMO.CPP, FITDEMOW.CPP, FITDEMOB.BPR, FITDEMO.PAS und FITDEMO.DPR enthalten.

Die nichtlinearen Anpassungs-Routinen von OptiVecsind sehr vielseitig einstellbar mit Hilfe von Optionen, die durch Aufruf der Funktion V_setNonlinfitOptions gewählt werden können. Um die aktuell eingestellten Optionen zu lesen, rufe man V_getNonlinfitOptions.
Alle Optionen sind in eine Struktur (struct in C/C++, record in Pascal/Delphi) namens VF_NONLINFITOPTIONS zusammengefaßt. Diese besteht aus den folgenden Feldern:
 

VF_NONLINFITWORKSPACE

Wie oben beschrieben, benötigen alle nicht-linearen Anpassungsfunktionen einen Satz von internen Variablen, der zusammengefasst als struct (Delphi: record) VF_NONLINFITWORKSPACE über seine Adresse an die jeweilige Funktion übergeben und wiederum von dieser verwendet wird, um alle benötigten Daten an Unter- und Hilfsfunktionen zu übergeben. Dieser Variablen-Satz muss nicht initialisiert werden; er enthält keine nutzbaren Informationen für den Anwender. Bei den Funktionen der MF_nonlinfit-Familie wird analog ein (von VF_NONLINFITWORKSPACE leicht verschiedener) Variablen-Satz als MF_NONLINFITWORKSPACE benötigt.
Man schreibe also in C/C++:

VF_NONLINFITWORKSPACE ws;
VF_NONLINFITOPTIONS fopt;
V_getNonlinfitOptions( &fopt );
// an dieser Stelle "fopt" nach Bedarf modifizieren...
VF_nonlinfit( ParValues, AStatus, nParameters, X, Y, sz, ModelFunc, DerivativeFuncs, &ws, &fopt );

oder in Delphi:
ws: VF_NONLINFITWORKSPACE;
fopt: V_NONLINFITOPTIONS;
V_getNonlinfitOptions( @fopt );
// an dieser Stelle "fopt" nach Bedarf modifizieren...
VF_nonlinfit( ParValues, AStatus, nParameters, X, Y, sz, @ModelFunc, @DerivativeFuncs, @ws, @fopt );

Wird beim Aufruf von VF_nonlinfit der entsprechende Paremeter gleich NULL / nil gesetzt, so erzeugt und verwendet die aufgerufene Funktion ihren eigenen Workspace.

13.4 Anpassung von Mehrfach-Datensätzen

type VF_EXPERIMENT = record
  X, Y, InvVar: fVector;
  size: UInt;
  WeightOfExperiment: Single;
end;
type PVF_EXPERIMENT = ^VF_EXPERIMENT;
 
type MF_EXPERIMENT = record
  X, Y: fVector;
  MZ, MInvVar: fMatrix;
  htZ, lenZ: UInt;
  WeightOfExperiment: Single;
end;
type PMF_EXPERIMENT = ^MF_EXPERIMENT;

Sowohl in VF_EXPERIMENT als auch in MF_EXPERIMENT sollten InvVar und WeightOfExperiment nur für die gewichteten Varianten der multifit-Funktionen gesetzt werden.

13.5 Hilfs-Funktionen für nichtlineare Anpassungen

Es gibt zwei Möglichkeiten, diese Funktionen aufzurufen. Erstens können sie aus der ja vom Benutzer zu schreibenden Modellfunktion heraus angesprochen werden. Sie könnten hierfür beispielsweise einen Zähler in Ihrer Modellfunktion installieren, der alle hundert Aufrufe das erreichte c², den Parametersatz usw. ausliest. Der zweite Weg steht nur Multithread-Programmen offen: Ein Thread führt die Anpassung aus, und ein weiterer ist für den Aufruf der obigen Hilfs-Funktionen zuständig, um den Fortgang der Anpassung zu überprüfen.
Beide Wege verlangen, dass der verwendete VF_NONLINFITWORKSPACE global zugänglich ist. Wenn eine Nonlinfit-Funktion aus mehreren Threads gleichzeitig aufgerufen wird, gibt es natürlich ein Problem, vor allem, wenn der Aufruf der Hilfsfunktionen aus der Modellfunktion heraus erfolgen soll: Woher soll die Modellfunktion "wissen", von welchem Thread heraus sie aufgerufen wurde? Die Lösung: Man speichere einen Thread-Index in den einzelnen Parameter-Vektoren A. Dies könnte in Ihrem Hauptprogramm beispielsweise so ähnlich aussehen wie:

    float A1[11], A2[11], ...;
    int AStatus1[11], AStatus2[11], ...;
    VF_NONLINFITWORKSPACE ws1, ws2, ...;
    ....
    VF_random( A1, 10, 1, -1.0, +1.0 ); // Startwerte
    VI_equC( AStatus1, 10, 1 ); // die ersten 10 Parameter sollen angepasst werden
    A1[10] = 1; // Thread-Index = 1
    AStatus1[10] = 0; // der Thread-Index bleibt natürlich eingefroren
    ... Thread #1 erzeugen mit VF_nonlinfit und A1, AStatus1, ws1 als Argumenten
 
    VF_random( A2, 10, 1, -1.0, +1.0 ); // Startwerte des 2. Satzes
    VI_equC( AStatus2, 10, 1 ); // wieder die ersten 10 Parameter anpassen
    A2[10] = 2; // Thread-Index = 2
    AStatus2[10] = 0; // Thread-Index wieder eingefroren
    ... Thread #2 erzeugen mit VF_nonlinfit und A2, AStatus2, ws2 als Argumenten

In Ihrer Modellfunktion hätten Sie dann etwas in der Art von:

void ModelFunc( fVector Y, fVector X, ui size, fVector A )
{
    static unsigned counter1=0, counter2=0, ...;
    float CurrentFOM;
    ....
    switch( (unsigned)(A[10]) )
    {
        case 1: if( (++counter1 % 1024) == 0 )
                {   CurrentFOM = VF_nonlinfit_getFOM( ws1 );
                    printf( "\nCount 1: %u, FOM: %f", counter1, CurrentFOM );
                } break;
        case 1: if( (++counter2 % 1024) == 0 )
                {   CurrentFOM = VF_nonlinfit_getFOM( ws2 );
                    printf( "\nCount 2: %u, FOM: %f", counter2, CurrentFOM );
                } break;
                ....
    }
    ....
}

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

14. Matrix-Eingabe und -Ausgabe

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

15. Graphische Darstellung von Matrizen

Zurück zum MatrixLib-Inhaltsverzeichnis     OptiVec Home

Copyright © 1996-2020 OptiCode – Dr. Martin Sander Software Development