|
|
|
|
Meine Zelle sei l=10 lang. Wenn ich ein Atom bei x=1 und eins bei x=9 habe, dann ist die Distanz nicht 8 sondern 2.
Das meine ich mit periodischen Randbedingungen. Das gleiche in alle Richtungen. Die Zellenlänge in alle Richtungen sei bekannt.
/e: Aber mach dir nciht zu viel Arbeit. Ich sehe es ja wie du, habe nur im Moment nicht die Zeit, mir das zu erarbeiten. Die Skripte die ich schreibe sind immer nur so utility Gedöns, die nicht schnell und robust sein müssen, deshalb ist Priorität einfach der Programmieraufwand.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 13.02.2017 11:56]
|
|
|
|
|
|
Ich kann dich da gut verstehen Oli, np ist zwar sehr mächtig und schnell, aber ich brauche da auch immer lange, bis ich überhaupt die richtigen Operatoren gefunden habe. Sobald ich die habe, finde ich die Docs aber ok / vollständig. Manche Operatoren finde ich nicht gut erklärt, aber das kann auch damit zusammenhängen, dass die kompliziert sind. Ersteres vermute ich liegt irgendwo an mir, weil ich mathematisch funktional illiterat bin und dann noch weniger die englischen Begriffe kenne.
Und dann, ja, natürlich, pure vektorielle Notation ist eine ganz andere Art Algorithmen zu notieren als iterativ/sequentiell.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.02.2017 13:11]
|
|
|
|
|
|
| Zitat von B0rG* Außerdem muss man mal ernsthaft darüber nachdenken, was man da eigentlich so programmiert .
| |
... was bei mir persönlich dazu führt, dass ich dann sicherheitshalber doch eine Schleife zum Testen schreibe.
Aber des Resultat ist in der Tat schöner.
|
|
|
|
|
|
|
Funktional illiterat. Sehr schön
|
|
|
|
|
|
|
Oh, numpy ist funktional? Dann bin ich wohl functional programmer.
|
|
|
|
|
|
|
Ich hätte mal ne Frage zu zmq und speziell zu pyzmq.
Ich habe hier ein Programm, dass per REQ/REP Schema mit einem Server kommuniziert. Jetzt soll der User die Möglichkeit haben, dem Programm zu sagen, unter welcher Adresse es sich mit dem Server verbinden soll und unter umständen sich auch mit einem anderen Server verbinden.
Ich frage mich jetzt, ob ich die gleiche Instanz von zmq.Socket() wieder verwenden sollte, i.e. die Verbindung mit zmq.Socket().disconnect() trennen und mit .connect() neu aufbauen soll, oder ob ich lieber eine neue Instanz von Socket() dafür hole?
|
|
|
|
|
|
|
Mir ist bisher in der Doku noch nichts begegnet, was dagegen spricht (außer vielleicht die Warnung, dass Sockets nicht thread-safe sind). So gefühlsmäßig würde ich trotzdem ein neues Objekt anlegen, einfach um sicher zu gehen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Danzelot am 13.02.2017 16:57]
|
|
|
|
|
|
Ich bastel mir da eigentlich immer eine Klasse, die irgendwo ein Socket hat, und Methoden, die die eigentlichen Req/Reps machen. __init__ kriegt die URL; URL ändert sich -> neue Instanz.
|
|
|
|
|
|
|
| Zitat von Oli
Meine Zelle sei l=10 lang. Wenn ich ein Atom bei x=1 und eins bei x=9 habe, dann ist die Distanz nicht 8 sondern 2.
Das meine ich mit periodischen Randbedingungen. Das gleiche in alle Richtungen. Die Zellenlänge in alle Richtungen sei bekannt.
/e: Aber mach dir nciht zu viel Arbeit. Ich sehe es ja wie du, habe nur im Moment nicht die Zeit, mir das zu erarbeiten. Die Skripte die ich schreibe sind immer nur so utility Gedöns, die nicht schnell und robust sein müssen, deshalb ist Priorität einfach der Programmieraufwand.
| |
Numpy ist Freude, nicht Arbeit \o/! Hatte leider heute Mittag nur keine Zeit mehr.
Du bist also auf der Suche nach der mittleren minimalen Distanz auf einem Torus. Angenommen die Koordinaten sind im Intervall zwischen Null und max_coords (ein Vektor mit so vielen Einträgen, wie es Raumdimensionen gibt), dann kannst du die nicht-ausmultiplizierte Variante sehr einfach anpassen:
|
Code: |
X = np.array(...) # Shape: (Anzahl Atome x Raumdimensionen)
max_coords = np.array(...) # Shape: (Raumdimensionen)
# Ohne ausmultiplizieren
deltas = np.abs(X[None, :] - X[:, None])
torus_deltas = np.minimum(deltas, max_coords - deltas)
squared_distances = np.square(torus_deltas).sum(axis=-1)
distances = np.sqrt(squared_distances)
np.fill_diagonal(distances, np.inf)
mean_shortest_distance = distances.min(axis=1).mean()
|
|
Ich sehe leider gerade nicht, wie man das elegant ausmultipliziert. Jemand eine Idee?
|
|
|
|
|
|
|
Danke, ich schaue es mir morgen mal an. Ab jetzt werde ich nicht mehr von periodischen Randbedingungen sondern n-dimensionalen torus (sen) sprechen, da freut sich meine Arbeitsgruppe.
|
|
|
|
|
|
|
Tori
|
|
|
|
|
|
|
bestimmt tori, außer es ist us-Deklination, dann ist es einfach torus ... Latein ist eine Trollsprache
e: Da lädt man einmal den Tab nicht neu, zack, zwischgepostet. Früher hätt's das nicht gegeben.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.02.2017 19:42]
|
|
|
|
|
|
Keine lust gehabt, das aufm Smartphone nachzuschauen.
Torussen finde ich witziger.
|
|
|
|
|
|
|
|
|
|
|
u-Deklination beste Deklination, da hat man mit dem Nominativ Singular direkt drei andere Fälle abgedeckt.
|
|
|
|
|
|
|
| Zitat von Oli
Danke, ich schaue es mir morgen mal an. Ab jetzt werde ich nicht mehr von periodischen Randbedingungen sondern n-dimensionalen torus (sen) sprechen, da freut sich meine Arbeitsgruppe.
| |
Als Belohnung bekommst du noch einen Codeschnipsel und Pandas-Teaser. Angenommen deine Daten sehen so aus in atoms.csv :
|
Code: |
name,x,y,z
Klaus,1.5,2,3
Peter,2,7.3,12
Günter,4,2,0.7
|
|
Dann geht das hier:
|
Code: |
import numpy as np
import pandas as pd
def nearest_neighbour_torus(X, max_coords):
deltas = np.abs(X[None, :] - X[:, None])
torus_deltas = np.minimum(deltas, max_coords - deltas)
squared_distances = np.square(torus_deltas).sum(axis=-1)
np.fill_diagonal(squared_distances, np.inf)
return np.sqrt(squared_distances.min(-1))
atoms = pd.read_csv('atoms.csv', index_col='name')
max_coords = np.array([10, 12, 17])
atoms['distance'] = nearest_neighbour_torus(atoms.values, max_coords)
print(atoms)
print("mean distance:", atoms.distance.mean())
|
|
Gibt dann aus:
|
Code: |
x y z distance
name
Klaus 1.5 2.0 3.0 3.397058
Peter 2.0 7.3 12.0 8.036168
Günter 4.0 2.0 0.7 3.397058
mean distance: 4.943427780576996
|
|
Das tolle daran: Der Code funktioniert auch noch, wenn du beschließt dich mit 17 Raumdimensionen zu beschäftigen. Kannst du das über deine Physik auch sagen?!
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von B0rG* am 13.02.2017 20:01]
|
|
|
|
|
|
Dinge, die ich heute gelernt habe:
|
Code: |
In [8]: np.newaxis is None
Out[8]: True
|
|
|
|
|
|
|
|
|
Pandas ist wirklich der geilste Scheiß. R Funktionalität ohne sich mit scheißendreck R rumärgern zu müssen.. <3
Vermutlich meine Top 3: read_csv, resample und groupby. Was hab ich mir mit Matlab damals immer einen abgebrochen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von nobody am 13.02.2017 20:12]
|
|
|
|
|
|
Google Calendar weißt mich heute stolz darauf hin, dass es 2^2.2^3.2^4 sei. Versteh ich leider nicht, halp plx?
|
|
|
|
|
|
|
Pandas muss ich mir auch mal ansehen,wie es scheint.
|
|
|
|
|
|
|
Hier ging es doch vorhin um ZMQ, erzählt mir mal wie ich das hier am Schönsten löse. Ich habe folgenden Pseudocode (eigentlich C++):
|
Code: |
void communication_thread() {
socket.connect(address);
while(running) {
// incoming messages
poll(socket, wait=100ms);
if (socket.has_message_waiting) {
message = socket.receive();
if (message.command == DO_STUFF) {
for (listener in listeners) {
listener.notify(message.data);
}
}
}
// outgoing messages
while (to_send = message_queue.pop()) {
socket.send(to_send);
}
}
socket.close();
}
|
|
Grob gesagt: Ich habe einen Socket auf dem Nachrichten empfangen und gesendet werden können. Der ist nicht thread-safe, deshalb läuft er in einem eigenen Thread, und holt seine zu sendenden Daten aus einer thread-safe Queue. Der Socket wird auf neue Nachrichten geprüft, die Funktion wartet maximal 100 ms. Wenn eine Nachricht reinkommt, werden Listener informiert, dass Daten reingekommen sind. Danach wird die Sende-Queue geleert und verschickt.
Erstens: Ist das überhaupt das optimale Pattern in meinem Fall? Oder habe ich eine Möglichkeit übersehen, um innerhalb eines Threads einen ZMQ-Socket lesend und schreibend zu verwenden? Für ZMQ-Erfahrene: Ich habe hier das ROUTER-DEALER-Pattern implementiert. Für den Rest: Ein asynchrones Request-Reply-Pattern.
b) Problem ist jetzt dass das eine öffentliche API wird, und ich keine Kontrolle darüber habe was die Nutzer für einen Mist in ihren Listenern implementieren. Wenn einer von denen jetzt besonders lange braucht um die Daten zu verarbeiten, hängt in der Zeit die gesamte Kommunikation. Wie kann ich verhindern, dass ein Listener da alles blockiert? Kann ich irgendwie garantieren dass die Listener so angestupst werden, dass der Programmfluss bei mir direkt weitergeht?
Ein weiteres Queue-Objekt öffentlich zur Verfügung stellen geht aus Gründen nicht. Eine Eingangsqueue einrichten löst das Problem nicht. Für jedes einkommende Paket einen Thread erstellen, der die Listener benachrichtigt, ist bei bis zu 100 Paketen pro Sekunde auch echt nicht praktikabel. Sonstige Ideen?
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Danzelot am 15.02.2017 15:28]
|
|
|
|
|
|
| Wie kann ich verhindern, dass ein Listener da alles blockiert? Kann ich irgendwie garantieren dass die Listener so angestupst werden, dass der Programmfluss bei mir direkt weitergeht?
Ein weiteres Queue-Objekt öffentlich zur Verfügung stellen geht aus Gründen nicht. Eine Eingangsqueue einrichten löst das Problem nicht. Für jedes einkommende Paket einen Thread erstellen, der die Listener benachrichtigt, ist bei bis zu 100 Paketen pro Sekunde auch echt nicht praktikabel. Sonstige Ideen? | |
Separater Thread für die Listeners mit PUSH sockets (also Pipeline) und inproc://, damit würdest du Latenzbubbelz vermeiden, aber hättest immernoch Probleme, wenn die Listener im Durchschnitt langsamer als die eingehende Requestrate sind. In dem Fall würde ich einen Timeout aufs Senden setzten in deinem communication_thread und bei einem Timeout dort (weil das Socket ins Blockieren gegangen ist, da Queue voll) einen weiteren Listener-Prozessierungs-Thread starten.
Was du sonst noch machen kannst, und auch in Richtung von Problem 1.) geht, wäre zwei separate Threads zu haben, der eine macht das mit den Listenern, der andere tut die Queue in eine PUSH socket. Dein communication thread würde dann auf alle drei Sockets pollen und nur noch Nachrichten dispatchen.
// Threads sind billig, da kann man ruhig genug an die Wand werfen
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 15.02.2017 15:45]
|
|
|
|
|
|
Joah, PUSH-PULL wäre ein Alternativmuster, dann würde zumindest mal ein langsamer Listener nicht das Versenden blockieren. Eigentlich möchte ich es aber vermeiden, noch einen Socket mehr aufzumachen.
inproc:// klappt aber nicht, die beiden Gegenstellen sind nicht notwendigerweise auf dem gleichen Gerät. Damit scheitert, wenn ich das richtig sehe, auch die Idee bei Bedarf einen neuen Thread zu eröffnen.
Im Moment tendiere ich einfach dazu, in die SDK-Spezifikation ein "macht euren Listenern gefälligst Feuer unterm Hintern" zu schreiben.
|
|
|
|
|
|
|
Nein, ich meinte eher, dass du mit einem separaten Listener-Abhandlungs-Thread über PUSH/PULL kommunizierst; das würde nur die Implementierung von communication_thread ändern, nicht dessen Router/Dealer-Interface.
|
|
|
|
|
|
|
Ach so. Das klingt tatsächlich recht elegant. Die Möglichkeit schaue ich mir mal genauer an, danke.
|
|
|
|
|
|
|
|
|
|
|
Cool!
Mehr Standardmodellbestätigungen. Kommt auch mal was spannendes?
Hast du entdeckt, dass Frauenbeine keine Tischbeine sind? Na bravo!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Der Autor hat natürlich im wesentlichen Recht. Wie bei allen Dingen, die von Marketing aufgeblasen werden, hat nach meinem Empfinden auch das Silicon Valley "in der Szene" (in meinem Fall studierte Informatiker) einen nicht so guten Ruf, wie im Rest der Gesellschaft.
|
|
|
|
|
|
Thema: pOT-lnformatik, Mathematik, Physik XX ( Der XX(X)-Thread. ) |