mathematische Matrix

Ja, ich bin mir zu etwa 98% sicher. -- ich fand es bei einer "Einzelallokation" immer verwunderlich. So unterschiedlich sind die Geschmäcker.

BTW: Eine statische Allokation macht auch nichts anderes, als einen Block allozieren.

Wichtig aber: Die Größe muss entsprechend teilweise bekannt gemacht werden, also nicht mit int** definieren, sondern mit int[][3]. Hintergrund: Er kann sonst nicht ausrechnen, wie die Größe im speicher liegt. Aber soweit ich das sehe, hat erja eine konstante Größe (3).

Wieso geht das?

int a[17];
a[n] -> a + sizeof(int) * n

Richtig?

Klappt offensichtlich auch bei dynamischer Allozierung.

1.
int a[17][3];
int a[n] -> a + sizeof( int[3] ) * n;

Klar doch?

2.
int* p=a[n] -> p = a + sizeof( int[3] ) * n;
p[m] -> p+ sizeof(int) * m;

klar doch?

3. Einsetzung a[n] = p:
int a[n][m] -> (a+sizeof( int[3] ) * n) + sizeof(int) * m;

Richtig?

Klappt offensichtlich auch bei dynamischer Allozierung.

Ich weiß nicht mehr sytaktisch, welches Array (äußeres oder inneres) man offen lassen darf. Aber so lange nur eines offen ist, was hier der Fall ist, geht das. Hmm, ich schaue es heute abend noch einmal genauer nach. Das Problem ist halt, dass der Compiler den sizeof kennen muss. Bei halboffenen Arrays kennt er den aber.

Ich bin mir wirklich ziemlich sicher.

Ah, habe eine Erläuterung gefunden, die sich mit meiner deckt, jedoch etwas kürzer ist:
pweb.netcom.com/~tjensen/ptr/ch7x.htm

Es ist also so, wie ich es oben gemacht habe: Der linkeste Index kann offen bleiben.

Es ist übrigens ein weiterer Grund, warum Arrays keine Pointer sind, auch wenn das immer wieder falsch behauptet wird.

Original von Tom9811
Ah, habe eine Erläuterung gefunden, die sich mit meiner deckt, jedoch etwas kürzer ist:
pweb.netcom.com/~tjensen/ptr/ch7x.htm

Die Erläuterung bezieht sich aber auf statische Arrays. Für dynamische Arrays musst Du da schon in Kapitel 9 schauen. Da sind noch weitere Methoden für das Anlegen von dynamischen Arrays beschrieben. Sowohl für den Fall, dass die Spaltenzahl zur Compilierzeit bekannt (quasi "halbdynamisch" :]) ist, als auch für den Fall das nicht.
Also Vorsicht beim "über C-Experten herziehen".

Michael

Die Erläuterung bezieht sich aber auf statische Arrays.

Nein, es ging mir um den Zugriff. Danach hattest du gefragt, nicht nach der Erzeugung. Soll ich dir den Wortlaut deines Beitrages noch einmal hierhin kopieren, mit Hervorhebung für dich:

Und bei der Variante kann man dann per
[Codebeispiel]
zugreifen?

Oder habe ich dich jetzt irgendwie falsch zitiert?

Ich kann da nur etwas von Zugriff lesen, nicht von Erzeugung. Du? Umd zum Zugreifen findet sich an meinem Link:


Ich finde das ziemlich eindeutig: Man kann auf halboffene Arrays mittel []-Operator zugreifen.

Über die Erzeugung habe ich aber extra für dich an anderer Stelle geschrieben.

Ich finde es schon erstaunlich, dass du etwas in bezweifest (Oder war die Frage gar rhethorisch und du bist davon ausgegangen, dass es nicht geht?), ich es dir erkläre, und du -anstatt dich zu bedanken- auch noch sagst, meine Erläuterung sei falsch, was sie nicht ist. Welches Problem hast du genau? Wieso kannst du es nicht einfach akzeptieren, dass ich es besser wusste als du?

