|
|
|
|
|
|
|
Ist das einfach nur "nice to know" oder hat das anwendbar irgendwelche Vorteile für die Behandlung von Elektrodynamik?
I.e., wie würde man die Arbeit motivieren, wenn man dafür Gelder einwerben wollte?
|
|
|
|
|
|
|
|
|
|
|
Wahrscheinlich eher nice-to-know, auch wenn es in der experimentellen Seite von analogen Raumzeiten Nutzen finden sollte. Unter anderem reden einige Optiker die "cloaks" bauen wollen gerne von deren Interpretation als analoge Raumzeiten. Und ich bin mir recht sicher, dass vieles davon nur eine begrenzte Lebensdauer haben dürfte, weil da halt mitunter ein wenig die Intuition für Raumzeiten fehlt...
In eine ähnliche Kerbe dürfte schlagen, dass man damit halt was an der Hand hat, um Ingeni- klassischen Elektromagne...tikern... ...ten... (Ja, der Name Elektromagnet für so jemanden ist lustig, den nehm ich jetzt...) die traditionelle Indexnotation etwas schmackhafter zu machen. Wenn auch nicht spaßig auszurechnen, so kann man damit zumindest sehr flott einige Effekte konzeptionell erklären (Fresnel-Fizeau: in bewegten Medien koppeln Magnet- und elektrisches Feld zu sowohl Magnetisierung als auch elektrischer Verschiebung, statt nur µH=B und D=epsilon*E.) Umgekehrt kann man die ganze elektromagnetischen Resultate für uns Relativisten leichter verständlich ausdrücken.
Ich mein, boah, ey, dreidimensionale Vektoren, Kreuzprodukte und Rotation und Divergenz und Gradient, Vektoranalysis, das ist doch alles notationeller Käse. Jetzt kann man den Elektromagneten auch mal ECHTE Notation an die Hand geben.
...und dann gibt es noch richtig krass "fundamentale Elektromagneten", die zwar eine Art Indexnotation benutzen, aber...keine Metrik benutzen, was die Notation wieder katastrophal kompliziert. Zumal die Koryphäen des Gebietes dann auch noch ein echt schlechtes Händchen haben, um Notation zu wählen. Ich schlage eine beliebige Seite in Hehl, Obukhov auf und mir käst das Gehirn und kreist der Hut. Deren Fragestellung ist aber auch sehr eigen, wenn auch cool: Kann man Lichtkegel erklären, nur mit Edyn, ohne Metrik? Was eine ziemlich coole, wenn auch knackig schwere Idee ist.
Does anyone here speak l33t?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Wraith of Seth am 21.06.2017 12:19]
|
|
|
|
|
|
|
|
|
Ich steige demnächst beim Computer Science department als Postdoc ein \o/ als Biologe ein bisschen furchteinflössend - aber ich bin gespannt 
Werde an "computational models for early vision" arbeiten.
|
|
|
|
|
|
|
|
|
|
|
|
Computermodelle aus Kindersicht?
|
|
|
|
|
|
|
|
|
|
|
|
Comoutermodelle von Kindersicht
|
|
|
|
|
|
|
|
|
|
|
Ich werde demnächst einen 4 Jahresvertrag mit Habilitationsziel unterschreiben, obwohl ich das gar nicht will. 
Zumindest werde ich jetzt DFT Knecht.
|
|
|
|
|
|
|
|
|
|
|
|
Dachte du wolltest in die Industrie? Nix schönes gefunden?
|
|
|
|
|
|
|
|
|
|
|
Es hat sich ein bisschen was an unseren Plänen verändert, sodass wir erst in 1-1.5 Jahren hier wegkommen. Daher habe ich nochmal meinen Vertrag verlängern lassen. Da Landesstellen aber nur mit "Qualifikationsziel" vergeben werden, muss ich offiziell eine Habilitation anstreben.
Die Wahrscheinlichkeit, dass ich das durchziehe, ist aber gering.
|
|
|
|
|
|
|
|
|
|
|
Na dann Gratulation zum neuen Vertrag! :-)
Wirst du inhaltlich einfach weitermachen oder ändert sich auch das Aufgabengebiet?
|
|
|
|
|
|
|
|
|
|
|
|
Wie gesagt, ich werde wohl hauptsächlich Dichtefunktionaltheorie machen. Ist ganz nett, damit kenne ich mich noch wenig aus.
|
|
|
|
|
|
|
|
|
|
|
Irgendwie sind die Performance Unterschiede zwischen Python-funktionen verblüffend.
Das folgende dauert 2 Sekunden:
| |
| Code: |
with open(datafile, 'r') as f:
data = np.stack([np.fromstring(line, sep=',') for line in f], axis=0) |
|
Aber das hier dauert 10mal so lang:
| |
| Code: |
data = np.genfromtext(datafile) |
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Concrete_R am 23.06.2017 12:13]
|
|
|
|
|
|
|
|
|
|
In der Funktion passiert ja auch noch ein bisschen mehr.
|
|
|
|
|
|
|
|
|
|
|
Ja, hat aber ewig gedauert bis ich das rausgefunden habe 
|
|
|
|
|
|
|
|
|
|
|
Meinten Sie pandas.read_csv ?
Könnte gut sein, dass das noch ein bisschen viel schneller ist, wenn das Format passt.
e/ Wenn ich so drüber nachdenke, np.loadtxt sollte auch deutlich schneller sein als die Schleife in python.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 23.06.2017 17:56]
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Meinten Sie pandas.read_csv ?
Könnte gut sein, dass das noch ein bisschen viel schneller ist, wenn das Format passt.
e/ Wenn ich so drüber nachdenke, np.loadtxt sollte auch deutlich schneller sein als die Schleife in python.
| |
Sofern ich das richtig sehe produziert np.loadtxt nur die erste Zeile als 1d Array, nicht 2d.
pandas.read_csv hängt irgendwie und produziert nach mehreren Minuten immer noch nichts, obwohl das online als bestes gepriesen wird. Vll. Weil die Datei extrem viele Spalten und nur ca 100 Reihen hat?
|
|
|
|
|
|
|
|
|
|
|
Ah, in dem Fall ist der Zeitverlust durch die Schleife nicht so problematisch, entsprechend ist deine Lösung tatsächlich ganz gut mit dabei. Von wie vielen Spalten sprechen wir denn? Ist das auch brav tidy data?
Ansonsten sind die Resultate aber in der Tat spannend. csv mit numpy parsen ist arg langsam, weil das ein in Python geschriebener parser ist. Pandas ist im Allgemeinen schneller. Gar nicht so sehr wie ich dachte jedoch. In diesem einfachen Fall kann die List Comprehension gut mithalten:
| |
| Code: |
In []: np.savetxt('/tmp/stuff.csv', np.random.normal(size=(100, 10_000)), delimiter=',')
...: %timeit np.loadtxt('/tmp/stuff.csv', delimiter=',')
...: %timeit with open('/tmp/stuff.csv', 'r') as f: np.stack([np.fromstring(line, sep=',') for line in f], axis=0)
...: %timeit pd.read_csv('/tmp/stuff.csv', sep=',', header=None)
...: %timeit pd.read_csv('/tmp/stuff.csv', sep=',', header=None, na_filter=False, low_memory=False)
...:
1 loop, best of 3: 1.08 s per loop
1 loop, best of 3: 408 ms per loop
1 loop, best of 3: 524 ms per loop
1 loop, best of 3: 338 ms per loop
|
|
Vergleiche mit transponierten Daten:
| |
| Code: |
In []: np.savetxt('/tmp/stuff.csv', np.random.normal(size=(10_000, 100)), delimiter=',')
...: %timeit np.loadtxt('/tmp/stuff.csv', delimiter=',')
...: %timeit with open('/tmp/stuff.csv', 'r') as f: np.stack([np.fromstring(line, sep=',') for line in f], axis=0)
...: %timeit pd.read_csv('/tmp/stuff.csv', sep=',', header=None)
...: %timeit pd.read_csv('/tmp/stuff.csv', sep=',', header=None, na_filter=False, low_memory=False)
...:
1 loop, best of 3: 1.15 s per loop
1 loop, best of 3: 438 ms per loop
1 loop, best of 3: 261 ms per loop
1 loop, best of 3: 230 ms per loop
|
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 23.06.2017 22:14]
|
|
|
|
|
|
|
|
|
Nein, leider keine tidy data. Einfach nur rohe EEG Daten, also zwischen 30.000 und 80.000 spalten.
Mit der schleife ist es gerade schnell genug, aber ich probiere Mal die low_memory Option bei Pandas.
|
|
|
|
|
|
|
|
|
|
|
|
Aber wodurch ergeben sich da so viele Spalten? Wie dem auch sei, du hast mein Mitleid . Als letztes würde ich noch sagen, dass wenn die IO so kritisch ist ein schlaueres Datenformat viel hilft, ich finde der beste Tradeoff aus Convenience und Performance ist die HDF5-API von Pandas. Bei verhältnismäßig vielen Daten (sagen wir ~100GB) habe ich auch gute Erfahrungen mit xarray (i.e. NetCDF) gemacht - falls deine Daten schön "rechteckig" sind. Dann kann man damit aber sehr schick nur Teile der Daten laden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Aber wodurch ergeben sich da so viele Spalten? Wie dem auch sei, du hast mein Mitleid . | |
Die Spalten sind Zeit, mit 1024 Hz über mehrere Minuten aufgenommen 
| | Als letztes würde ich noch sagen, dass wenn die IO so kritisch ist ein schlaueres Datenformat viel hilft, ich finde der beste Tradeoff aus Convenience und Performance ist die HDF5-API von Pandas. Bei verhältnismäßig vielen Daten (sagen wir ~100GB) habe ich auch gute Erfahrungen mit xarray (i.e. NetCDF) gemacht - falls deine Daten schön "rechteckig" sind. Dann kann man damit aber sehr schick nur Teile der Daten laden.
| |
Danke - aber leider geht es darum Daten von einem anderen Team zu Laden, in der Form in der die es gespeichert haben...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Concrete_R am 24.06.2017 7:05]
|
|
|
|
|
|
|
|
|
Sei froh, dass du CSV hast. Ich muss im Medizinbereich auch mal mit XLSX Daten arbeiten. Warum das Gerät gerade das Format ausgibt, und nicht ein platzsparendes, schlaues Format? Who knows.
Das sind dann eine Million Zeilen XML-Markup, wo dir instant schlecht wird, und 'n paar Zeilen Daten.  .
Alternative Idee, um die Auslesegeschwindigkeit möglicherweise zu erhöhen:
- Eine Schleife, die alle Daten ausliest.
- Nach X Zeilen, werden diese Zeilen an einen Worker weitergegeben.
- Dieser Worker parsed die eigentlichen Daten und fügt sie in das Ergebnis ein.
- Multiple, parallele Worker arbeiten dieser Daten ab.
Vorteil:
- Deine eine Auslese-Schleife macht nur eine Zuweisung, welcher Worker welche Zeilen verarbeitet
- Somit sparst du dir das parsen nach jeder Zeile
Nachteile:
- Out-of-Order Dateistücke. Müsste man irgendwie markieren, wo was hin kommt. Zeilennummerierung, oder so.
- Aufwendiger umzusetzen.
Hm. Vielleicht? Aber wird vermutlich auch nicht den Performancegewinn bringen.
Disclaimer: Hab keine Ahnung von Python.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von derSenner am 24.06.2017 10:16]
|
|
|
|
|
|
|
|
|
| | Zitat von derSenner
Sei froh, dass du CSV hast. Ich muss im Medizinbereich auch mal mit XLSX Daten arbeiten. Warum das Gerät gerade das Format ausgibt, und nicht ein platzsparendes, schlaues Format? Who knows.
Das sind dann eine Million Zeilen XML-Markup, wo dir instant schlecht wird, und 'n paar Zeilen Daten. http://imgur.com/C5mtIXt.png.
| |
Damit das Format menschenlesbar ist? Finde ich (wenn die Daten nicht ausschließlich maschinell weiterverarbeitet werden sollen) nicht schlimm, und lässt sich mit passenden Bibliotheken auch vernünftig einlesen.
|
|
|
|
|
|
|
|
|
|
|
Das geht mit CSV doch genau so, wenn du das in Excel oder so importierst?
Zu 99% wird das kein Mensch angucken. Wenn, dann wird das irgendwie weiterverarbeitet.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von derSenner am 24.06.2017 10:17]
|
|
|
|
|
|
|
|
|
| | Zitat von derSenner
Sei froh, dass du CSV hast. Ich muss im Medizinbereich auch mal mit XLSX Daten arbeiten. Warum das Gerät gerade das Format ausgibt, und nicht ein platzsparendes, schlaues Format? Who knows.
Das sind dann eine Million Zeilen XML-Markup, wo dir instant schlecht wird, und 'n paar Zeilen Daten. http://imgur.com/C5mtIXt.png.
Alternative Idee, um die Auslesegeschwindigkeit möglicherweise zu erhöhen:
- Eine Schleife, die alle Daten ausliest.
- Nach X Zeilen, werden diese Zeilen an einen Worker weitergegeben.
- Dieser Worker parsed die eigentlichen Daten und fügt sie in das Ergebnis ein.
- Multiple, parallele Worker arbeiten dieser Daten ab.
Vorteil:
- Deine eine Auslese-Schleife macht nur eine Zuweisung, welcher Worker welche Zeilen verarbeitet
- Somit sparst du dir das parsen nach jeder Zeile
Nachteile:
- Out-of-Order Dateistücke. Müsste man irgendwie markieren, wo was hin kommt. Zeilennummerierung, oder so.
- Aufwendiger umzusetzen.
Hm. Vielleicht? Aber wird vermutlich auch nicht den Performancegewinn bringen.
Disclaimer: Hab keine Ahnung von Python.
| |
Den Aufwand mache ich mir nicht, vor allem weil es als Portion der Gesamtlaufzeit nicht wirklich viel ausmacht...
Das mit den XLSX Daten hab ich auch schon gehört, das R package für xlsx Daten bestätigt meine Erwartung, wie man sich bei sowas fühlt:
|
|
|
|
|
|
|
|
|
|
|
Wo es hier gerade um Python ging - hat schon Mal jemand Coconut ausprobiert?
coconut-lang.org
Ein "Superset" von Python, mit mehr functional programming syntax. Hat zB einen forward pipe operator, den ich in dplyr so liebe:
| |
| Code: |
3 |> factorial |> print |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A 2005 Deutsche Bank report referred to it as a “bizarre” “triple-pay” system, in which “the state funds most research, pays the salaries of most of those checking the quality of research, and then buys most of the published product”.
| |
Wenn man es so klar vorgelegt bekommt kann man sich nur an den Kopf fassen.
Mein naechster Posten ist wahrscheinlich vom Wellcome Trust gesponsort, die letztes Jahr ihren eigenen Journal angefangen haben:
https://wellcomeopenresearch.org/
Mal gucken, vielleicht muss ich mich nicht mehr mit Journals abgeben 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Concrete_R
Ich steige demnächst beim Computer Science department als Postdoc ein \o/ als Biologe ein bisschen furchteinflössend - aber ich bin gespannt
Werde an "computational models for early vision" arbeiten.
| |
Spezifisch auf bestimmte Organismen?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Concrete_R
Wo es hier gerade um Python ging - hat schon Mal jemand Coconut ausprobiert?
coconut-lang.org
Ein "Superset" von Python, mit mehr functional programming syntax. Hat zB einen forward pipe operator, den ich in dplyr so liebe:
| |
| Code: |
3 |> factorial |> print |
|
| |
Direkt mal installiert und angeschaut.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von PutzFrau
| | Zitat von Concrete_R
Ich steige demnächst beim Computer Science department als Postdoc ein \o/ als Biologe ein bisschen furchteinflössend - aber ich bin gespannt
Werde an "computational models for early vision" arbeiten.
| |
Spezifisch auf bestimmte Organismen?
| |
Alles in Menschen. Das early bezieht sich auf frueh im visuellen System. Wird viel Cognitive Neuroscience und Neuroimaging beinhalten, weshalb ich (denke ich mal) den Job bekommen habe.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXI ( X-Ray-Edition ) |
