|
|
|
|
Ich glaubin C++ kannst du inzwischen 1'000'000 schreiben
Immernoch besser als 1,000,000.1234...
|
|
|
|
|
|
|
| Zitat von Oli
TIL 1_000_000. Weiß gerade nicht, wie ich das finden soll.
/e: Ich glaub ich einige mich auf "kacke". Dann lieber 10**6.
| |
Ich verstehe nicht, was daran kacke sein soll
|
|
|
|
|
|
|
| Zitat von Oli
TIL 1_000_000. Weiß gerade nicht, wie ich das finden soll.
| |
Lesbar.
|
|
|
|
|
|
|
Fand ich am Anfang auch sehr irritierend als ich das in einem Projekt gesehen hab, aber man gewöhnt sich sehr schnell dran.
|
|
|
|
|
|
|
Schlimmer find ich, dass 1e6 automatisch float ist
|
|
|
|
|
|
|
Ich finde das gut, denn es ist konsistent mit 1e-6, ohne irgendwelche Spezialfälle einzuführen. Das ist meist die bessere Lösung.
|
|
|
|
|
|
|
Ja und das e ist doch extra ne ieee gleitkommazahl
|
|
|
|
|
|
|
Okay, das hab ich nicht bedacht. Guter Punkt.
|
|
|
|
|
|
|
Ich habe einen 3D-Plot in Mathematica; darauf eine Kurve. Jetzt habe ich eine Liste von Punkten, die ich da hinzufügen möchte. Wenn ich aber
|
Code: |
Plot3D[BLABLUBB, Epilog -> {Blue, PointSize@Large,
Point[{2.0412659811804788`, 1/
10, -0.024117126531325903`}, {1.9953481886921989`, 19/
90, -0.20809167603988385`}, {1.8873511294953458`, 29/
90, -0.07569210673632422`}, {1.72392850266934`, 13/30,
0.046007455127992286`}, {1.5078796531338334`, 49/90,
0.28877390409363457`}, {1.2406252978665728`, 59/90,
0.6907166583809947`}, {0.9229504644646123`, 23/30,
0.9621481052708369`}, {0.5553107121949061`, 79/
90, -3.9302678076573514`}, {0.13797872774661446`, 89/
90, -572.6837308777665`}]}] |
|
versuche, scheitert es, weil er mir sagt, dass die Dimension des Arrays falsch ist - das ist halt patenter Unsinn.
Was macht Wolfram mal wieder wie das Arschloch, dass es/er ist?
¤DIT:
Weil Epilog nicht ist, was ich suche. https://mathematica.stackexchange.com/questions/52259/why-plot3d-does-not-accept-epilog-option
Na, danke auch, dass die Hilfe da keine Beispiele für gibt...
No man is an island, entire of itself;
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 11.09.2020 5:53]
|
|
|
|
|
|
Probier mal
|
Code: |
...
Point[{{2.0412659811804788`, 1/
...
90, -572.6837308777665`}}]}]
|
|
Sprich, einmal {...} für das Array aller Punkte, und einmal {...} für jeden einzelnen Punkt.
|
|
|
|
|
|
|
¤DIT: @Omega: Danke, aber auch das klappt nicht - Epilog scheint nur 2D-Objekte zu fressen...
____________
Wie merge ich zwei divergierende Branches eines TeX-Files in Github (Windows) am Einfachsten?
Oder geht das nur händisch, statt Diff die Unterschiede nacheinander abhaken zu lassen? Wenn letzteres geht - wie?
Speedy thing goes in, speedy thing comes out.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 14.09.2020 9:54]
|
|
|
|
|
|
git mergetool ist dein Freund.
Praktikable Tools wären z.b. kdiff3 oder meld.
|
|
|
|
|
|
|
Wenn du TeX mit VSCode schreibst, kannst du das auch im Editor mittels GUI zusammenklicken, welche Changes wo verwendet werden sollen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von derSenner am 14.09.2020 10:42]
|
|
|
|
|
|
Danke schonmal. ...dann werde ich morgen mal in noch mehr Tools einarbeiten...
Soviel zu: "Mal eben..."
...denk' mal drüber nach!
|
|
|
|
|
|
|
Ich würde nicht sagen, dass das zwingend Tool-Arbeit ist. Wenn du in github einen Pull-Request stellst, um die beiden Branches zu mergen, dann brauchst du kein Tool, sondern kannst es über die Browser-UI machen. Zumindest ist es bei Gitlab und den Merge-Requests so.
|
|
|
|
|
|
|
Ein git-webfrontend wie gitlab könnte man auch als tool bezeichnen.
Flutscht jedoch tatsächlich ziemlich gut
|
|
|
|
|
|
|
|
|
|
|
| Zitat von statixx
git mergetool ist dein Freund.
Praktikable Tools wären z.b. kdiff3 oder meld.
| |
Meld sagt mir, Git wäre nicht installiert. ._.
Lasst mich raten: GitHub installiert kein Git.
Der Klimawandel kann echt nicht schnell genug kommen.
¤DIT:
Nachdem ich jetzt Git und Meld installiert habe, löse ich es über eine Kombination der GitHub App Meld und TeXstudio per Hand. Git? Wird komplett umgangen, weil nur im Weg. Ey, was für ein Krampf. Meine Meinung zu Git und TeX bleibt völlig unbeeindruckt zu vor Monaten.
Wovon man nicht sprechen kann, darüber muss man schweigen.
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Wraith of Seth am 15.09.2020 3:12]
|
|
|
|
|
|
Where is the Github-App git-executable? https://stackoverflow.com/questions/26077449/i-cant-find-my-git-exe-file-in-my-github-folder/31769109
Wofür du die Github-App brauchst, ist die andere Frage. Normalerweise ist das recht simpel.
1. Git runterladen: https://git-scm.com/download/win
2. Git in den PATH von Windows hinzufügen. Macht der Install evtl. eh schon selbst, aber geht so: WIN+Pause drücken, links "Erweiterte Systemeinstellungen", unten rechts "Umgebungsvariablen", bei deinem User doppelklick auf den "Path"-Eintrag. Hier den Pfad zur eben installierten git.exe einstellen.
3. Ein Difftool deiner Wahl runterladen. Sollte bereits funktionieren.
4. ???
5. Profit.
Mit ordentlichen Editorn wie VSCode lässt sich das auch super integrieren, und du bekommst direkt im Text hinweise auf Mergen usw.
|
|
|
|
|
|
|
/Hass 1
Das geht wohl mit ein bisschen Rumstümpern an den Kontextmenüs auch mit TeXstudio, aber ich werde meinen (TeX-)Editor nicht für eine SVN ändern. Diskussionsende dazu.
Die GitHub-App war schlicht, was der Rest der Gruppe nutzt und damit mein erster Kontakt mit GitHub seit Jahren.
Meld tat es halbwegs, auch wenn ich das jetzt lokal an zwei verschiedenen Dateien gemacht habe, während ich im Hintergrund in einer dritten getippt habe. Die Github-App weigerte sich vehement, mir verschiedene Branches zu diff'en; nach der Installation von git und meld selbst geht das bestimmt irgendwie(tm), aber eigentlich(tm) hatte ich vor, heute mehr zu erledigen als zu mergen und meinen PC weiter mit NOCH mehr Kollaborationsscheiß zuzumüllen. Die Alternative war: Stundenlang (aber mit Ende in Sicht) per Hand, oder stundenlang (und eventuell nur noch mehr rabbit hole) es ans Laufen zu kriegen, wie ich es erwartet habe. Da ich in einer einer Stunde ein anderes Projekt per Skype beharke, war die Wahl klar.
Ein Projekt, bei dem ich dank overleaf deutlich schneller und fixer alles am Laufen hatte, das gemeinsame Editieren flüssiger läuft, weniger Software-Chaos auftreten kann, nicht plötzlich lokale LaTeX-Installationen im Main Branch auftauchen (nein, ich war's nicht), ...
Aber natürlich kommen jetzt wieder die ganzen madigen git-Propheten auf ihren Löchern gekrochen und schreiben mit ihrem prolabierten Anus die heilige Botschaft von git, vim, emacs, Linux, Kommandozeile und makefile auf jede freie Fläche.
/Hass 0
Blow shit up, throw women through walls, got it.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 15.09.2020 9:01]
|
|
|
|
|
|
Ach, WoS, ich arbeite täglich mehrfach mit git, merge Requests, usw. und es funktioniert einfach bombe. Da kannst du sagen, was du willst
|
|
|
|
|
|
|
OK Boomer.
Ein wenig Konstruktiv: Es wird natürlich schwer fallen ein Tool deinem Workflow und einen Erwartungen anzupassen, wenn beides nicht kompatibel ist. Nimm dir die Zeit, versteh die Konzepte, wähle informiert Werkzeuge aus und schonw irst du merken, dass es eigentlich wirklich recht simpel ist. Die Motivation hinter jedem Versionskontrollmanagement ist es, zu vermeiden, Dateien rumkopieren zu müssen und trotzdem sicher Historie zu haben. Bei den Systemen wie git haben Leute dann lang darüber nachgedacht, wie man das wohl anständig machen könnte. Da kann man dann schon persönlich von profitieren.
|
|
|
|
|
|
|
@homer: Da gehören halt auch zwei zu. Die Kombination git-Neuling gegen TeX-Neuling... ...ist nicht so prickelnd. Zumal die einzige Person, die beides (und wie es lokal verwendet wird) erklären könnte, nicht räumlich in der Nähe ist. Und ich nicht einmal einen fucking PC von der Uni gestellt bekomme. Und wenn, dann hat der nur ein völlig kastriertes, veraltetes und unbrauchbares LaTeX. Um das man schon betteln muss. "Wie, kein Word?"
@Borg: Ich raff ja das Grundprinzip. Aber ich hatte bisher nie eine brauchbare Einführung, die Online-Hilfen helfen mir meistens nicht wirklich, und immer noch kein Projekt, wo mir der Mehraufwand etwas gebracht hat. Ja, ich halte daran fest: Selbst meine Doktorarbeit hat nie einen Arbeitsschritt beinhaltet, den eine Versionskontrolle leichter oder sicherer hätte gestalten können. Wenn ich jetzt coden würde... ...aber das tue ich halt (noch) nicht.
So. Genug aufgeregt jetzt. Nächster Bluthochdruckquell wird Wolfram/Mathematica und Newton-Raphson.
Why can't we piss off a fuzzy planet? Still dangerous, but hey, bunnies.
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Wraith of Seth am 15.09.2020 9:19]
|
|
|
|
|
|
WoS, gib dir den Gitfuck trotzdem. Als ich mich gerade an den Schreibtisch setzte, musste ich feststellen, dass kein File in meiner Cloud juenger als Sonntagabend ist, dabei hab ich gestern gearbeitet. Und die (nicht gesyncte?) lokale Version wurde anscheinend beim Boot ueberschrieben oder so, jedenfalls ist alles von gestern weg.
In Zukunft (also nach dem Dokument, das muss naemlich heute Abend raus :-) ) wird auch tex ins git verlegt, nicht nur der Code...
|
|
|
|
|
|
|
Für die Redundanz habe ich ja alles in der Dropbox, was den Vorteil hat, dass es auch absolute DAUs raffen - ich bin in meinem Fachgebiet bei weitem nicht der computerfernste Mensch.
Dein Problem klingt auch nach: Arbeitsrechner. Habe ich halt gerade eh nicht.
Für die Mathediplomarbeit musste ich git benutzen, weil Gruppenusus. Morgens pull, abends commit. Nie was anderes. Abgeben. Zwei unnötige Commandos aus dem Tagesablauf streichen.
Die Hilfe, die die einzige Person mit Ahnung gerade per Mail schickte:
Spoiler - markieren, um zu lesen:
If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
If I didn't have you, I'd probably have someone else.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 15.09.2020 9:25]
|
|
|
|
|
|
| Aber ich hatte bisher nie eine brauchbare Einführung, die Online-Hilfen helfen mir meistens nicht wirklich | |
So geht es mir ehrlichweise nicht selten, wenn ich mich an etwas Neues wage. Aber irgendwann kommt man an den Punkt, an dem die Onlinehilfe sogar wieder hilfreich werden. Ich kann verstehen, wenn dabei Frust entsteht, aber langfristig führt es zu weniger, da bin ich mir ganz sicher. Du bist ja nicht der erste, der git+Tex gemeinsam erfolgreich verwenden will.
|
|
|
|
|
|
|
WoS, hatten wir hier nicht schonmal einen längeren Disput mit dir über Git?
|
|
|
|
|
|
RANT!!!
|
Nein, ich will das nicht. Ich muss das. Grooooßer Unterschied - vor allem, was meine Bereitschaft angeht, mich auf Online-Hilfen einzulassen. Arkane TeX-Stackexchange-Antworten reverse engineeren mach ich dir sofort, egal wie wenig ich davon raffe.
Und bei aller Vorliebe: TeX ist da die vollständig gleiche GEQUIRLTE OPEN-SOFTWARE SCHEISSE. Die "Hilfskultur" ist da wahrscheinlich sogar, gerade im deutschsprachigen Netz, noch toxischer und arrogantert, dank der Religion bis zum KOMA. Effektiv eine Menge Gatekeeping und dann darauf zig-tausend halbgare "Lösungen". (Wobei, vielleicht tue ich Lyx gerade Unrecht und es ist tatsächlich nutzbar out-of-the-box wie Word. Ich habe meine Zweifel, ungesehen.) Das fängt an bei der Reflexantwort: "Aber du wirst es wollen und dich ärgern, dass du es nicht immer so gemacht hast!", hört da aber nicht auf. Da wird monolithisch eine richtige Antwort für Workflows postuliert, wenn die Metrik für "guter Workflow" nicht mal bekannt ist. Wenn man von "der richtigen Software" redet, macht man's bereits falsch. S o-einfach-ist-das-jpg. Natürlich, wenn ich irgendwann in die Verlegenheit komme, Mentor zu sein, werde ich auch LaTeX an den Mann bringen - aber wer mir eine solide Word-Lösung gibt, wird damit mühelos durchkommen. Ich kann dann nur halt nicht helfen, falls was schiefgeht. Der Grund, warum ich dann LaTeX lehre, ist, weil ich es dann tatsächlich LEHREN kann statt faul den Lernaufwand vollständig auf andere abzuwälzen.
Ähnlich bei Programmiersprachen und wie man sie lernt: Da wird oft ein bestimmtest Persönlichkeitsprofil angenommen, bei dem eine intrinsische Motivation schon vor dem Kontakt mit der Programmiersprache existiert, oder, in der milden Fassung, durch den Kontakt mit der Programmiersprache geweckt wird. Auch ohne diese intrinsische Neugier, die der typische picklige, weiße, männliche, hetero-cis-Nerd für spaghettimonstergegeben hält kann man aber ein solider Programmierer werden. Man wird dann zwar wahrscheinlich eher zu Betriebsblindheit neigen, oder sehr spezielles Fachwissen haben - aber das spricht einem weder Fähigkeit noch Daseinsberechtigung ab. Auf der lehrenden Seite ist das natürlich frustrierend, aber sobald man sich mit git, TeX, Linux, Programmiersprachen und Co auseinandersetzt, findet man zwei Optionen: Kostenpflichtiges Angebot oder die gleiche knappe, bündige, no-nonsense, der-Leser-weiß-eh-schon-was-er-machen-wird-Art. Der Leser ist nur einen Club-Mate-Exzess davon entfernt mit Regex die Welt zu retten, wenn er sich um git sorgt. Denn Menschen und ihre Bedürfnisse an git sind alle gleich.
@Oli: Ja, vor ein paar Monaten, iirc. Wahrscheinlich letztes Jahr...?
Make way evil! I'm armed to the teeth and packing a hamster!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 15.09.2020 9:49]
|
|
|
|
|
|
Äh. Ok. Open source kann schon arg scheiße sein, aber das find ich jetzt ein wenig übertrieben. Nicht alles ist so wie die Kernel-Mailingliste.
|
|
|
|
|
|
|
| Zitat von Wraith of Seth
Auch ohne diese intrinsische Neugier, die der typische picklige, weiße, männliche, hetero-cis-Nerd für spaghettimonstergegeben hält kann man aber ein solider Programmierer werden. | |
...
|
|
|
|
|
|
Thema: pOT-lnformatik, Mathematik, Physik XXIII |
|