Sowohl für den Fall, dass die Spaltenzahl zur Compilierzeit bekannt (quasi "halbdynamisch"

Falsch. Es gibt keine "halbdynamischen" Arrays, sondern halboffene. Halboffene Arrays werden als Pointer angelegt, also das Array selbst schlicht und ergreifend _gar nicht_. Das ist nicht halbdynamisch, sondern ganz und gar dynamisch.

Du musst unterscheiden zwischen der Allozierung und dem Zugriff. Bei einem offenem oder halboffenem Array wird dieses als Pointer angelegt und als Array zugegriffen. Bei einem statischen wird es komplett angelegt und als Array benutzt. Bei einem Pointer bist du wiederum für die Anlage (oder Zuweisung) zuständig und der Zugirff erfolgt als Pointer. Ich hatte doch schon einmal erwähnt, dass Arrays nicht Zeiger sind, oder?

Also Vorsicht beim "über C-Experten herziehen".

Du hast die Frage gestellt, nicht wahr?

Und bei der Variante kann man dann per
[Codebeispiel]
zugreifen?

Entweder du wusstest da nicht.
Oder die Frage war rhethorisch, dann wusstest du es falsch.
Such es dir aus. Einen Experten kann ich nicht sehen. Und deine jetzigen "Erläuterungen" machen ganz bestimmt keinen aus dir.

Aber wir wollen doch nicht vom Thema ablenken, nicht wahr? Der Code, der hier publiziert ist, ist genau genommen kein 2D-Array, sondern ein Array von Pointern. Es ist für den OP mutmaßlich sogar so günstig, da er einzelne Elemente austauschen will, was so schneller geht. Aber: Es wird auch noch frank und frei behauptet, das Gegenteil sei der Fall. Offenbar haben hier einige C-Experten ein Array von Pointern mit einem mehrdimensionalen Array verwechselt. Das kommt vor, auch bei Experten. Wer es allerdings nicht erkennt, obwohl er darauf hingewiesen wird, der ist definitiv kein Experte.

Aber gut, den Fehler sieht man allerorten. Wie man allerdings auf den Gedanken kommen kann, ein mehrfaches malloc führe zu _einem_ Speicherblock, bleibt mir ein Rätsel. Und dann auch noch von der Ressourcenschonung zu sprechen, wenn man für 3 Ints einen Speicherblock vom System anfordert ... Sorry, wenn ich da das Expertentum bezweifele, dessen Ermangelung mir vorgeworfen wird. Ist aber doch schon lustig, wenn die Leute auf der Wichtigkeit des Grundlagenwissens beharren, dieses aber bei Ihnen schlicht falsch ist. Meinst du nicht auch?

Noch lustiger am Code ist, dass er offenbar das innere Array gar nicht als Feld meint. Es handelt sich nämlich um eine konstante Größe 3, was den Verdacht nahelegt, dass es sich um die Koordinaten x, y, z. handelt. Zu denken wäre also an ein Array von Pointern auf structs, zumal er die Elemente des inneren Arrays nicht indiziert.

Aber ich nehme es als positiven Effekt mit, dass du dir das nochmal angeschaut hast.

Original von Tom9811

Die Erläuterung bezieht sich aber auf statische Arrays.

Nein, es ging mir um den Zugriff. Danach hattest du gefragt, nicht nach der Erzeugung.

Ja, ich hatte nach dem Zugriff gefragt und zwar bezogen auf Deinen Beitrag:

Original von Tom9811
Nur noch ein Hinweis an die wirklichen und selbsternannten C-Experten hier:

Was der OP macht ist nicht die Allozierung eines einhheitlichen Blockes. Im Speicher sieht die Belegung von

Quellcode

1. int **feld = (int**)malloc( sizeof(int) * rows * 3);

und

Quellcode

1. int **feld = (int**)malloc( sizeof(int*) * rows;
2. for( ...
3. feld[i] = (int*)malloc( sizeof(int) * 3);

NICHT gleich aus. Das führt zu einer völlig anderen Speicherbelegung. Zudem führt 2) mutmaßlich zu einem Speicherverschwendung, welche die eines NSArrays deutlich übersteigen dürfte. Wenn schon, dann bitte 1) nehmen.

Ich finde es schon erstaunlich, dass die C-Experten hier zu einem "C-Array" raten, weil es vorteilhaft sei, es gleichzeitig ber gänzlich unvorteilhaft allozieren.

Hier sagst Du ja wohl, wenn man schon kein NSArray benutzt, soll man den Speicher so allozieren:
Das habe ich doch wohl richtig so verstanden, oder? Daraufhin fragte ich, ob ich auf einen so allozierten Speicherbereich eben wie auf ein zweidimensionales C-Array zugreifen kann. Meine Frage hat also eindeutig einen Bezug zur Erzeugung gehabt.

Original von Tom9811
Soll ich dir den Wortlaut deines Beitrages noch einmal hierhin kopieren, mit Hervorhebung für dich:

Und bei der Variante kann man dann per
[Codebeispiel]
zugreifen?

Oder habe ich dich jetzt irgendwie falsch zitiert?

Ich kann da nur etwas von Zugriff lesen, nicht von Erzeugung.

Tja, den Bezug zur Erzeugung hast Du geschickterweise nicht mit kopiert. Interessant.

Original von Tom9811
Umd zum Zugreifen findet sich an meinem Link:

Quellcode

1. void set_value(int >>>>m_array[][COLS]<<<<)
2. {
3. int row, col;
4. for (row = 0; row < ROWS; row++)
5. {
6. for (col = 0; col < COLS; col++)
7. {
8. >>>>m_array[row][col] = 1;<<<<
9. }
10. }
11. }

Alles anzeigen

Ich finde das ziemlich eindeutig: Man kann auf halboffene Arrays mittel []-Operator zugreifen.

Was hat jetzt die Übergabe von mehrdimensionalen Arrays an Funktionen mit meiner Frage zu tun?

Original von Tom9811
Ich finde es schon erstaunlich, dass du etwas in bezweifest (Oder war die Frage gar rhethorisch und du bist davon ausgegangen, dass es nicht geht?)

Oder habe ich es vielleicht sogar praktisch ausprobiert? Wer weiß?

Original von Tom9811
ich es dir erkläre, und du -anstatt dich zu bedanken- auch noch sagst, meine Erläuterung sei falsch, was sie nicht ist.

Wieso soll ich mich für eine theoretische Erklärung bedanken, die meine Frage nicht beantwortet?

Original von Tom9811
Welches Problem hast du genau?

Du hast meine Frage eben nicht beantwortet. Wie wäre es mal mit einem praktischen Beispiel, wie Du Speicher allozierst und dann darauf wie auf ein zweidimensionales Array zugreifst?

Original von Tom9811
Falsch. Es gibt keine "halbdynamischen" Arrays, sondern halboffene.

Mein Gott. Was glaubst Du, warum ich meine Wortschöpfung in "" geschrieben habe?

Original von Tom9811

Also Vorsicht beim "über C-Experten herziehen".

Du hast die Frage gestellt, nicht wahr?

Deine Aussage:

Original von Tom9811
Ich finde es schon erstaunlich, dass die C-Experten hier zu einem "C-Array" raten, weil es vorteilhaft sei, es gleichzeitig ber gänzlich unvorteilhaft allozieren.

Und jetzt kommts:

Original von Tom9811
Es ist für den OP mutmaßlich sogar so günstig, da er einzelne Elemente austauschen will, was so schneller geht

Zwei Aussagen, die sich eindeutig widersprechen, oder?

Original von Tom9811
Aber wir wollen doch nicht vom Thema ablenken, nicht wahr?

Ähm, ja. Thema war ein Array der Form "feld[H][W]" in der Größe veränderbar zu realisieren.

Original von Tom9811
Der Code, der hier publiziert ist, ist genau genommen kein 2D-Array, sondern ein Array von Pointern.

Der Code stammt übrigens vom OP und tut was er tun soll (nach dem er entwanzt wurde).

Original von Tom9811
Aber: Es wird auch noch frank und frei behauptet, das Gegenteil sei der Fall. Offenbar haben hier einige C-Experten ein Array von Pointern mit einem mehrdimensionalen Array verwechselt.

Ich weiß nicht, wen Du meinst. Mir ist der Unterschied jedenfalls klar.

Original von Tom9811
Aber gut, den Fehler sieht man allerorten. Wie man allerdings auf den Gedanken kommen kann, ein mehrfaches malloc führe zu _einem_ Speicherblock, bleibt mir ein Rätsel.

Mir bleibt ein Rätsel, wer das behauptet haben soll.

Original von Tom9811
Und dann auch noch von der Ressourcenschonung zu sprechen, wenn man für 3 Ints einen Speicherblock vom System anfordert ... Sorry, wenn ich da das Expertentum bezweifele, dessen Ermangelung mir vorgeworfen wird. Ist aber doch schon lustig, wenn die Leute auf der Wichtigkeit des Grundlagenwissens beharren, dieses aber bei Ihnen schlicht falsch ist. Meinst du nicht auch?

Über Resourcen habe ich mich nicht ausgelassen.

Original von Tom9811
Noch lustiger am Code ist, dass er offenbar das innere Array gar nicht als Feld meint. Es handelt sich nämlich um eine konstante Größe 3, was den Verdacht nahelegt, dass es sich um die Koordinaten x, y, z. handelt. Zu denken wäre also an ein Array von Pointern auf structs, zumal er die Elemente des inneren Arrays nicht indiziert.

Ob der Code aber letztendlich der ist, der im Programm angewendet wird? Mir sieht das erst mal nur nach Testcode aus.

Michael

[Allozierung und Zugriff]
Der Link bezog sich nicht auf die Allozierung, sondern auf die vorstehenden Erläuterungen, die deine Frage und den Zugriff betrafen.

Ichhatte erläutert, wie amn auf ein solch alloziertes Array zugreift, weil du das gefragt hattest. Ich hatte nicht erläutert, wie man es alloziert. Das geschah in einem anderen Beitrag.

Deine Frage hat auch einen Bezug zu floats, malloc, sizeof, C, Computern usw. gehabt. Die Frage war aber, wie man zugreift.

[Widersprchende Aussagen]
Nein.

Nochmal in Kurzform:
- Was dort alloziert wird, wird hier 2D-Array genannt. Es ist aber keines, sondern ein Array von Zeigern auf Arrays. Das ist etwas anderes.
- Dennoch ist es sogar günstig es so zu machen. Sozusagen Hans im Glück.
- Die Aussagen über die Allozierung werden hier für ein 2D-Array gemacht, nicht für ein Array von Zeigern auf Arrays. Sie sind daher schlicht falsch.
- Die Aussagen, ob man auf dem 2D-Array nicht ein 1D-Array machen soll, sind damit ebenfalls schlicht falsch.

Also noch einmal in ganzer Kürze:
Wenn man ein 2D-Array haben will, so muss man es anders allozieren.
Wenn man ein Array von Zeigern auf Arrays haben will, sollte man nicht über 2D-Arrays sprechen.

Was hat jetzt die Übergabe von mehrdimensionalen Arrays an Funktionen mit meiner Frage zu tun?

Du weißt nicht, was es mit deiner Frage zu tun hat, wenn man eine Variable mit [][n] definiierst und dann mit [n][m] darauf zugreift?
Du bist nicht zur Transferleistung in der Lage von einem Parameter zu einer lokalen Definition?
Sorry, das hatte ich dir als C-Experten unterstellt!

Also hier die Erläuterung:
Es ist gleichgültig, ob das Array in einer Parameterliste oder als lokale Variable deklariert wird. Es funktioniert immer gleich. Da kannst du mir vertrauen. Wenn du demnächst ähnliche Expertenfragen hast, etwa die Zuweisung von Integern, kannst du dich vertrauensvoll an mich wenden.

Ansonsten stellt sich die Frage, warum der Unterschied, der dir so klar war, von dir erfragt wurde.

Für einen C-Experten nicht schlecht. Er muss nachfragen, bekommt im ersten Wort der Antwort die Lösung und sagt dann, ihm sei der Unterschied klar. Das ganze mit ein paar "Erläuterungen", die bestenfalls einen laienhaften Zugang verdeutlichen.

Danke für die Diskussion. Wie gesagt, wenn es demnächst mal wieder an Kleinigkeiten hapert, kannst du dich melden.

Also man kann auch aus einer Fliege nen Elefanten machen.
Und hat eigentlich irgend jemand behauptet er sei ein C-Experte?
Wir versuchen hier nur zu helfen, nicht alles bis ins unendliche breitzutreten.


Manfred

Ich auch. Ich fange auch nicht von "Grundlagen in C sind doch ganz gut" an, sondern halte hier schon lange meine Schnauze. Wie auch beim Forumsformat. Aber antworten darf ich doch noch, wenn mal wieder jemand anfängt?

Richtig, es wurde lediglich behauptet, dass Grundlagenkenntnisse von C nützlich sind. Ich sehe das in diesem Forum in einem Kontext. Außerdem wurde mir abgesprochen, auf Performance jemals programmiert zu haben -- und eine Lösung vorgestellt, die Performance verbrät. Wundert dich, dass ich ärgerlich werde?

Zum Thema zurück:
Das ist nicht unwichtig. Du kannst das nämlich nicht so einfach in ein 1D-Array umbauen, wenn es ein Array von Pointern ist. Das geht nur bei "echten" 2D-Arrays, weil die auch physikalisch "an einem Stück" liegen. Es dürfte für den OP aber hinderlich sein, weil er ganze (Sub-)Arrays austauscht. Da sind Arrays von Pointern sind da etwas schneller. Also braucht er tunlichst einen Zwitter. Wie macht man den nun?

Also langer Rede kurzer Sinn: Wenn man das wirklich richtig auf Performance und Ressourcenschonung machen will, dann alloziert man einen Block für alle. Dann nimmt man sich ein Array von Pointern und setzt die Pointer von Hand in den Block. So hat man einen Monolithen im Speicher, den man auch mal mit memcpy oder einem 1D-Array ansprechen kann und dennoch die Vorteile des Pointer-Arrays. Das Problem mit dem free() erledigt sich von allein. Die Anzahl der Systemaufrufe verkleinert sich massiv.

_Das_ meinte ich damit, wenn ich sage, dass die Leute hier schreiben, dass C-Arrays besser peroformieren und sie es dann so implementieren, dass es schlecht performiert. Sie erzählen heir dem OP, dass er mit einem F1-Wagen durch die Stadt fahren soll, was gefährlich ist und als nächstes schweißen sie ihm den 2. Gang zu. Da würde ich doch lieber gleich die Luxuslimo nehmen.

Man kurz als Implementierungsidee, ungeprüft und schnell heruntergehackt


So in etwa müsste das funktionieren, sind aber sicher noch Fehler drin. Wenn der OP sich noch einmal maildet, probiere ich es aus und debugge es.

Der Trick dürfte aber klar geworden sein. Du sparst dir COLUMNS-1 Mal Aufrufe von malloc.Du zerbritzelst den Speicher nicht. Du hast trotzdem die Funktionalität.

++UPDATE++
Das "darübergelegte" Feld muss freilich zugewiesen werden.

Original von Tom9811
[Allozierung und Zugriff]
Der Link bezog sich nicht auf die Allozierung, sondern auf die vorstehenden Erläuterungen, die deine Frage und den Zugriff betrafen.

Ichhatte erläutert, wie amn auf ein solch alloziertes Array zugreift, weil du das gefragt hattest. Ich hatte nicht erläutert, wie man es alloziert.

Wenn ich meine Frage des Zugriffs auf eine konkrete Art der Allozierung beziehe, dann solltest Du die Frage auch so beantworten oder es sein lassen. Es hilft sonst nicht weiter.

Du hast dann unheimlich viel geschrieben, was ich nur als ein "ja" auf meine Frage deuten kann. Und nun lass das Programm mal laufen:

Testapp has exited due to signal 10 (SIGBUS).

Aber ich habe vermutlich hier einen Spezialcomputer, der anders tickt, als alle anderen.

Nö, ich habe das nicht ausgeteestet und bin schon froh, dass es überhaupt kompiliert. Übrigens ist bei mir ein halboffenes Array. Den Untersdchied habe ich glaube ich, schon einmal erläutert.

Original von asrael
Und hat eigentlich irgend jemand behauptet er sei ein C-Experte?

Das ist Toms Lieblingsdisziplin. Anderen Sachen unterstellen, die sie nicht behauptet haben.

Michael

Original von Tom9811
Übrigens ist bei mir ein halboffenes Array.

Ich darf noch mal aus dem Beitrag von Dir zitieren, worauf sich meine Frage bezogen hat:

Was der OP macht ist nicht die Allozierung eines einhheitlichen Blockes. Im Speicher sieht die Belegung von

Quellcode

1. int **feld = (int**)malloc( sizeof(int) * rows * 3);

und

Quellcode

1. int **feld = (int**)malloc( sizeof(int*) * rows;
2. for( ...
3. feld[i] = (int*)malloc( sizeof(int) * 3);

NICHT gleich aus. Das führt zu einer völlig anderen Speicherbelegung. Zudem führt 2) mutmaßlich zu einem Speicherverschwendung, welche die eines NSArrays deutlich übersteigen dürfte. Wenn schon, dann bitte 1) nehmen.

Kann da kein halboffenes Array entdecken.

"Was der OP macht ..."

Soll ich dir jetzt auch noch Deutsch beibringen? Das wird mir jetzt echt zu anstrengend.

Ich soll mir von jemanden deutsch beibringen lassen, der nicht einmal sein eigenes Geschreibsel richtig deuten kann? Guter Witz.

Original von Michael
Testapp has exited due to signal 10 (SIGBUS).

Du musst einen Zeiger auf das 2-D Array benutzen:


Gruss!

Original von ai-freak
Du musst einen Zeiger auf das 2-D Array benutzen:

Endlich mal ein Mann der Praxis. :]

