|
|
Verschachtelte Cell-Arrays auslesen + flexible Preallocation |
|
Tom_Gast |
Gast
|
 |
Beiträge: ---
|
 |
|
 |
Anmeldedatum: ---
|
 |
|
 |
Wohnort: ---
|
 |
|
 |
Version: ---
|
 |
|
|
 |
|
Verfasst am: 26.10.2016, 12:42
Titel: Verschachtelte Cell-Arrays auslesen + flexible Preallocation
|
 |
|
 |
|
Hallo,
ich habe zwei Fragen zu Cell-Arrays:
1. Ich habe beispielsweise den folgenden verschachtelten Cell-Array:
Der sieht dann also so aus:
(Die jeweiligen {1x2cells} bestehen also aus 2 Mal [1x3 double])
Jetzt möchte ich die innere Verschachtelung aufheben, d.h. es soll ein neuer Cell-Arrax entstehen, der so aussieht:
Zitat: |
B = {[0.1 0.2 0.9], [0.4 0.1 1.2], [4.1 2.5 1.8], [0.3 0.6 2.1]} |
Der sieht dann also so aus:
Dieser neue {1x4 cell} Cell-Array soll also die Daten der inneren Cell-Arrays von A untereinander stehen haben.
Gibt es eine Möglichkeit von Cell-Array A nach Cell-Array B zu kommen?
2. Wenn man einen Cell-Array oder aber auch einen normalen Vektor mit einer for-Schleife iterativ vergrößert, möchte Matlab, dass man den Cell-Array bzw. Vektor vorher mit der entsprechenden Größe anlegt. Das geht auch in den meisten Fällen.
Allerdings habe ich gerade einen Fall, bei dem ich einen zufälligen Vektor auf Bedinungen überprüfe und dann entsprechend ein Ergebnis (dazwischen sind noch einige mathematische Operatoren) in einen seperaten Vektor speichern möchte.
Dort kann ich aber auf keinen Fall vorher wissen, wie groß der Ergebnis-Vektor sein wird, das ist immer unterschiedlich. Trotzdem möchte Matlab, dass man den Vektor vorher anlegt. Wie gehe ich da am besten vor, gibt es da Tipps?
Vielen Dank im Vorraus,
Gruß
Tom
|
|
|
|
|
Jan S |

Moderator
|
 |
Beiträge: 11.057
|
 |
|
 |
Anmeldedatum: 08.07.10
|
 |
|
 |
Wohnort: Heidelberg
|
 |
|
 |
Version: 2009a, 2016b
|
 |
|
|
 |
|
Verfasst am: 26.10.2016, 14:31
Titel: Re: Verschachtelte Cell-Arrays auslesen + flexible Prealloca
|
 |
|
 |
|
Hallo Tom_Gast,
Es ist kein Fehler, ein Array iterativ wachsen zu lassen. Wenn es nur um ein paar Elemente geht, ist das harmlos. Wenn man aber z.B. eine Millionen Element einzeln aneinander hängt, werden insgesamt
sum(1:1e6) * 8 = 2 TerraByte
als Speicher vom Betriebssystem angefordert und hin- und her-kopiert. Da hört der Spaß dann auf.
Daher sollte man grundsätzlich immer pre-allozioeren. Und wenn Du in deinem Fall nicht weiß, wie viel Speicherplatz benötigt wird, ist eine zu hohe obere Grenze meistens kein Problem. Wieder das Beispiel mit 1e6 DOUBLES: Wenn Du vorsichtshalber 10 mal so viel Speicherplatz reservierst, sind das nur 80MB, also ein Klacks für moderne Computer. Gibt es in Deinem Fall eine theoretische Obergrenze?
Wenn nicht, kannst Du auch zunächst die einzelnen Vektoren in einem Cell-Array sammeln und am Schluss per
cat
verbinden.
Leider scheint dabei auch Matlab selbst schluderig mit der Pre-allocation umzugehen: Die C-Mex-Funktion https://www.mathworks.com/matlabcen.....leexchange/28916-cell2vec zählt zunächst den benötigten Speicher ab und ist manchmal um den Faktor 4 schneller als
cat
. Ups!
Gruß, Jan
Zuletzt bearbeitet von Jan S am 27.10.2016, 11:29, insgesamt einmal bearbeitet
|
|
|
Tom_Gast |
Gast
|
 |
