|
|
|
|
Dann könnte das hier funktionieren, wenn du dich auf die Ordnung verlassen kannst:
df.columns = pd.MultiIndex.from_product((df.columns.unique(), ['demand', 'price']))
|
|
|
|
|
|
|
|
|
|
|
Funktioniert bei jemandem auf swagger.io die Server-Generierung? Client-Generation funktioniert, Server aber irgendwie nicht.
/Ok, wenn ich auf den alten Editor wechsle, geht es.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von MCignaz am 20.09.2017 14:28]
|
|
|
|
|
|
Also scalebox funktioniert natürlich, im worst case mache ich das ganze händisch bzw baue ein Makro.
Die elegante Lösung vermute ich hinter \DeclareMathSizes{text}{math text}{script}{scriptscript}.
Das Problem ist jetzt, dass die 2 in 0^\frac{1}{a_2}, schon drei Script-Ebenen tief liegt: superscript, fraction, subscript. Jetzt sagt das TeXBook leider "There is no “SSS” style or “scriptscriptscript” size; such tiny symbols would be even less readable than the scriptscript ones."
Bleibt also wohl beim worst case.
Achja, funfact: \documentclass[11pt] fängt man mit \DeclareMathSizes{10.95} ab...
|
|
|
|
|
|
|
Kannst du's nicht vielleicht so umformulieren, dass der komplizierte Term nicht im Exponenten steht? Ich denke das "es ist nicht mehr schön zu lesen"-Argument ist schon nicht zu vernachlässigen.
fände ich glaube ich immernoch schöner - aber vielleicht kann man auch eine für die Anwendung passendere Formulierung finden?
|
|
|
|
|
|
|
Eine passendere Formulierung fällt mir keine ein, an sich taucht die Formel nur einmal ganz zum Schluss einer längeren Beweiskette auf. Die Parameter werden für andere Zwecke sinnvoll benannt, in diesem einen konkreten Fall kennt man dann allerdings eine (obige) geschlossene Form, die dann bestimmte benötigte analytische Eigenschaften mitbringt bzw diese leicht berechenbar macht.
Mal auf Papier anschauen, auf dem Monitor finde ich das mit einer Scalebox sehr gut leserlich, frac mit einem von drei möglichen Indizes (1,2,plusminus) ist platzmäßig dann doch noch was anderes als dreimal hochstellen.
Wenns auf Papier eng wirkt, nehme ich aber wohl deine Lösung, also (x/y)^Platzhalter.
e: tatsächlich gefällt mir gerade ein Vergrößern des restlichen Exponenten ziemlich gut, \frac yx lässt so schön viel Platz. Mal in ein Paar Tagen nochmal drauf gucken, ob ich den übergroßen Exponenten dann noch ertrage.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Irdorath am 21.09.2017 13:12]
|
|
|
|
|
|
Ggf keine Lösung, wegen externer Vorgaben... Kannst du noch auf LuaLaTeX oder sowas wechseln, wo du mehr Zugriff auf Schriftgrößen haben dürftest...?
|
|
|
|
|
|
|
|
|
|
|
Ob du seine Posts wohl gelesen hast...?
|
|
|
|
|
|
|
Die in diesem Thread? Ja. Im Latexthread? Bisher nicht.
|
|
|
|
|
|
|
Ich mache jetzt ja Dichtefunktionaltheorie. Man verwendet irgendeine Black Box von Code, alles hängt vom Funktional ab, PseudoPP und Full-electron spucken unterschiedliche Dinge aus, die Atompositionen sind wichtig, die ausgerechneten Bandlücken falsch, etc.
Aber egal, man rechnet halt irgendwas aus und wenn es in der richtigen Größenordnung ist wirds halt veröffentlicht. So müssen sich Experimentalphysiker fühlen.
|
|
|
|
|
|
|
| Zitat von Oli
So müssen sich Experimentalphysiker fühlen. | |
Fick dich mal 3 ± 0.8m hinfort!
|
|
|
|
|
|
|
2 vs. 3 Detektoren:
Yes Boo, I agree. This group could do with a swift kick in the morals.
|
|
|
|
|
|
|
| Zitat von Oli
So müssen sich Experimentalphysiker fühlen.
| |
Süßer diss, aber immer wenn ich Theorie, insb. Computer-Theorie machen muss, bin ich immer super unsicher nicht irgendwo doch nen Fehler drin zu haben. Da fühl ich mich beim Experiment sicherer, da ist alles fair game.
|
|
|
|
|
|
|
Eben. Deshalb mein rant über DFT.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 28.09.2017 14:04]
|
|
|
|
|
|
https://mathwithbaddrawings.com/2017/09/20/the-state-of-being-stuck/
Offene Türen und so, ich weiß, aber trotzdem eine gute Lektüre. Und ich brauche das irgendwie täglich, sonst gebe ich doch irgendwann auf.
Gerade, weil ich mich momentan endlich an meine Kobayashi Maru, algebraische Quantenfeldtheorie, wage.
Kanonische Transformationen sind Symplektomorphismen im Phasenraum.
|
|
|
|
|
|
|
Hallo, ich bin mir gar nicht sicher, ob das der beste Thread dafür ist, aber ich habe eine Frage zu Android und Java.
Ich bin in beidem ziemlicher n4p und habe trotzdem vor, eine kleine App zu schreiben, die mir eine Aufgabe erleichtert und so, wie ich mir das vorstelle, nicht im Play Store zu haben ist.
Hauptfunktionalität ist es kontinuierlich drei (möglicherweise voneinander abweichende) Uhrzeiten auf die Sekunde genau anzuzeigen:
- Die Systemzeit von Android
- Eine über einen NTP-Server synchronisierte Zeit
- Zeit vom GPS-Signal
Das sollte ja nun nicht zu schwierig sein und die ersten beiden laufen auch schon, um gps hab ich mich noch nicht gekümmert.
Die aktuelle Systemzeit bekomme ich aktuell dadurch, dass ich
aufrufe.
Implementiert sieht das ca. so aus:
|
Code: |
public View onCreateView(/* ... */) {
//...
tvClockSys = (TextView) view.findViewById(R.id.tv_Clock_Sys);
sdfSystime = new SimpleDateFormat("HH:mm:ss.SSS");
Handler hndSysTime = new Handler();
hndSysTime.postDelayed(updateSystemTime, 0);
return view;
}
public Runnable updateSystemTime = new Runnable() {
public void run() {
tvClockSys.setText(sdfSystime.format(new Date()));
hndSysTime.postDelayed(this, 0);
}
};
|
|
updateSystemTime wird also kontinuierlich ausgeführt, erstellt bei jedem Aufruf ein neues Date Objekt, formatiert die Zeitangabe mittels des SimpleDateFormat (sdfSystime.format) und setzt den String dann als Text für das TextView (tvClockSys.setText).
Das funktioniert im Endeffekt genau so, wie ich es will. Allerdings kann ich mir nicht vorstellen, dass das für den Speicher cool ist, wenn ich da x mal pro Sekunde ein neues Date Objekt erstelle. Ich mülle da doch im Endeffekt alles zu? Oder ist das völlig belanglos und Java / Android kümmert sich darum?
|
|
|
|
|
|
|
Java hat einen Garbage Collector
|
|
|
|
|
|
|
In der Regel wird das die Runtime ohne Probleme für dich handeln. Du könntest aber natürlich das auch irgendwie anders lösen (statisches Singleton, sonstiges statisches Objekt) und die Objekte dann nur einmal erstellen. Hier gilt aber wie immer die Regel: bemerkst du kein Problem, ist es kein Problem. Wenn du dem nicht traust: Benchmark. Und die Objekte werden ja so oder so vom GC gehandelt.
| Zitat von red
Java hat einen Garbage Collector
| |
Was einen ja nicht zwingend immer vor Problemen schützt. Bei solchen trivialen Sachen wird die jvm aber sogar erkennen, dass die gleichen Objekte immer wieder verwendet werden und den Speicherbereich wahrscheinlich sogar belassen und nur die dynamischen Daten neu schreiben.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 01.10.2017 17:46]
|
|
|
|
|
|
Dieser Moment, wenn man sich denkt, "Hey, von dem Forscher habe ich außer den zwei Papern fast nie was gehört..." und googlet. Er war einen Monat an einer Uni in Pyöngjang (mit evangelikalen Verbindungen), fünf Jahre an einer Uni in Kabul und jetzt an einer evangelikalen Uni in Kanada, dazwischen Maurer für Kamine. Ooooook... Ich glaube, ich kann die Religion raten!
Immerhin scheint man Optionen zu haben, wenn einem der normale Lebenslauf eines Akademikers langweilig wird.
The universal aptitude for ineptitude makes any human accomplishment an incredible miracle.
|
|
|
|
|
|
|
| Zitat von Joggl²
Hallo, ich bin mir gar nicht sicher, ob das der beste Thread dafür ist, aber ich habe eine Frage zu Android und Java.
Ich bin in beidem ziemlicher n4p und habe trotzdem vor, eine kleine App zu schreiben, die mir eine Aufgabe erleichtert und so, wie ich mir das vorstelle, nicht im Play Store zu haben ist.
Hauptfunktionalität ist es kontinuierlich drei (möglicherweise voneinander abweichende) Uhrzeiten auf die Sekunde genau anzuzeigen:
- Die Systemzeit von Android
- Eine über einen NTP-Server synchronisierte Zeit
- Zeit vom GPS-Signal
Das sollte ja nun nicht zu schwierig sein und die ersten beiden laufen auch schon, um gps hab ich mich noch nicht gekümmert.
Die aktuelle Systemzeit bekomme ich aktuell dadurch, dass ich
aufrufe.
Implementiert sieht das ca. so aus:
|
Code: |
public View onCreateView(/* ... */) {
//...
tvClockSys = (TextView) view.findViewById(R.id.tv_Clock_Sys);
sdfSystime = new SimpleDateFormat("HH:mm:ss.SSS");
Handler hndSysTime = new Handler();
hndSysTime.postDelayed(updateSystemTime, 0);
return view;
}
public Runnable updateSystemTime = new Runnable() {
public void run() {
tvClockSys.setText(sdfSystime.format(new Date()));
hndSysTime.postDelayed(this, 0);
}
};
|
|
updateSystemTime wird also kontinuierlich ausgeführt, erstellt bei jedem Aufruf ein neues Date Objekt, formatiert die Zeitangabe mittels des SimpleDateFormat (sdfSystime.format) und setzt den String dann als Text für das TextView (tvClockSys.setText).
Das funktioniert im Endeffekt genau so, wie ich es will. Allerdings kann ich mir nicht vorstellen, dass das für den Speicher cool ist, wenn ich da x mal pro Sekunde ein neues Date Objekt erstelle. Ich mülle da doch im Endeffekt alles zu? Oder ist das völlig belanglos und Java / Android kümmert sich darum?
| |
Das ist kein Problem. Wenn du dir sorgen machst, dass dein GC nicht aufräumt, dann weise das Date-Objekt keiner Variable zu. Der Standard-GC verhält sich so, dass ein Objekt ohne Referenz auf sich, als zu löschen markiert wird.
Calendar.getTime() macht übrigens auch nichts anderes.
|
Code: |
public final Date getTime() {
return new Date(getTimeInMillis());
}
|
|
|
|
|
|
|
|
|
|
|
|
|
Nice.
|
|
|
|
|
|
|
You need a reason to live! You don't need excuses to die!
|
|
|
|
|
|
|
Freue mich auch über den Chemienobelpreis für das Cryo-Elektronenmikroskop. Lustig, dass die Chemienobelpreise in den letzten Jahren oft näher an meiner Arbeit sind als die der Physik, aber arbeite nun ja auch in Chemical Physics/Physical Chemistry.
|
|
|
|
|
|
|
Bist du eigentlich schon promoviert? Wir suchen einen guten Postdoc fürs TEM.
|
|
|
|
|
|
|
Danke fürs Angebot, aber dauert noch mindestens 1,5 Jährchen
|
|
|
|
|
|
|
Moment, sollte ich ewiger Student etwa nicht der letzte Doktor im Thread sein?
Blow shit up, throw women through walls, got it.
|
|
|
|
|
|
|
Ich hab noch mindestens 2 Jahre (as if), eher 3. Aber du hast auch gut Vorsprung, bin jetzt schließlich auch erst ein Jahr dabei .
|
|
|
|
|
|
Zu Hülf!
|
Ha! Etwas, was nicht völlig abgefahren ist!
Meine Kollegin hat mich heute generdsniped: Angenommen, man hat eine Box voll Gas in einem homogenen Schwerefeld. Jetzt kann man relativ einfach den "Gleichgewichtszustand" für diese Box bekommen und erhält eine "höhen"abhängige Temperatur. Ihr Frage, sinngemäß: "Wie kann das ein thermisches Gleichgewicht sein?" Es ist offensichtlich ein dynamisches Gleichgewicht, aber das "thermisch" macht auch mir tatsächlich Kopfzerbrechen. Klar, jede infinitesimale Höhenschicht ist intern im thermischen Gleichgewicht, aber was würde es bedeuten, dass ein anderes, physikalisches System mit der ganzen Box im thermischen Gleichgewicht ist? Offensichtlich hat die Box ja keine einheitliche Temperatur... ...würde man dann über die Temperaturen mitteln? Schließlich ist die Definition von Temperatur ausgehend vom nullten Hauptsatz ja nur, dass es die eindeutig zuzuordnende Größe ist, die jeder Äquivalenzklasse bezüglich der Äquivalenzrelation "im thermischen Gleichgewicht mit" einen konkreten, individuellen Wert gibt. Ich komme in diesem Beispiel irgendwie arg in Bedrängnis, was jetzt "System" ist oder mit anderen, physikalischen Systemen (oder Subsystemen des ursprünglichen Böxchens) verglichen werden darf.
...halbwegs klar, was die (ansteckende) Verwirrung ist?
What a depressingly stupid machine.
|
|
|
|
|
|
Thema: pOT-lnformatik, Mathematik, Physik XXI ( X-Ray-Edition ) |