Michael

Ich finde "Was der OP macht" eigentlich wenig Geschreibsel und ziemlich leicht zu verstehen.

Nein, man muss einen Array von Zeigern auf floats benutzen, siehe unten.

Du kannst natürlich auch das 2D Array dynamisch anlegen. Der Nachteil ist aber (siehe vorherigen Beitrag), dass er an späterer Stelle ganze Arrays vertauscht. Wenn du keinen Zeiger hast, läuft das auf händisches kopieren hinaus. Das sind dann 3 Zuweisung statt einer.

Aber eigentlich sollte man NSArray et al. benutzen. Es ist nämlich wenig sinnvoll, wegen nicht notwendiger, dafür aber angeblichen Performance-Vorteilen, C zu benutzen um dann gleich wieder die Performance wegzuschmeißen.

So, und jetzt ist gut. Ich gehe mir jetzt ein C-Programm schreiben, welches Objective-C-Programme interpretiert. Und weil ich es in C geschrieben habe, ist es viel schneller als ein Objective-C-Porigramm!!!!!!!!!!!

Original von Tom9811
Nein, maan muss einen Array von Zeigern auf floats benutzen, siehe unten.

Du kannst natürlich auch das 2D Array dynamisch anlegen. Der Nachteil ist aber (siehe vorherigen Beitrag), dass er an späterer Stelle ganze Arrays vertauscht. Wenn du keinen Zeiger hast, läuft das auf händisches kopieren hinaus. Das sind dann 3 Zuweisung statt einer.

