|
|
|
|
|
|
|
Altes deutsches Maschinenbau-Unternehmen wo Quellcode für die Industriesteuerungen häufig von 50-60 Jahre alten ehemaligen Elektrikern kommt; ja da ist das normal. 
Im Regelfall endet das so in 30% englisch und 70% deutschem Quellcode oder für manche Projekte sogar umschaltbar in diverse Sprachen und wird vom Übersetzungsbüro gepflegt, wenn man es ernst meint. Das braucht man aber normalerweise nur, wenn der Kunde die SW mitkauft, dann muss ich die Kommentare halt auch schonmal auf finnisch mit ausliefern.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von MCignaz
| | Zitat von wuSel
Zur Diskussion über Quellcode-Kommentare letztens:
// Bausteinende
Ja du Otto, ich seh das, das ist nämlich die letzte Zeile. 
| |
Deutsch in Source-Code und Kommentaren. Kenn ich aus meiner hippen Berlin-Bubble nicht - kommt das häufig vor?
| |
Nicht gesehen in:
Uni Heidelberg
USA (lol)
Gesehen in:
Bosch
Ist nocht mein Ding, so vong Stil her.
|
|
|
|
|
|
|
|
|
|
|
Der kopierte Kommentar ist von Bosch... 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von krischan111
| | Zitat von derSenner
Hat hier jemand Erfahrung mit so USB-Dongle-Dingern auf denen man Software ausliefert?
Also weniger auf der technischen Seite, vielmehr was sowas kostet. Irgendwie finde ich da kaum was auf Google, vielleicht fehlen mir die richtigen Keywords.
| |
http://codemeter.de
Das ist eins der bekanntesten Systeme. Preise sind gleich auf der Startseite aufgeführt. Laut Homepage kompatibel zu Windows, Linux und macOS.
Konkurrent:
https://sentinel.gemalto.com/software-monetization/software-protection/
Sentinel HL Hardware Keys (früher bekannt als Aladdin).
| |
Danke! Sehe ich das richtig, dass da ein so ein Teil 40¤ kostet? Das ist ja irre.
Habe mir seit einigen Jahren auch angewohnt, immer Englisch zu kommentieren und zu beschreiben. Macht einfach auf lange Zeit gesehen mehr Sinn.
Ich hab auch schonmal gesehen:
| |
| Code: |
// Wenn
if {
[..]
}
// Sonst
else {
[..]
} |
|
War aber nur privat, kein Industrieprojekt oder so.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 16.09.2016 13:00]
|
|
|
|
|
|
|
|
|
Wo doch jeder weiß, dass es falls heißen sollte  .
|
|
|
|
|
|
|
|
|
|
Nein, jeder weiß doch, dass falls = when und dann = do.
e/ Und Nicht-Englisch in Kommentaren geht ja mal gar nicht. Nicht nur wegen der Einheitlichkeit. Ich hab auch schon Italienisch, Spanisch, Japanisch und Russisch in Bibliotheken/Frameworks erlebt. Warum packt man das denn überhaupt auf GitHub, wenn es 99% der Leute nicht nutzen können?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Skgoa am 16.09.2016 13:22]
|
|
|
|
|
|
|
|
|
| | Zitat von wuSel
Der kopierte Kommentar ist von Bosch...
| |
inb4 wusel wird von Bosch zerklagt wegen NDA-Bruch
|
|
|
|
|
|
|
|
|
|
|
|
Ja, ist aus so einem komischen Steuergerät ... da stand noch irgendwas von "Abgas" und "Volkswagen". Keine Ahnung was das soll.
|
|
|
|
|
|
|
|
|
|
|
Ist schon ne Weile her und so richtig tief drin war ich auch nie aber vllt hilft es ja.
Im thermischen Gleichgewicht sind ein paar Spins mehr im up-Zustand als im down-Zustand und daher gibts eine Magnetisierung in z-Richtung.
Alle Spins präzedieren um z aber mit unterschiedlicher Phasenlage, so dass die Magnetisierung in xy gleich 0 ist.
Nun kommt mein Wechselfeld parallel zur xy-Ebene. Die Kreisfrequenz dieses Feldes entspricht der Präsessionsfrquenz der Spins.
-> Spins klappen um und schwingen in phase mit dem Wechselfeld.
Mein Wechselfeld bleibt genau so lange aktiv bis die Anzahl der Spins im up-Zustand gleich der Anzahl im down-Zustand ist.
Die Magnetisierung in z-Richtung verschwindet und die Spins schwingen alle in Phase.
Wir haben nun eine MAgnetisierung die in der xy Eben rotiert. (Magnetisierung von der z-Richtung um 90° in xy-Ebene klappen -> 90° Impuls)
Die Spins klappen zurück und verlieren ihre gemeinsame Phasenlage. -> die in der xy-Ebene rotierende Quermagnetisierung nimmt ab.
Das passiert durch spin-spin Wechselwirkung (langsames Abklingen) und durch die Inhomogenität des Gewebes die unterschiedliche Präzessionsgeschwindigkeiten verursacht (sehr schnelles Abklingen).
Will ich jetzt das langsam abklingende Signal messen ändere ich die momentane Phasenlage mit einem 180° Impuls.
Das sorgt dafür dass die Spins nochmal ind Phase schwingen und ich das langsam abklingende Singal (T2) messen kann.
Bisschen wirr? 
|
|
|
|
|
|
|
|
|
|
|
Das hilft auch beim Verständnis, auch wenn RS gerade noch abgestritten hat dass das Wechselfeld die Spins in Phase bringt
Danke euch beiden auf jeden Fall, ich werde meinen aktuellen Wissensstand jetzt für ausreichend halten. Eigentlich muss ich ja sowieso viel mehr wissen wie und warum am Ende auf dem Computer ein Bild ankommt, aber sowas kann ich nicht ohne halbwegs Verständnis von den Effekten dahinter.
|
|
|
|
|
|
|
|
|
|
|
na dann viel spass.
Das war was mit ner inversen Fourier Transformation oder so, ne?
|
|
|
|
|
|
|
|
|
|
|
Ja, ziemlich lustiges System wie die in jeder Raumdimension zur richtigen Zeit die richtigen Hochfrequenzfelder und Magnetfeldgradienten anlegen und dann auf einmal die Fouriertransformierte vom Bild der Protonenmenge im Körper in der Antenne haben. Solche Tricks zu lernen und verstehen macht auch ehrlich gesagt etwas mehr Spaß als mich jetzt damit zu beschäftigen warum ein 180°-Puls möglich ist.
|
|
|
|
|
|
|
|
|
|
|
Ich brauche mal programmierkonzeptionelle Hilfe.
Ich versuche, mein Programm hybrid zu parallelisieren: Auf N Rechnern wird ein MPI Prozess gestartet, jeder davon parallelisiert intern mittels eines Thread Pools aus M threads.
Es gibt Arbeitspakete, die sich alle MPI Prozesse bei Prozess#0 "abholen", parallel mit ihren M threads berechnen und dann wieder bei #0 abliefern.
#0 wartet einfach darauf, dass ein Paket ankommt, verarbeitet die Daten und schickt ein neues Paket raus. So in der Art:
#0
| |
| Code: |
while(true) {
mpi::status incoming = _mpi_handler->getWorld().recv(mpi::any_source, MpiHandler::MPI_RESULT, pixel_results);
// tu irgendwas mit pixel_results
_mpi_handler->getWorld().send(incoming.source(), MpiHandler::MPI_WORK, to_distribute.back());
to_distribute.pop_back();
} |
|
Soweit so gut. Jetzt ist es aber so, dass mein Master, also Prozess#0, auch M threads zur Verfügung hat. Ich würde M-1 davon gerne nutzen, um auch ein Pakete zu berechnen. Um nicht festlegen zu müssen, welche und wie viele, würde ich gerne das gleiche pattern wie oben anwenden: Die M-1 Threads holen sich ein Paket ab, berechnen es, bekommen ein neues Paket und so weiter.
Das Problem ist, ich weiß nicht, wie ich in meiner Warte-Schleife oben auf Ergebnisse aus unterschiedlichen Channels warten kann. Die thread basierte Variante arbeitet mit std::future.
Gibt es da eine Standard Vorgehensweise?
|
|
|
|
|
|
|
|
|
|
|
|
Warum nicht einfach einen separaten Prozess auf dem Knoten starten und sich das special-casing sparen?
|
|
|
|
|
|
|
|
|
|
|
Weil ich gerne shared memory nutzen würde, weil doch teilweise recht viel Speicher benötigt wird. MPI ist (soweit ich weiß) immer distributed memory, jeder Prozess auf einem Knoten braucht also die gleiche Menge. Außerdem will ich die MPI Kommunikation minimieren, weil es 1. nicht so wahnsinnig schnell ist übers Netzwerk und 2. bei unserem Cluster manchmal Probleme mit limitierten MPI Networking contexts gibt.
/e: Es gibt die MPI funktionen auch als non-blocking, ebenso wie man von std::future den Status überprüfen kann. Ich _kann_ also endlos loopen und jedesmal prüfen, ob eine MPI Nachricht da ist und/oder die futures fertig sind. Ein bisschen fugly ist das aber schon.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 16.09.2016 17:07]
|
|
|
|
|
|
|
|
|
Würdet ihr eine undefinierte Gaußklammer [x] immer als floor(x) lesen?
Schwedischer Autor, meiner Meinung nach sollte das Resultat einfach an .5 gerundet werden. :/
|
|
|
|
|
|
|
|
|
|
|
|
Ich kenne Gaußklammern hauptsächlich mit nur einem "Eck", dann ist das entweder floor oder ceil. Ich würde wohl sagen wenn es einfache eckige Klammern sind, würde ich von floor ausgehen, weil das irgendwie die natürlichere Operation ist.
|
|
|
|
|
|
|
|
|
|
|
Ich kenne [x] als größte ganze Zahl, die kleinergleich x ist -> floor. Die Varianten mit nur einer Ecke würde ich nur verwenden, wenn ich beide Varianten benötige.
inb4 zur Null hin runden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von MCignaz
Deutsch in Source-Code und Kommentaren. Kenn ich aus meiner hippen Berlin-Bubble nicht - kommt das häufig vor?
| |
Leider. Ist aber nicht so schlimm wie auskommentierter Quellcode.
"Ja, das habe ich damals geändert, aber vielleicht braucht man das nochmal."
Die Versionsverwaltung haben wir nur als Zierde, oder was?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Ich kenne Gaußklammern hauptsächlich mit nur einem "Eck", dann ist das entweder floor oder ceil. Ich würde wohl sagen wenn es einfache eckige Klammern sind, würde ich von floor ausgehen, weil das irgendwie die natürlichere Operation ist.
| |
Dito, bzw. ich weiß zwar, was die Original-Gaußklammer bedeutet, sehe aber keinen Grund, sie der eindeutigeren Notation vorzuziehen.
Also um Irdoraths Frage zu beantworten: ja, würde ich als floor(x) lesen, halte ich aber nicht für die eleganteste Notation (da ja offensichtlich nicht für jeden eindeutig).
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von nobody am 16.09.2016 20:43]
|
|
|
|
|
|
|
|
|
|
Ok, dann muss ich wohl oder übel an meinem Verständnis feilen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Weil ich gerne shared memory nutzen würde, weil doch teilweise recht viel Speicher benötigt wird. MPI ist (soweit ich weiß) immer distributed memory, jeder Prozess auf einem Knoten braucht also die gleiche Menge. Außerdem will ich die MPI Kommunikation minimieren, weil es 1. nicht so wahnsinnig schnell ist übers Netzwerk und 2. bei unserem Cluster manchmal Probleme mit limitierten MPI Networking contexts gibt.
/e: Es gibt die MPI funktionen auch als non-blocking, ebenso wie man von std::future den Status überprüfen kann. Ich _kann_ also endlos loopen und jedesmal prüfen, ob eine MPI Nachricht da ist und/oder die futures fertig sind. Ein bisschen fugly ist das aber schon.
| |
Die Threads auf dem #0 Node können ja nach dem Berechnen ihres Paketes selbständig "irgendwas mit den Pixeln" machen und sich auch ein neues Paket holen. Musst einfach schauen, dass du Threadsafe auf gemeinsame Datenstrukturen zugreifst.
Bei den anderen Prozessen wartest du einfach bis alle Threads mit ihren Aufgaben fertig sind und schickst dann die Daten zurück? Könntest du auch parallel machen; ein Thread der arbeitet und Daten zurück sendet, wenn vorhanden. Z.B. könntest du eine threadsafe queue verwenden, die vom Mainthread regelmässig gecheckt wird und dann etwas gesendet wird (async).
Macht das Sinn?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von _Ac_
Die Threads auf dem #0 Node können ja nach dem Berechnen ihres Paketes selbständig "irgendwas mit den Pixeln" machen und sich auch ein neues Paket holen. Musst einfach schauen, dass du Threadsafe auf gemeinsame Datenstrukturen zugreifst.
Bei den anderen Prozessen wartest du einfach bis alle Threads mit ihren Aufgaben fertig sind und schickst dann die Daten zurück? Könntest du auch parallel machen; ein Thread der arbeitet und Daten zurück sendet, wenn vorhanden. Z.B. könntest du eine threadsafe queue verwenden, die vom Mainthread regelmässig gecheckt wird und dann etwas gesendet wird (async).
Macht das Sinn?
| |
Die anderen Prozesse sind soweit kein Problem, die berechnen ihre Aufgaben parallel und schicken dann zurück, was vom #0 per mpi::recv empfangen und verarbeitet wird. Nur die Threads auf #0 sind das Problem. Ich kann natürlich ein paar Rechnungen anwerfen bevor ich in die mpi send/receive loop gehe, aber ich bräuchte sozusagen eine zweite event loop für die Threads. "irgendwas mit den Pixeln" ist eigentlich nur I/O, das sollte also lediglich vom main thread (bzw. seriell) von statten gehen.
Ich schaue morgen mal, ob ich eine Art proof of concept hinkriege.
|
|
|
|
|
|
|
|
|
|
|
Es läuft. Habe es in etwa so gemacht, wie _Ac_ es vorgeschlagen hat. Glaube ich.
Vor lauter atomics, mutex, guards qualmt mir der Kopf. Aber irgendwie hat man das Gefühl, auf hohem Niveau zu programmieren.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sowas?
Aber merke: Formalsprache hat ihre Einsatzbereiche. Im Zweifel lieber mehr Worte, weniger Zeichen, wenn der Text für andere ist. Siehe dazu auch Halmos - How to write mathematics.
Hey, you do your experiments - I do mine!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 18.09.2016 13:43]
|
|
|
|
|
|
|
|
|
![TeX: a \neq b \forall a \in [x,y], b \in [r,s], a \neq 0, b \neq 0](http://chart.apis.google.com/chart?chco=FFFFFF&chf=bg,s,00000000&cht=tx&chl=a+%5Cneq+b+%5Cforall+a+%5Cin+%5Bx%2Cy%5D%2C+b+%5Cin+%5Br%2Cs%5D%2C+a+%5Cneq+0%2C+b+%5Cneq+0)
Vielleicht noch in Kombination mit  als logisches "and".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Streng genommen gehören Quantoren vor die Aussagen...
Und deins funktioniert nur für geschlossene Intervalle. Und b muss bei dir immer null sein, genau wie a.
...kein Mensch kann sie wissen, kein Jäger erschießen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von DarkFritz
Ja, genau so eine Darstellung wollte ich eigentlich vermeiden. Dann werd ich es wohl bei der Beschreibung belassen.
| |
So wie du es formulierst, ist aber auch gerade unklar, was du mit "außer 0" meinst.
Your ass looks fat in that skirt. I mean, yes ma'am.
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XX ( Der XX(X)-Thread. ) |
