Servus Florian! Am 28.09.2016 um 00:09 schrieb Florian Lindner:
Dabei will ich folgendes:
- Die Datei soll menschen-lesbar sein
- Eingelesen werden soll es mit Python um dann z.B. mit numpy weiterverarbeitet werden.
Wie würde nun ein geeignetes Datenformat ausschauen, was ich dann auch problemlos mit Python einlesen kann? Ich frage mich, was Du mit dem Ganzen eigentlich bezweckst.
Du willst aus C++ in ein menschenlesbares Datenformat schreiben um es dann zu Parsen um es dann mit Numpy zu verarbeiten? Das erscheinen mir gleich zwei Widersprüche zu sein: Wenn Du numpy brauchst sind es viele Daten. Wenn Du viele Daten hast, will die sich ein Mensch nicht mehr anschauen. Und Du willst keinen Parser dafür bauen, weil der a) langsam sein wird und b) Du dir wirklich sicher sein musst, dass er richtig funktioniert. Was bei vielen Daten nicht ganz einfach zu überprüfen ist. Dein Daten sind irregulär, also keine rechteckige Matrix. Daher ist Numpy sowieso nicht gut geeignet diese Daten direkt zu verarbeiten. Warum willst Du also Dinge, die sich unterscheiden in einer Datei aneinander hängen, um sie später für die Verarbeitung in Numpy wieder auseinander zu pfriemeln. Wenn Du an Deiner "Alles in einen File"-Strategie festhält, wirst Du beim Einlesen sowieso eine Art von Dispatching machen müssen um die (sofern ich verstanden habe homogenen) Daten der einzelnen Runs wieder aus Deinem File zu extrahieren. Wir verarbeiten für einen großen KFZ-Hersteller CAN-Bus-Daten. Das sind Signale die je nach Datenquelle anders kodiert sind. Also z.B. "Blinker Hinten Rechts" hat nur ein paar Zustands-Bits. Dagegen ist die Drehzahl, das Drehmoment und der Öldruck, des Motors ein Fließkomma-Wert. Alle diese Daten kommen als ein großer Datenstrom an. Das Problem ist also dem Deinigen evtl. ähnlich gelagert. Jede da draußen mit CAN-Daten beschäftigte Firma baut sich, wie Du es auch vor hast, ein eigenes Datenformat, um mit den Daten umzugehen. Wir wollten nicht den gleichen Fehler machen und haben ein standardisiertes Datenformat genommen. Wir dispatchen die CAN-Daten nach der Datenquelle jeweils in eine Tabelle eines HDF5-Files. Es gibt also eine Tabelle für den "Blinker hinten rechts" und eine andere Tabelle für die Motordaten. Jede dieser HDF5-Tabellen hat dabei eine andere Struktur. HDF5 ist ein sehr flexibles selbst dokumentierendes, standardisiertes, komprimiertes, binäres, plattformunabhägiges Datenformat welches mit zwei Python-Befehlen eine Tabelle in einen numpy Array lesen/schreiben kann [1]. Ein HDF5-File ist aufgebaut wie ein Dateisystem mit Ordnern in denen Tabellen (und beliebige andere Dinge wie z.B. Grafiken) liegen können. Noch dazu kann mit mehr als C-Geschwindigkeit in gigantisch großen Datenbeständen (größer als der verfügbare RAM) aus Python heraus gesucht und gefiltert werden. HDF5 ist erstmal nicht menschenlesbar - was meiner Meinung nach auch in den seltensten Fällen nötig oder wünschenswert ist. Aber es gibt mit hdf5dump und hdfview [2] plattformunabhängige Werkzeuge um HDF5-Files konfortablel zu betrachten oder in menschenlesbare Form zu bringen. Die Python Charting-Software VEUSZ [3] kann HDF5-Files direkt einlesen und verarbeiten, wie auch alle anderen größeren Charting-Programme Import-Filter für HDF5 anbieten. Ich habe mit Aesir [4] einen QT-Python-HDF5-Viewer programmiert der deutlich schneller als HDFView ist. Auch haben wir Datenklassen für Plone programmiert, um direkt im Browser durch HDF5-Files zu navigieren und deren Tabellen als Web-Tabellen und Charts darzustellen zu können [5]. Das ist der große Vorteil eines gut dokumentierten und standardisierten Datenformats, es ist eine gute Basis um selber darum ein Ökosystem zu entwickeln. Ich hoffe Du erzählst uns ein bisschen mehr über Dein Projekt, dann können wir Dir sicher bessere Ratschläge geben als JSON, YAML, welche beide mit Numpy nicht so recht zusammengehen. Beste Grüße Volker [1] http://www.pytables.org/ [2] https://support.hdfgroup.org/products/java/hdfview/ [3] http://home.gna.org/veusz/ [4] Noch nicht released. Kann bei Interesse aber gerne das Teil "as is" mal auf github schieben. [5] Erste Prototypen. -- ========================================================= inqbus Scientific Computing Dr. Volker Jaenisch Richard-Strauss-Straße 1 +49(08861) 690 474 0 86956 Schongau-West http://www.inqbus.de =========================================================