|
|
|
|
|
|
|
Wir sind uns da einig, ich glaube mein Post wurde einfach falsch verstanden. Ich hätte gerne mehr diskrete Mathe, Typentheorie , Sprachtheorie etc. gehabt. Gab es aber alles nur in Minidosierung, dafür die Riesenpackung Analysis. Hätte man bestimmt mit Wahlmodulen machen können, aber die Lust dazu kann man sich mit der gemachten Erfahrung ausmalen.
Man muss dazu auch sagen, dass das alles über ein Jahrzehnt her ist, und sich da laut Bekannten einiges getan hat im Grundstudium.
¤: Wäre halt auch der Motivation zuträglich, wenn man fachnähere Mathematik beibringen würde, gerne auch mit Anwendungen wie in der Physik.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 28.09.2020 12:31]
|
|
|
|
|
|
|
|
|
| | Zitat von Irdorath
| | Zitat von SwissBushIndian
Und wie ich schonml erwähnt habe, kam das was man wirklich wissen sollte (in meinem Beruf) sträflich zu kurz, dafür alles was ich in über 15 Jahren noch nie gebraucht habe in Hülle und Fülle.
| |
Ich weiss nicht, was und wo du studiert hast, aber ein Universitaetsstudiengang ist (mMn zurecht) keine Berufsvorbereitung, also ausser du willst Wissenschaftler werden.
| |
Jein. Man lernt zumindest nicht notwendigerweise hard skills, aber viele Konzepte sind natürlich auch im Beruf anwendbar. Niemand zahlt Akademikergehälter für Leute, die nichts mitbringen.
|
|
|
|
|
|
|
|
|
|
|
|
Ja natuerlich sind die Skills transferierbar, so funktioniert das System ja.
|
|
|
|
|
|
|
|
|
|
|
Und wenn man sich bei von FAANG bewerben will, kann man direkt nach dem ersten Semester (Algorithmen und Datenstrukturen) abbrechen. Das sind die hard skills, die man dafür braucht.
|
|
|
|
|
|
|
|
|
|
|
|
Traurigerweise ist das ziemlich wahr.
|
|
|
|
|
|
|
|
|
|
Wo wir gerade bei Computergedöhnse sind: Was passiert hier?
| |
| Code: |
lambda x: r"$10^{{{0:.3g}}}$".format(float(log10(x))) |
|
Ich verstehe, dass ich mir (mit numpy) den log10 von x ausrechne, in eine Python-Float umwandle; auf der anderen Seite bedeutet das r einen C(?)-artigen String, die Dollarzeichen brauche ich, damit mir das von Sage als LaTeX interpretiert wird - aber dann hapert es bei mir damit, wie ".format" in das 0:.3g eingreift (was ist das?) und warum ich die zwei inneren, geschweiften Klammern brauche.
Ich habe bisher immer mit printf-Syntax gespielt, also den Dollarzeichen.
Mildly related: Wie funktioniert eine wenn-dann-Sache in einer Lambda-Funktion in Python?
Speedy thing goes in, speedy thing comes out.
|
|
|
|
|
|
|
|
|
|
|
r bedeutet raw-String, d.h. dass keine Zeichen im String interpretiert werden, sondern dass er genommen wird, wie er ist.
| |
| Code: |
print("hi\nwos")
hi
wos
print(r"hi\nwos")
hi\nwos |
|
Bei {0:.3g} bezieht sich die 0 auf den ersten Eintrag im Format, .3g ist wie .3f (Rundung auf 3 Stellen) nur, dass nicht benötigte Nullen weggeschnitten werden
| |
| Code: |
"{:.5f}".format(0.020000)
'0.02000'
"{:.5g}".format(0.020000)
'0.02' |
|
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von homer is alive am 28.09.2020 15:18]
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
Mildly related: Wie funktioniert eine wenn-dann-Sache in einer Lambda-Funktion in Python?
| |
Die Syntax ist:
| |
| Code: |
lambda x: a if condition(x) else b |
|
und bedeutet:
| |
| Code: |
def function(x):
if condition(x):
return a
else:
return b |
|
Meinst du das? Das geht aber generell immer und hat nichts mit Lambda-Funktionen im Speziellen zu tun. Für kompliziertere Logiken bitte "def" verwenden.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von homer is alive am 28.09.2020 15:22]
|
|
|
|
|
|
|
|
|
Danke! D.h. die 0 in "{0:.5f}".format(0.020000) ist nur relevant, wenn man eine Liste im format-Argument drin hätte?
____
Dass ich die wenn-dann-Sache im Lambda haben will, liegt daran, dass innerhalb von contour_plot ich eher auf numpy-Geschichten stoße, außerhalb eher auf Sage. Ich habe jetzt schon die Antwort, die mir mein Problem lösen konnte, erst nutzen können, nachdem ich die diversen Typenkonflikte gelöst hatte... Also bleibt alles schön brav in meinem contour_plot... Ich muss nur eine einzelne 0 abfangen, das ist alles.
Being the only child of an evil corporate overlord has a few very distinct advantages.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
Danke! D.h. die 0 in "{0:.5f}".format(0.020000) ist nur relevant, wenn man eine Liste im format-Argument drin hätte?
| |
Oder wenn du dasselbe Argument mehrfach reinformatieren willst. Ich finde es aber als keyword argument schöner, nicht als positional argument.
"{0:.5f}_{0:.1f}_{1}".format(0.020000, 0.5)
bzw.
"{any_number:.5f}_{any_number:.1f}_{another_number}".format(any_number=0.020000, another_number=0.5)
Beides:
'0.02000_0.0_0.5'
| | | Dass ich die wenn-dann-Sache im Lambda haben will, liegt daran, dass innerhalb von contour_plot ich eher auf numpy-Geschichten stoße, außerhalb eher auf Sage. Ich habe jetzt schon die Antwort, die mir mein Problem lösen konnte, erst nutzen können, nachdem ich die diversen Typenkonflikte gelöst hatte... Also bleibt alles schön brav in meinem contour_plot... Ich muss nur eine einzelne 0 abfangen, das ist alles. | |
Keine Ahnung 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von homer is alive am 28.09.2020 15:33]
|
|
|
|
|
|
|
|
|
Cool, danke! 
May the force be with you!
|
|
|
|
|
|
|
|
|
|
|
|
Muss noch korrigieren (zumindest für Python 3.7/8, älter weiß ich nicht): .g evaluiert auf Precision n-1 (n ist die Zahl vor dem g, sprich die gewünschte Precision). Mit .f bekommt man die Precision n wie spezifiziert.
|
|
|
|
|
|
|
|
|
|
Damit es hier auch mal eine ernsthafte Antwort gibt:
| |
| Code: |
lambda x: r"$10^{{{0:.3g}}}$".format(float(log10(x))) |
|
Das ist natürlich eine Beobachtung aus dem neuen Lambda Komplex auf Xen. Es wurden 10 Baumstämme beobachtet, die da treiben. Der Rest sind die Koordinaten.
|
|
|
|
|
|
|
|
|
|
|
| |
Ich verstehe, dass ich mir (mit numpy) den log10 von x ausrechne, in eine Python-Float umwandle; auf der anderen Seite bedeutet das r einen C(?)-artigen String, die Dollarzeichen brauche ich, damit mir das von Sage als LaTeX interpretiert wird - aber dann hapert es bei mir damit, wie ".format" in das 0:.3g eingreift (was ist das?) und warum ich die zwei inneren, geschweiften Klammern brauche. | |
lambda x: r"$10^{{{0:.3g}}}$".format(float(log10(x)))
Das r ist hier schlicht überflüssig. r(aw)-strings in Python deaktivieren Escapes, d.h. "\n" ist ein String aus einem Zeilenumbruch, während r"\n" ein Backslash und ein n enthält.
lambda x: "$10^{{{0:.3g}}}$".format(float(log10(x)))
float(log10(x))
Die Umwandlung zu float ist vielleicht überflüssig, weil log10 wahrscheilich schon float zurückgeben wird. (Tut es das nicht, würde ich jetzt das einfach als schlechte API darstellen  ).
lambda x: "$10^{{{0:.3g}}}$".format(log10(x))
.format() benutzt einen String als Formatstring. In Formatstrings benutzt man {} um ein Argument darzustellen. Will man jetzt aber einfach nur ein { oder } als Teil der Ausgabe haben, schreibt man {{, was dann zu einem einzelnen { in der Ausgabe wird.
{{...}} heißt also, dass die ... in der Ausgabe von { und } umgeben werden.
"{0:.3g}".format(y)
{foo:bar}
foo gibt das Argument an. 0 heißt hier, dass nullte, also erste, Argument von format, also y.
Das ist hier auch überflüssig und könnte einfach als {:bar} geschrieben werden.
bar gibt an, wie das Argument formatiert werden soll. Das kann man hier nachlesen: https://docs.python.org/3/library/string.html#format-specification-mini-language
.3 ist die "precision", also Anzahl der Stellen hinterm Komma.
g sagt: "General format. For a given precision p >= 1, this rounds the number to p significant digits and then formats the result in either fixed-point format or in scientific notation, depending on its magnitude."
Ich würde ja behaupten, dass hier das normale "f" Format (dezimale Fließkommaausgabe) es auch tun würde, weil der Zehner-Logarithmus ja meistens eher klein ist und daher nicht in den Genuss einer wissenschaftlichen Notation kommen wird. "f" ist zufälligerweise auch das Standardformat für Floats und kann daher weggelassen werden.
~> lambda x: "$10^{{{:.3}}}$".format(log10(x))
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 28.09.2020 18:06]
|
|
|
|
|
|
|
|
|
Danke! Aber: Fast - das g brauche ich, sonst bekomme ich 10^{22.0} oder, bei weniger Präzision, 10^{2.3e+01}. Mit dem g kann ich dann auch auf 2 Stellen Präzision runter.
Ticking away the moments that make up a dull day...
|
|
|
|
|
|
|
|
|
|
|
Java (Eclipse): Hat wer eine Idee woran es liegen könnte, wenn ein Programm ziemlich langsam Fortschritte macht (nach circa 1-2 Tagen und Durchführung vieler komplexer Rechnungen), aber dann wieder fix läuft, sobald man beim JProfiler das CPU Profiling startet? 
Wir haben scheinbar Probleme mit der GC, denn nach 2 oder 3 Tagen erhalten wir en "gc overhead limit exceeded". Heapsize erhöhen bringt nichts an der Stelle. 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Gepan.3dsvs.com am 29.09.2020 8:44]
|
|
|
|
|
|
|
|
|
Führt ihr das produktiv aus Eclipse heraus aus? Am besten noch im Debugmode? Aber mal so auf den ersten Blick klingt das nach fehlendem Dispose irgendwo, gepaart mit sehr vielen kleinen Objekten, die ihre Referenz nicht verlieren. Damit kann man sein Memory schön fragmentieren, und der GC rödelt viel und cleart quasi nichts.
Im Debugmode, und entfernter auch mit dem Profiler, verhalten sich Programme in der Regel anders als im normalen Ausführmodus, weil viel mehr reflection genutzt wird um Information zu sammeln. Das kann einerseits dazu führen, dass der GC effizienter ist, weil bessere Inspektion, oder aber es wird mehr CPU für die Reflection gebraucht wird und der GC unter die 98% Grenze fällt. Auf der anderen Seite kann es im Debugmode sein, dass gewisse Referenzen nicht freigegeben werden, obwohl sie zwar ausserhalb des Runtime, aber nicht ausserhalb des Debugscopes sind. Daher: nie Produktivläufe aus der IDE starten.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 29.09.2020 10:29]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also mein erster Gedanke wäre auch: nicht aus der IDE starten. Generell nichts aus der IDE starten, was nicht ein schneller Test einer spezifischen Funktionalität ist.
|
|
|
|
|
|
|
|
|
|
|
Lambacher Schweizer, Q3:
| | | Sie müssen im Stadtzentrum nach dem Weg fragen. Ihnen kommt eine Frau mit vollen Einkaufstaschen und eine mit Aktenmappe unter dem Arm entgegen. Begründen Sie anhand eines Zahlenbeispiels und mithilfe der Begriffe der Unabhängigkeit und der bedingten Wahrscheinlichkeit, warum Sie eher die Frau mit den Einkaufstaschen befragen. | |
Tja.
|
|
|
|
|
|
|
|
|
|
|
|
Wo ist das Problem? P(Wohnt da|Einkaeufe) ≥ P(Wohnt da|Aktentasche) und P(kennt sich aus|wohnt da)≥P(kennt sich aus|wohnt da nicht)
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
| | Zitat von Aminopeptid
Mathe ist wunderschön, wenn man nicht in der Kindheit damit so dermaßen traumatisiert wurde, dass man es für den Rest des Lebens nur noch mit der Kneifzange anfässt.
| |
Gratulation zum Abschluss! Spannend mit der Mathe, kannst du beschreiben was dich so traumatisiert hat? Und hätte die Lehre in der Hochschule irgendwas anders machen können, um dich doch noch abzuholen?
---
Spannende Frage! Ich glaube der Post erwähnt einige wichtige Argumente wie die Schwierigkeit zweiter Ableitungen, die Kosten diese auszurechnen und Detailprobleme vom Newtonverfahren. Ich würde hinzufügen:
- Unwissenheit: Viele Leute die ML machen haben keinen starken Mathe-Background und wissen schlicht wenig über mathematische Optimierung. Vielleicht haben sie also nie darüber nachgedacht, dass es etwas anderes als Gradient Descent überhaupt gibt.
- Good Enough: Gradient Descent ist vergleichsweise simpel und funktioniert meistens gut genug, warum also etwas anderes machen?
- Numerische Stabilität: In meiner Erfahrung sind Newtonverfahren viel schneller beleidigt wenn es um numiersche Stabilität geht. Wenn Newtonverfahren konvergieren sind sie super, tun sie aber oft nicht. Die Zeit die man braucht um mit dem Optimierer zu kämpfen kann man auch anders verwenden oftmals.
- Stochastische Optimierung: Ich weiß nicht, ob man Newtonverfahren erweitern kann für stochastische Optimierung (Mini-Batching zum Beispiel) und ob sie dann überhaupt noch irgendwelche Garantien liefern. Bei Gradient Descent geht das total einfach.
- Triviale Parallelisierbarkeit: Aus der stochastischen Optimierung folgt quasi direkt, dass man Gradient Descent trivial parallelisieren kann und zwar ohne irgendwelche Kommunikation zwischen Threads, von ab und an mal Ergebnisse austauschen abgesehen. Man kann Gradientenschritte ruhig bisschen zufällig, in falscher Reihenfolge oder nur recht grob machen und das klappt immernoch. Weiß nicht ob das bei Newton auch so ist.
- Man will gar nicht das Minimum finden: Ich kann mir gut vorstellen dass Newtonverfahren speziell bei Neuronalen Netzen auch zu gut sind. Dass der Optimierer schlecht optimiert ist da durchaus oftmals ein Feature (siehe: Early Stopping). Würde man das Minimum der Fehlerfunktion finden hätte man ein Modell von dem man im Prinzip eh schon weiß, dass es schlecht ist. Das ist zwar niederschmetternd aus theoretischer Sicht aber halt Realität.
Ich glaube wie oft im maschinellen Lernen könnte jemand der sich so wirklich mit Optimierung auskennt viele Probleme besser lösen als sie zur Zeit gelöst werden. Kann mir sehr lebhaft vorstellen, dass sich "echte" Optimierer die Haare raufen wenn sie sehen was Leute im ML so machen. So ist das bei interdisziplinären Aufgaben.
| |
Man kann auch einfach mehr Computerpower draufkloppen :O
https://twitter.com/Luke_Metz/status/1308951548979011585 (learned optimizers)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von R am 01.10.2020 10:57]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Xerxes-3.0
Lambacher Schweizer, Q3:
| | | Sie müssen im Stadtzentrum nach dem Weg fragen. Ihnen kommt eine Frau mit vollen Einkaufstaschen und eine mit Aktenmappe unter dem Arm entgegen. Begründen Sie anhand eines Zahlenbeispiels und mithilfe der Begriffe der Unabhängigkeit und der bedingten Wahrscheinlichkeit, warum Sie eher die Frau mit den Einkaufstaschen befragen. | |
Tja.
| |
Ich habe das "mit" überlesen: "Ihnen kommt [...] Aktenmappe [...] entgegen."
Natürlich frage ich die Frau, nicht die Aktenmappe.
|
|
|
|
|
|
|
|
|
|
|
Related: Was macht JAX (autodiff) so viel schneller als pytorch?
|
|
|
|
|
|
|
|
|
|
|
Hier kann nicht zufällig jemand höheres Mathematica-Plot-Voodoo? Falls doch: Heeeeeeelp...
Commander, set a new course. There's coffee in that nebula.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 02.10.2020 10:01]
|
|
|
|
|
|
|
|
|
| | Zitat von R
Related: Was macht JAX (autodiff) so viel schneller als pytorch?
| |
Ich habe es nicht getestet, aber es scheint ja nicht wirklich unbedingt schneller zu sein als PyTorch:
| | Back in the day I switched from TF to PyTorch precisely because it offered more control and let you rearrange the internals of a network to a greater degree with a simple intuitive pythonic design. Jax seems to take this a step further? But what is the catch? What can I do that would be inconvenient or impossible with PyTorch?
> It has faster higher-order gradients, is built on top of XLA, which can be faster or have some other advantages in the future, has other interesting transformations (vmap for vectorization, pmap for parallelization) and has better TPU support (and probably always will as it's from Google and may even manage to become Google's main Scientific Computing/NN library in the future) | |
https://www.reddit.com/r/MachineLearning/comments/f5k6kv/d_a_first_look_at_jax/
|
|
|
|
|
|
|
|
|
|
|
Was ist hier eigentlich die Meinung zu... ...halblogarithmischen Graphen?
Ich habe da jetzt einen, mit dem ich halb(logarithmisch) glücklich bin, aber eigentlich ist er mir zu überladen. Wenn ich aber Mathematica frei walten lasse, sind nur bei jeder zweiten Zehnerpotenz Hilfslinien und das ganze sieht, von den Hilfslinien her, aus wie ein linearer Plot. Die Hilfslinien zwischen Zehnerpotenzen lassen das ganze zwar fürchterlich dicht und überladen aussehen, aber man weiß sofort "Hey, logarithmisch!" und kann auch Werte um Welten besser ablesen. Wahrscheinlich könnte ich auf die Hilfslinien verzichten und nur die Ticks sichtbar machen, aber das macht bei der geringen Zahl Hilfslinien das Ablesen nicht sehr einfach.
Meinungen?
You need a reason to live! You don't need excuses to die!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 03.10.2020 12:37]
|
|
|
|
|
|
|
|
|
|
Ich finde logarithmische Graphen sind ein wunderbares Mittel um sich selbst zu belügen und falsche Intuition aufzubauen. Es gibt Ausnahmen die sich von Natur aus logarithmisch verhalten (Audio vielleicht?), aber in den meisten Fällen finde ich logarithmische Skalen eher schlecht als gut. Aktuelles Beispiel: COVID-Fallzahlen in logarithmischen Plots halte ich für eine sehr blöde Idee, speziell wenn man darin dann noch Vergleiche (wie etwa zwischen Ländern) anstellt.
|
|
|
|
|
|
|
|
|
|
|
Wenn es nicht logarithmisch dargestellt wird, ist das Problem noch schlimmer, da ein Großteil der Graphen, die man vergleichen will ineinanderlaufen (zwischen 10^-6 und 10^-3) bei den interessanten Werten und davor [und das schließt physikalisch wichtige Werte ein] hemmungslos den Graphen aufblasen (bis zu ~400).
Ich bereite das ja nicht für die "Allgemeinheit" vor, sondern für Physiker. Bei COVID gebe ich dir insofern Recht, dass man keine Intuition für die Teile aufbaut, wenn man nicht monatelang damit geknechtet wurde. Mehrere Astro-Vorlesungen liefern das, die abendlichen Nachrichten und gelegentlich mal Wiki-Lesen nicht so.
Hast du entdeckt, dass Frauenbeine keine Tischbeine sind? Na bravo!
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Wraith of Seth am 03.10.2020 12:55]
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXIII |
