oldpath = cd; % Pfad der m-file (main.m) wird ermittelt, um automatisch zurückzufinden.
endung = length(' .mat'); % Für weitere Verarbeitung, wird die Länge der Dateiendung, sowie als Zusatzzeichen (Nr. der Messung), ermittelt. cd(fpath); % Wechselt den Aktuellen Ordner an den Ort, wo sich die Messungen befinden.
datei = [fname(1:findstr(fname,'g_')) '_']; % Dateiname wird gekürzt, um Folgemessungen einzulesen. % Beispiel: % Aus der Datei "GP30_Messung_1.mat" wird "GP30_Messung_"
% Nummer der Messung finden
nr = fname(1 : findstr(fname,'.mat') - 1);
nr = fliplr(nr);
nr = nr(1: findstr(nr,'_')-1)
nr = str2num(fliplr(nr));
Anz_Messung = 100; % Anzahl der Messungen die geladen werden
X = zeros(2000,Anz_Messung); % Arbeitsspeicher schonen, d.h. eine Matrix aus 2000 * n wird erstellt
for i = nr:1:(Anz_Messung+nr)-1% Liest die Anzahl der Messungen, z.B. 1000, ein und schreibt diese in die vorgefertigte Matrix X load([datei,num2str(i),'.mat']);
X(:,((i-nr)+1))=eval(genvarname(['Messung',num2str(i)]));
end clear i;
name = datei(1 : findstr(datei,'_Messung') - 1); % Erstellt ein String, der nur aus dem Anfang des Dateinames besteht. % Beispiel: % Aus der Variablen "datei" mit dem String "GP30_Messung_" wird "GP30". eval([name ' = mean(X,2);']); % Bildet den Mittelwert der Anzahl der aufgenommen Messungen
Soweit funktioniert alles wunderbar.
Im Code obigen Code sieht ihr, wie ich 100 Messungen laden kann und daraus wird der Mittelwert gebildet, sodass ich für die Verarbeitung der Messung einen Vektor habe.
Hier liegt nun auch mein Problem.
Habe mich dazu entschieden für jede einzelne Messung diese Prozedur anzuwenden ohne das ich den Mittelwert bilde.
Ansich funktioniert das auch mit meinem Code, indem ich einfach bei
Anz_Messung = 1; eingebe und in der Spalte wo der Mittelwert gebildet wird passiert nichts da nur ein Vektor.
Doch damit wird es sehr mühselig eine Anzahl von 100 Merkmalsvektoren zu erzeugen.
Eine Lösung wäre, wenn ich den Mittelwert gar nicht bilde.
Doch in diesem Fall müsste ich meine ganze m-File auch anpassen, was bei einigen Stellen gar nicht mal so einfach wäre.
Im Prinzip müsste doch mein Vorhaben mit noch einer weiteren Schleife funktionieren, wo ich mehrere Messungen aufnehmen kann und jede Einzelne wird verarbeitet und in Merkmalsmatrix reingeschrieben.
Letztendlich gilt aber für OOP Entwicklung das gleiche, wie unter anderen Sprache (Java, C++, C#) für das Konzept. Z.B. kann ich bezügl. OOP das Buch von Helmut Balzert "Grundlagen der Informatik" emfpehlen.
eine Klasse für die Berechnung der Normalized Compression Distance mit unterschiedlichen Algorithmen und Cache Struktur
http://flashpixx.de/svn/Matlab_NCD/
und eine Klasse um eine beliebe Datenbank in Matlab zu verwenden http://flashpixx.de/svn/Matlab_Database/
Man muss zur Verwendung nur den JDBC Treiber in Matlab einbinden und kann dann die Datenbank komplett nutzen. SQL Statement übergeben und Daten werden als Strukt geliefert.
Genereller Ansatz ist eben ein Verzeichnis mit einem @ anzulegen, das so heißt wie die Klasse und darin werden dann die m-Files abgelegt.
Verfasst am: 07.06.2012, 12:18
Titel: Re: Hilfe zur Vereinfachung meines Codes
Hallo NNLab,
Wenn Du den Code "vereinfachen" möchtest, halte ich einen Objekt-Orientierten Ansatz für kontra-produktiv.
Ich würde andere Dinge bevorzugen. Ich finde die multiple Konvertierung des Filenamens verwirrend kompliziert. Um genau zu sein, verstehe ich sie sogar nicht, so dass ein Verbesserungsvorschlag kaum möglich, aber dringend wichtig wäre...
Ich vermute, man könnte die durchgeführten Aufgaben mit einem einzigen SSCANF-Befehl erledigen.
Ich benutze grundsätzlich nur "qualifizierten" File-Namen, die also den vollständigen Pfad enthalten. Das Wechseln des aktuellen Verzeichnisses per CD wird damit überflüssig und man kann gar nicht mehr vergessen den Orginal-Zustand wieder herzustellen.
FILEPARTS ist hilfreich um die Einzelteile des File-Names zu erhalten.
Ausserdem ist es deutlich effizienter und sicherer die Ausgabe von LOAD explizit in eine Variable zu schreiben und auf EVAL unter allen Umständen zu verzichten. Wie in diesem Forum schon hundertfach erklärt, gibt es immer eine bessere Möglichkeit als EVAL.
Also:
Code:
Data = load(...);
X = Data.XYZ;
% Oder:
Fields = fieldnames(Data);
X = Data.(Fields{1});
Verfasst am: 07.06.2012, 13:46
Titel: Re: Hilfe zur Vereinfachung meines Codes
Jan S hat Folgendes geschrieben:
Wenn Du den Code "vereinfachen" möchtest, halte ich einen Objekt-Orientierten Ansatz für kontra-produktiv.
Sehe ich das richtig, dass dann ein prozeduraler Code ggf noch mit global operierenden Variablen einfacher ist?
Tut mir leid, aber diese These, dass OOP kontra-produktiv ist halte ich für extrem gewagt
mein Senf dazu:
OOP hilft bei größeren Projekten, den Code zu strukturieren. Als "größeres" Projekt würde ich das noch nicht unbedingt sehen.
So oder so: wenn man den Code so als Methode in einer Klasse unterbringt, wird zwar vielleicht die Nutzung von außen einfacher, der Code bleibt ja aber so, wie er ist, und wird somit nicht vereinfacht.
Aus meiner Sicht wäre der erste Schritt, Verbesserungen im Code durchzuführen (siehe Jans Vorschläge). Dann kann man sich immer noch überlegen, ob man mit Klassen und Objekten arbeiten möchte.
Globale Variablen würde ich so oder so nach Möglichkeit meiden, insbesondere in größerer Häufung.
Verfasst am: 08.06.2012, 00:37
Titel: Re: Hilfe zur Vereinfachung meines Codes
Hallo flashpixx,
Ich meine nicht, dass objekt-orientiert Programmierung prinzipiell kontra-produktiv ist. Im Gegenteil: Wenn ein Programm mehr als 200'000 Zeilen Matlab Code enthält ist ohne OO Design kaum noch eine Wartbarkeit, Erweiterbarkeit und Debugbarkeit zu erreichen. Allerdings kann man eine OO-Architektur natürlich auch ohne die OO-Methoden in Matlab implementieren. Ein Information-Hiding, Data-Incapsulation, Inheritance, Polymorphie und eine Inter-Objekt-Kommunikation kann man auch mit Structs und Procedures abbilden, dann benötigt man aber einen strengen und korrekten Programmierstil, um nicht mal eben in den Daten rumzupfuschen, weil es ja möglich ist.
Wenn ich aber NNLabs bisheriges Programm anschaue, vermute ich, dass das Erlernen von Matlabs OO-Methoden zunächst mehr Zeit benötigt, als für das Projekt angemessen ist. Die Lernkurve ist bei prozeduraler Programmierung zunächst einfach flacher.
Verfasst am: 08.06.2012, 21:05
Titel: Re: Hilfe zur Vereinfachung meines Codes
Jan S hat Folgendes geschrieben:
Ich meine nicht, dass objekt-orientiert Programmierung prinzipiell kontra-produktiv ist. Im Gegenteil: Wenn ein Programm mehr als 200'000 Zeilen Matlab Code enthält ist ohne OO Design kaum noch eine Wartbarkeit, Erweiterbarkeit und Debugbarkeit zu erreichen.
Full Ack.
Jan S hat Folgendes geschrieben:
Allerdings kann man eine OO-Architektur natürlich auch ohne die OO-Methoden in Matlab implementieren. Ein Information-Hiding, Data-Incapsulation, Inheritance, Polymorphie und eine Inter-Objekt-Kommunikation kann man auch mit Structs und Procedures abbilden, dann benötigt man aber einen strengen und korrekten Programmierstil, um nicht mal eben in den Daten rumzupfuschen, weil es ja möglich ist.
Das stimmt auch, als zusätzliches Beispiel wäre der Linux Kernel zu nennen, der ja in C rein prozedural entwickelt ist, wobei man aber eben die notwendigen Styleguides eben einhalten muss bzw. definieren muss. Leider ist meine Erfahrung dabei wirklich, dass wenn man es kann, eben schnell der Code zusammen gestrickt wird und gerade Matlab bietet sich an vielen Stellen dafür wirklich an, was ich eigentlich sehr Schade finde, denn eine ordentliche Strukturierung ist auch mit Matlab möglich.
Jan S hat Folgendes geschrieben:
Die Lernkurve ist bei prozeduraler Programmierung zunächst einfach flacher.
Jain, ich denke, wenn man einem Anfänger direkt die Paradigmen von OOP richtig bei bringt, sollte sich das nicht wirklich unterscheiden.
NNLab hat Folgendes geschrieben:
Hi,
Wenn ich 100 Messungen lade, will ich das jede Einzelne berechnet wird und zum Schluss sollen alle Ergebnisse in eine Matrix geschrieben werden.
Deine Frage ist hier zu generell, keiner weiss hier wie Deine Messungen strukturiert und wie mit den Daten gearbeitet werden muss, damit das Ergebnis raus kommt, was Du möchtest. Es ist hilfreich, wenn hier einmal skizzierst wie die Daten aussehen, wie sie nach dem lesen aus der Datei strukturiert sind und wie sie nach der Verarbeitung aussehen sollen
man sagt allgemein "eval ist evil", denn es führt zu schlecht verständlichem Code und zusätzlich kann man damit bei ungeprüfter Verwendung auch eine große Sicherheitslücke erzeugen (siehe dazu entsprechende Informationen für JavaScript, PHP und Ruby).
Du kannst mit genvarname und einem Struct oder einer Map so etwas ohne eval erzeugen:
Wie flashpixx schon schreibt, ist EVAL ein ausgesprochen schlechter Ansatz. Einen Index im Namen der Variablen zu verstecken ist einerseits sehr unpraktisch, weil man später wieder ebenso komplizierte Methoden benötigt, um auf die Variablen zuzugreifen. Zudem ist der Zugriff auf dynamisch per EVAL erzeugter Variablen bei der Bearbeitung dramatisch langsamer als bei Variablen, die fest programmiert im Code stehen.
Wenn Du die daten schon als Martrix vorliegen hast, ist der Zugriff per "X(:, 3)" viel effizienter und klarer als über ein mühsam zusammengefrickeltes "y_3".
ich glaube euch, wenn ihr mir sagt, dass die Methode mit EVAL schlecht ist.
Nur bin ich mit meinem Programm nun so weit gekommen, dass das Umschreiben
des Codes nun den Rahmen sprengen könnte.
Arbeite demnächst mit neuronalen Netzen, und brauchen dafür viele Datensätze.
Die Abgabe meiner Diplomarbeit steht bald an.
Wenn am Ende alles gemacht ist, und ich noch etwas zeit habe, werde ich mir das ganze
mir noch mal angucken und es verfeinern und vereinfachen so weit es geht.
Nichtsdestotrotz danke ich euch für jeden Tipp.
PS: Was die komplizierten Methoden zur Weiterverarbeitung angeht, habe ich nun das Problem, doch spreche ich es im anderen Thread an, weil es dort hingehört
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
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.
RSS