Coding Style Zeilen vs Spaltenvektoren

WICHTIG: Der Betrieb von goMatlab.de wird privat finanziert fortgesetzt. - Mehr Infos...

Partner:

Forum

Option

[Erweitert]

• Diese Seite per Mail weiterempfehlen

Gehe zu:

Michael Tansella

Forum-Newbie


	Beiträge: 3

	Anmeldedatum: 20.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 04.06.2013, 12:52 Titel: Coding Style Zeilen vs Spaltenvektoren

Hallo zusammen,

habt ihr für euch irgendwelche Regeln, wann ihr Zeilen- und wann Spaltenvektoren verwendet. Ist natürlich Geschmacksache, aber mich nervt es dass ich es dauernd anders mache und mir ist bisher kein sinnvolles Kriterium eingefallen.

Aus der Mathematik ist man ja vertikale Vektoren gewohnt, allerdings muss man dann bei Matlab umständlich mit Semikolons arbeiten, deshalb ist es bequemer horizontale Vektoren zu verwenden vec = [x y z].

Erzeugt man dann allerdings beispielsweise X-Werte mit linspace hat man schon wieder einen horizontalen Vektor mit X-Werten.

Mir sind die MATLAB Befehle fürs Transponieren usw. bekannt, ich möchte mir nur einen konsistenten Coding Style angewöhnen und deshalb interessiert es mich wie ihr das macht.

Viele Grüße,
Michael

Jan S

Moderator


	Beiträge: 11.057

	Anmeldedatum: 08.07.10

	Wohnort: Heidelberg

	Version: 2009a, 2016b

Verfasst am: 04.06.2013, 16:48 Titel: Re: Coding Style Zeilen vs Spaltenvektoren

Hallo Michael,

Das ist eine gute Frage!

Ich vermeide Ausdrücke wie "[x y z]" unbedingt. Es ist zwar valide Syntax, aber es kann überraschen unübersichtlich sein:

Code:

a = [1 +2 +2i]
b = [1 + 2 +2i]
c = [1 +2 + 2i]
k = 1;
d = [1 -k 3] % Welche Größe hat dies?!

Funktion ohne Link?

Um Rätselraten zu vermeiden und die Gefahr von Tippfehlern zu reduzieren füge ich deswegen immer alle möglichen Kommas ein, ebenso Semicolons am Zeilenende:

Code:

x = [1 2
3 4];
y = [1 2 ...
3 4];
% ??? Eindeutig:
z = [1, 2; ...
3, 4];

Funktion ohne Link?

In einem 10 Zeilen Programm mag das rosinenspaltig wirken, ich arbeite aber auch mit Programmen, die 200'000 Zeilen haben, so dass das Debuggen extrem wichtig wird.

Ich stand vor dem gleichen Problem wie Du. Und MathWorks selbst ebenfalls:Die Orientierung der Ausgabe mancher Toolbox-Funktionen ändert sich mit den Versionen. Deshalb würde es mit schwer fallen, auf Anhieb die Dimensionen folgender Outputs anzugeben:

Code:

[a,b,c] = unique(1:5);
[d,e,f] = unique((1:5).');

Funktion ohne Link?

Während a und d wohl der Orientierung des Inputs folgen, mag das für die Index-Vektoren nicht gelten.
Wenn ich nun c und f addieren müsste, würde ich das nicht dem Zufall überlassen, sondern es kontrolliert setzen:

Code:

k = c(:) + f(:);

Funktion ohne Link?

Der (:) Operator ist sehr schnell, denn er kopiert keine Daten im Speicher. Deshalb könnte man eigentlich Spalten-Vektoren bevorzugen.

Code:

x = rand(5,5);
x = x(x > 0.5);
size(x)

Funktion ohne Link?

Auch hier wird ein Vektor erzeugt, obwohl der Input eine Matrix ist. Da aber nicht von vornherein klar ist, ob in jeder Zeile bzw. Spalte gleich viele Elemente gelöscht werden, muss die Ausgabe ein Vektor sein. Aber mit welcher Orientierung? Hier wird ein Spalten-Vektor ausgegeben. Die Index-Vektoren der Mengen-Funktionen (unique etc) sind dagegen Zeilen-Vektoren.
FOR benötigt ebenfalls einen Zeilen-Vektor, läuft aber in der Tat sogar mit Matrizen:

Code:

x = magic(4)
for k = x
k
end

Funktion ohne Link?

Das find ich etwas schräg. Aber man muss es ja auch nicht benutzen.

Ich verfolge deshalb diese Strategie:
1. Cell Strings werden als Spalte gespeichert: {N x 1}
2. Zahlen-Vektoren, die nach ihrer Definition nur als Vektor sinnvoll sind, speichere ich als Zeilen: [1 x N]
3. Sowie Zahlen auch als Matrix oder Array existieren könnten (wie z.B. ein satz von Messwerten), wird die "Zeit"-Abhängigkeit entlang der ersten Dimension gespeichert, was zu [M x 1] Vektoren führen kann, falls eben auch nur ein Messwert vorliegt. Statt "Zeit" wird natürlich jede andere unabhängige Variable eingesetzt.

Wann immer eine Entscheidung uneindeutig ist, oder sogar wenn sie eindeutig ist(!!!), sorgen entsprechende Kommentar im Code dafür, dass auch ein anderer User nach 10 Jahren auf Anhieb versteht, wieso ich welche Orientierung angenommen habe.

Aber diese Regeln sind ohne Frage willkürlich. Aber wenn man sie konsequent einhält, kann man sich viel Debug-Zeit ersparen.

Matlabs automatische Entscheidung, ob eine Operation entlang der Zeilen oder Spalten ausgeführt wird (first non-singelton dimension) kann tückisch sein. Ich hatte eine Messdaten-Analyse geschrieben, die mehrere Kurven als Matrix speicherte und die Mittelwert der Daten berechnet:

Code:

n = 5;
Daten = rand(100, n);
Mittel = mean(Daten);

Funktion ohne Link?

Als ich das Programm dann mal für eine merkwürdige Messung laufen liess, die nur einen Messpunkt beinhaltete, war das Ergebnis unerwartet:

Code:

n = 1;
Daten = rand(100, n);
Mittel = mean(Daten); % ==> [1 x 1]

Funktion ohne Link?

Seit dem füge ich die zu bearbeitende Dimension grundsätzlich ein, da es viel komfortabeler ist 1 Sekunde mehr Tippen zu müssen als Stunden oder Tage mit dem Debuggen zu verbringen.

Gruß, Jan

Michael Tansella

Themenstarter

Forum-Newbie


	Beiträge: 3

	Anmeldedatum: 20.07.10

	Wohnort: ---

	Version: ---

Verfasst am: 04.06.2013, 18:03 Titel:

Vielen dank für die ausführliche und hilfreiche Antwort.
Dein Ansatz klingt vernünftig und werde ich mal testen.
Schönen Abend noch.


Einstellungen und Berechtigungen
Beiträge der letzten Zeit anzeigen:	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.