Aber eigentlich sollte man NSArray et al. benutzen. Es ist nämlich wenig sinnvoll, wegen nicht notwendiger, dafür aber angeblichen Performance-Vorteilen, C zu benutzen um dann gleich wieder die Performance wegzuschmeißen.

Sehe ich auch so. Mein Beitrag sollte nur zeigen, wie man 2D Arrays dynamisch anglegt und dann per (*f)[y][x] darauf zugreift. Die beste Repräsentation für die Matrix ist halt anwendungsabhängig. Wie oft werden Spalten vertauscht, wie groß sind die Matrizen, usw.
Solange man nicht die wirklich Performance-kritischen Bereiche des Codes kennt sollte man halt die "sicherste" und "einfachste" Variante benutzen. "Einfach" kann aber auch heißen, dass man halt das nimmt, was man schon kennt. Am flexibelsten ist es wohl sich mit Macros eine Abstraktion zu bauen:
MATRX_TYPE
CREATE_MATRIX
SWAP_COLUMNS(a,b)
...
die man dann jeweils gemäß der sich im Weiteren ergebenden Anforderungen anpassen kann.
Andererseits sind C-Makros halt auch wieder eine beliebte Fehlerquelle.

Ja, Macros benutze ich außerhalb reiner Wertedefinitionen auch extrem ungerne, gerade parametrisierte.

Man denke nur an das wudnerbare Inkrementierungsproblem in Markos: Da kann man sich zuweilen übel wundern.

Wobei ich ständig missverstanden werde (absichtlich?): Ich habe nichts gegen "C-Arrays", wenn sie _notwendig_ sind. Aber sie sind grundsätzlich -gerade die dynamische Variante- gegenüber NSArray komplizierter zu handhaben und fehleranfälliger. Und wer sagt, dass er eben sorgfältig genug ist, dem vertraue ich nicht. ("Es ist noch ein Schritt bis zum Abgrund.") Daher nur verwenden, wenn sie notwendig sind. Knuth sagt ja auch, dass _premature_ Optimization schlecht ist, nicht, dass Optimierung schlecht ist. Das wird ganz gerne überlesen.

Noch was:

Soweit ich weiß läßt sich GNU-Octave auch als Bibliothek benutzen (C++), womit man Zugriff auf extrem mächtige und effiziente Matrix-Algorithmen hat. Muß aber einschränkend sagen, dass ich's selbst noch nicht auf diese Weise verwendet habe.