Beiträge: ---
|
 |
|
 |
Anmeldedatum: ---
|
 |
|
 |
Wohnort: ---
|
 |
|
 |
Version: ---
|
 |
|
|
 |
|
Verfasst am: 27.10.2016, 08:09
Titel:
|
 |
Hallo,
vielen Dank für deine sehr hilfreiche Antowrt, Jan, hat super funktioniert.
Ich kannte den Katzen-Befehl cat vorher garnicht
Noch eine kleine Rückfrage zum zweiten Teil:
Zitat: |
Wenn nicht, kannst Du auch zunächst die einzelnen Vektoren in einem Cell-Array sammeln und am Schluss per cat verbinden. |
Das "Problem" bzw. die Warnung tritt aber auch beim Cell-Array auf. Wenn ich da meine Werte so fülle
Auch hier möchte Matlab, dass der Speicherplatz vorher angelegt wird. Oder wie hast du das genau gemeint?
Und: Auch wenn ich eine theoretische Obergrenze kenne, hat das immer den Nebeneffekt, wenn ich das z.B. mit
umsetze, dass dann der Vektor, sagen wir mal er wurde z.B. mit 400 Werten befüllt, am Ende des Befüllens unnötig Groß ist und dazu auch noch mit Nullen befüllt ist. Diese möchte man für die nächste Rechenschritten aber nicht haben.
Gruß Tom
|
|
|
Jan S |

Moderator
|
 |
Beiträge: 11.057
|
 |
|
 |
Anmeldedatum: 08.07.10
|
 |
|
 |
Wohnort: Heidelberg
|
 |
|
 |
Version: 2009a, 2016b
|
 |
|
|
 |
|
Verfasst am: 27.10.2016, 11:38
Titel:
|
 |
Hallo Tom_Gast,
Es benötigt viel weniger Resourcen, die überflüssig allozioerten Bereiche hinterher wieder frei zu geben, als das Array schrittweise wachsen zu lassen.
Ja, hier könnte man A auch gleich richtig pre-allozieren, aber in manchen Fällen geht es tatsächlich nicht. Jedenfalls hat man sich hier das iterative Anwachen erspart und ein {1x100} Cell-Array zu allocieren ist viel billiger als 100 Cell-Arrays zu erstellen, die jeweils index Elemente haben und das jeweils vorherige Array zu kopieren.
Das man mit der Obergrenze erstmal zu viel Speicher reserviert, ist harmlos: Siehe mein Beispiel oben: Vielleicht hat man mal 80MB zu viel alloziert. Das ist immer noch besser als 2 TB ! Den Speicher dann einmalig wieder auf die benötigte Größe zu kürzen, ist billig, denn Matlab gibt einfach das Ende des Speichers frei und muss nichts kopieren.
Gruß, Jan
|
|
|
Tom_Gast |
Gast
|
 |
Beiträge: ---
|
 |
|
 |
Anmeldedatum: ---
|
 |
|
 |
Wohnort: ---
|
 |
|
 |
Version: ---
|
 |
|
|
 |
|
Verfasst am: 27.10.2016, 11:43
Titel:
|
 |
Hallo Jan,
vielen Dank für die ausführliche Erläuterung. Das mit dem Speicher wieder freigeben ist ein sehr guter Hinweis, vielen Dank!
Somit konnten beide meiner Fragen zu 100% geklärt werden, Danke!
Gruß Tom
|
|
|
|
|
Einstellungen und Berechtigungen
|
|
Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
| RSS
Hosted by:
Copyright © 2007 - 2025
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
|
|