Mal eine eher allgemeine Frage: Welche Programmmiersprache wird heute für Software mit hohem numerischen Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder Quantenchemie, verwendet? Zu meiner Studienzeit war Fortran das Mass aller Dinge, mit oft steinzeitlichem, über Jahrzehnte immer wieder ergänztem Code. Ich muss zugeben, dass ich mich seit dem letzten Jahrtausend nicht mehr mit derartig aufwändigen Rechnungen beschäftigt habe, was an Numerik anfiel, konnte ich seitdem mit Matlab erschlagen. Was würde man heute nehmen, wenn man eine klassische "number crunching"-Anwendung neu schreiben würde? C(++) ist zwar weit verbreitet, aber für numerische Rechnung (z.B. lineare Algebra) eher umständlich. Ist Python eine Alternative? Fortran wurde ja auch ständig weiterentwickelt, die modernen Versionen haben kaum noch etwas mit dem vorsintflutlichen F77 oder früher gemeinsam. Aber nutzt das jemand?
Moin, Dann und wann bau' ich mir mal ein GNU-Octave (=Matlab fuer Bargeldarme) aus sourcen; dabei kann man feststellen, dass schon noch ganz ordentlich Zusatzlibs benoetigt werden, die immernoch in Fortran geschrieben sind... Gruss WK
Fritz G. schrieb: > C(++) ist zwar weit verbreitet, aber für numerische Rechnung (z.B. > lineare Algebra) eher umständlich. Ist Python eine Alternative? Numpy ist in C/C++ geschrieben.
Fritz G. schrieb: > Was würde man heute nehmen, wenn man eine klassische "number > crunching"-Anwendung neu schreiben würde? Eine GPU. Dir geht es ja scheinbar nicht um hohe Präzision aka viele Stellen, womöglich arbitrary numbers, sondern um Tempo, durchaus mit kleinen eventuell sogar Intergerwerten. Wenn man da kein speziall für die Aufgabe programmiertes FPGA nutzt, dann eben eine GPU, wie sie als Bitcoin Miner oder CUDA https://de.wikipedia.org/wiki/CUDA eingesetzt werden.
> Numpy ist in C/C++ geschrieben.
WIMRE benutzen zugrundeliegende BLAS-Libraries gerne noch Fortran
> Was würde man heute nehmen, wenn man eine klassische "number > crunching"-Anwendung neu schreiben würde? Du koenntest ja mal das hier probieren: https://de.wikipedia.org/wiki/Julia_(Programmiersprache) Vanye
Fritz G. schrieb: > Fortran wurde ja auch ständig weiterentwickelt, die modernen Versionen > haben kaum noch etwas mit dem vorsintflutlichen F77 oder früher > gemeinsam. Der dafür geschriebene Code schon. Schau mal in die ganzen Bibliotheken für lineare Algebra rein, das wimmelt nach wie vor von kryptischen Bezeichnern, weil man ja alles in 6 (signifikante) Zeichen rein pressen musste dazumals. 1N 4. schrieb: >> Numpy ist in C/C++ geschrieben. > > WIMRE benutzen zugrundeliegende BLAS-Libraries gerne noch Fortran So isses. Der wesentliche Verdienst von Python hier dürfte es sein, ein Bindeglied für die alten FORTRAN-Bibliotheken ins 21. Jahrhundert ahzubieten. Da es außerdem noch ein Bindeglied zu arbiträr großen Ganzzahlen bietet, ist es rund herum recht universell benutzbar.
Fritz G. schrieb: > Welche Programmmiersprache wird heute für Software mit hohem numerischen > Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder > Quantenchemie, verwendet? meine Empfehlung: https://docs.sciml.ai/ModelingToolkit/stable/ Nach FORTRAN, C, Octave, Python bin ich jetzt dort gelandet. JULIA hat Suchtpotential - erfordert aber ein Umdenken. Die Entwicklung wird getrieben vom MIT, CERN ,... und anderen Forschungseinrichtungen. https://julialang.org/ und https://juliacon.org/2024/ - Videos findet man auf youtube.
:
Bearbeitet durch User
Fritz G. schrieb: > Ich muss zugeben, dass ich mich seit dem letzten Jahrtausend nicht mehr > mit derartig aufwändigen Rechnungen beschäftigt habe, was an Numerik > anfiel, konnte ich seitdem mit Matlab erschlagen. Vielleicht sollte man erwähnen, dass sich seit dem letzten Jahrtausend auch geändert hat was als "aufwendige Rechnungen" gilt. Bist du dir sicher, dass deine "aufwendigen Rechnungen" heute noch als aufwendig gelten? Wenn deine Anforderungen an "aufwendig" nicht gestiegen sind, dann kannst du das, überspitzt dargestellt, heutzutage skripten. Du musst dir keine großen Gedanken um die Sprache machen. Nimm die die du am bequemsten findest. Um mal grob zu umreißen was sich geändert hat: 2000 kam im Consumer-Bereich der erste Pentium 4 auf den Markt. Ich bin mir allerdings nicht sicher ob das der damals schnellste erhältliche Intel-Prozessor war. Wenn mehr Rechenleistung für "aufwendige Rechnungen" auf dem Desktop benötigte konnte zu Workstations greifen. Je nach Anwendung Feld, Wald und Wiesen Workstations wie SPARCultra 5 und 10 mit UltraSPARC IIi CPU oder, wenn Chef gönnte, zum Beispiel SGI Octane mit MIPS R10000 (30000 USD). Natürlich auch alles was von anderen Herstellern dazwischen lag. Wenn das nicht reichte musste man per Fernzugang ins Rechenzentrum. Die nächste Eskalationsstufe danach waren Supercomputer. Beides für Privatleute damals völlig unmöglich. Alles Schnee von Gestern. Heute hat ein Handy die Rechenleistung damaliger Supercomputer. "aufwendige Rechnungen" von vor der Jahrtausendwende kaut dir heutzutage ein Office-PC durch ohne warm zu werden. Von PCs mit aktuellem Intel- oder AMD-Spitzenprodukt gar nicht zu reden. Was ist das momentan? i9-14900KS? GPUs als nächste Eskalationsstufe wurden schon erwähnt. Wenn das nicht reicht oder du nicht GPUs programmieren möchtest, dann kannst du heutzutage auch als Privatmann ins Rechenzentrum gehen. Das nennt sich heute nur Cloud und Anbieter wie Amazon oder Google verkaufen dir CPU (und GPU) Rechenzeit zu erträglichen Preisen.
Beitrag #7754662 wurde vom Autor gelöscht.
Hannes J. schrieb: > GPUs als nächste Eskalationsstufe wurden schon erwähnt. Als Programmiersprache, nach der hier ja gefragt wurde, ist die aber ganz schön komisch ...
Python ist in der Wissenschaft weit verbreitet, weil es eine Skriptsprache ist, die einfach und übersichtlich ist und man die Programme leicht ändern kann. Zudem bietet sie zahlreiche fertige Bibliotheken, z.B. das o.g. numpy https://de.wikipedia.org/wiki/NumPy und scipy https://de.wikipedia.org/wiki/SciPy
:
Bearbeitet durch User
Jens G. schrieb: > Hannes J. schrieb: >> GPUs als nächste Eskalationsstufe wurden schon erwähnt. > > Als Programmiersprache, nach der hier ja gefragt wurde, ist die aber > ganz schön komisch ... Das stimmt. Aber der TO hat angegeben, dass er sich in diesem Jahrtausend noch nicht mit der Thematik beschäftigt hat und da ist ein entsprechender Hinweis (auch wenn er keine Programmiersprache benennt) sicher nicht verkehrt.
CUDA https://www.studysmarter.de/studium/informatik-studium/systemarchitektur/gpu-programmierung/ https://de.wikipedia.org/wiki/CUDA#Programmieren
Es stellt sich natuerlich die Frage, ob sich das Problem parallelisieren oder nicht. Lasst es sich parallelisieren, ist natuerlich in den letzten zwanzig Jahren eine Unmenge passiert. Zum einen ist die Hardware billig und portabel geworden (ich habe hier einen Consumer-PC mit 6 Kernen, im Jahr 2000 waere noch richtig teuer gewesen), zum andern hat z.B. Fortran 2023 (ISO/IEC 1539:2023) massives parallel Rechnen vereinfacht (z.B. die Matrix-Rechnungen).
Bestens geeignet für Abbildung mathematischer Verfahren im Programm sollte ja wohl APL sein. Weshalb sich manche bereits Gedanken gemacht haben, APL auf GPUs zu implementieren. Die Sprache bietet reichlich Gelegenheit, Parallelität auszudrücken und GPUs sind genau dafür geschaffen. https://elsman.com/pdf/Dyalog17.pdf
:
Bearbeitet durch User
- Fortran - C & C++ - MATLAB - Julia - Python Für Linear Algebra nutzen eh all die genannten Sprachen die selben libraries, LAPACK/BLAS, daher ist das high level Interface gar nicht so wichtig. Für Differentialgleichungen werden häufig SUNDIALS solver benutzt: https://computing.llnl.gov/projects/sundials Auch können alle genannte Sprachen parallelisieren, und auf GPUs arbeiten. IMO ist es nahezu egal, welche high-level Sprache man nutzt, es sei denn es geht um Probleme, die hoch individuell sind, und es auf schnelle Schleifenausführung oder bedingte Sprünge ankommt, denn da sind interpretierte Sprachen traditionell langsamer. Für "standard" Probleme im Wissenschaftlichen Rechnen würde ich immer MATLAB, Julia, oder Python nutzen.
Eine Programmiersprache kann gar nichts. Die machen alle dasselbe, mehr oder weniger. Die Geschwindigkeit macht man mit den Algorithmen. Ja, man kann spezielle Mathematik Libraries verwenden, muss aber trotzdem eine Ahnung haben. Das Geheimnis an Simulation ist das unnoetige Wegzulassen. Der Unterschied der Libraries : Eine Matrixmultiplikation in C/C++ ist ein For (x=.. ) for (y=.. ) mit N Quadrat Operationen. Wenn man nun weiss, dass die Matrix schmal ist, weil Finite Elemente, sind's nur noch N Linear Operationen. Das geht fuer N gegen Gross in die Zeit.
Fritz G. schrieb: > Zu meiner Studienzeit war Fortran das Mass > aller Dinge Das ist aktuell immer noch so. C und C++ gewissermaßen als "Wingman" unterwegs, und Rust ist auch recht potent und wird auch schon eingesetzt. Da fehlen dann aber die vertrauten Bibliotheken und Parallelisierer oder was auch immer. Rust könnte schon der neue Maverick werden, fehlt halt ein wenig der Unterbau und das Drumherum, was bei C und C++ schon länger vorhanden ist. (https://www.intel.com/content/www/us/en/high-performance-computing/hpc-software-and-programming.html)
Die Frage war nach Programmiersprachen für numerische Berechnungen: Hier ein Artikel (frei verfügbar) aus Sicht der Wissenschaft - auch mit Vergleichen der schon genannten Sprachen. https://link.springer.com/article/10.1007/s41781-023-00104-x Die Frage ist nicht immer die Geschwindigkeit in der Ausführung, sondern auch die Zeit die ich zum Erstellen des Programms brauche, die Wiederverwendbarkeit und die Sicherheit (hier dürfte RUST aktuell das Rennen machen). In der Ausführung zählt nicht nur die Zeit für die numerische Bearbeitung, sondern auch die Zeit für die Speicherverwaltung (garbage collection).
Rbx schrieb: > Fritz G. schrieb: >> Zu meiner Studienzeit war Fortran das Mass >> aller Dinge > > Das ist aktuell immer noch so. C und C++ gewissermaßen als "Wingman" > unterwegs, und Rust ist auch recht potent und wird auch schon > eingesetzt. Da fehlen dann aber die vertrauten Bibliotheken und > Parallelisierer oder was auch immer. > Rust könnte schon der neue Maverick werden, fehlt halt ein wenig der > Unterbau und das Drumherum, was bei C und C++ schon länger vorhanden > ist. > (https://www.intel.com/content/www/us/en/high-performance-computing/hpc-software-and-programming.html) Ich würde sagen, bei C/C++ Vs Fortran ist es hauptsächlich der Compiler, der den Unterschied heute macht (klammert man die Algorithmen an sich aus). Da ist es oft sinnvoll GCC, llvm und z.b den Intel Compiler zu vergleichen. Die können ein optimiertes complilat für die ziel-cpu erstellen... Das hat einen weitaus größeren Impact als die Sprache. Wobei natürlich eigen3 in C++ ein weitaus besseres optimieren über die gesamte Applikation erlaubt, als z.B irgend ein Python Script.... Ich meine damit aber jetzt nicht high Level optimization, sondern Dinge wie Link-Time-Optimization und co, die vom Compiler/linker durchgeführt werden. Der Zeitunterschied beim coden ist IMHO nicht existent bzw vernachlässigbar, wenn man sich die eigentliche Entwicklungszeit der eigentlichen Algorithmen mit "Bleistift/Papier" ansieht. Daher mein Tipp: zuerst gut überlegen und dann in einer Compiler Sprache die man wirklich versteht schreiben. Libs sind gut, aber man muss auch dort verstehen wie sie arbeiten um die Daten effizient bearbeiten zu können. Umkopieren und im Extremfall typ-konvergieren bei der Übergabe von lib A nach lib B kann einem den Tag versauen. Bei mir ist es C++ im Qt Framework (GUI, ii,...) gespickt mit eigen3 und boost für Numerik, optimization,... Was mich zur Frage vom TO bringt: was nehmen die im Cluster Tja die nehmen das, was sie gut verstehen und am Cluster supported wird. Soweit ich informiert bin, ist der GCC am ARM das Maß aller Dinge. Am x86 LLVM oder der Intel Compiler. Dann stellt sich die Frage, wie die interconnects bedient werden. OpenMP ist z.B beim GCC quasi ein Compiler Flag. Es gibt da aber viele lösungen für unterschiedlichste workloads und Cluster Architekturen. Dazu kommen dann so Dinge wie CUDA, OpenCL,... Und erst jetzt wird die Sprache, in der "die paar Zeilen Algorithmus" implementiert werden, interessant. Rust hat ein paar recht interessante Eigenschaften, die zumindest theoretisch dem Compiler Möglichkeiten für ein noch aggressiveres optimieren geben (also weniger "Tricks" als in C/C++ erlauben) sollten. Ob sich das im Vergleich zu Fortran oder C/C++ tatsächlich auswirkt... Schwer abzuschätzen. Irgendwann fängt man immer an, den profiler anzuwerfen. Im Extremfall wird dann eine Funktion per Hand optimiert oder aber ein Datenfluss komplett umgestellt. Das hat für mich dann aber wieder weniger mit der Wahl der Sprache zu tun. 73
Ganz klar Ada. Wird gerne in der Luft- und Raumfahrt genutzt für numerische Berechnungen. https://de.wikipedia.org/wiki/Ada_(Programmiersprache) Ada erlaubt es eigene primitive Datentypen mit vorgegebener Präzision zu definieren.
Sarah D. schrieb: > Ganz klar Ada. Wird gerne in der Luft- und Raumfahrt genutzt für > numerische Berechnungen. Ganz klar COBOL. Wird überall gerne in der Wirtschaft genutzt für numerische Berechnungen. Die genaue Bedeutung von „gerne“ in diesem Kontext ist allerdings nicht die, die im Duden steht. Oliver
Beitrag #7761080 wurde von einem Moderator gelöscht.
Beitrag #7761086 wurde von einem Moderator gelöscht.
Beitrag #7761094 wurde von einem Moderator gelöscht.
Beitrag #7761099 wurde von einem Moderator gelöscht.
Oliver S. schrieb: > Ganz klar COBOL. Wird überall gerne in der Wirtschaft genutzt für > numerische Berechnungen. > > Die genaue Bedeutung von „gerne“ in diesem Kontext ist allerdings nicht > die, die im Duden steht. :D Ein ehemaliger Schulkamerad von mir, der dann Informatik studiert hat, nahm nach dem Abi eine Job an, bei dem er in COBOL programmierte. Das hat ihm, glaub ich, nicht wirklich Spaß gemacht. Sein Kommentar: "Man zwingt mich. Mit Geld." :)
:
Bearbeitet durch User
Giovanni schrieb: > Die Frage ist nicht immer die Geschwindigkeit in der Ausführung, sondern > auch die Zeit die ich zum Erstellen des Programms brauche, die > Wiederverwendbarkeit und die Sicherheit (hier dürfte RUST aktuell das > Rennen machen). Das ist zwar korrekt, allerdings sehe ich nicht, daß die Sicherheit, die Rust bieten kann, für akademische Anwendungen oder High-Performance-Computing eine prominente Rolle spielen würde. Die Anwender in diesem Umfeld haben auch wenig Interesse, sich mit Dingen wie Speicherverwaltung, Ownership und Typsicherheit herumzuschlagen -- das siehst Du bereits daran, daß die beliebteste Spache in diesem Bereich aktuell Python ist. Das erledigt alle diese Dinge ohne manuelle Eingriffe, wenn auch zum Preis eines etwas höheren Ressourcenbedarfs und einer etwas weniger hohen Performance. Stattdessen spielt Python in diesem Umfeld seine großen Stärken aus, insbesondere Zugänglichkeit und Übersichtlichkeit, seine exorbitante Infrastruktur, sowie seine einfache Verwendung als "Glue-Sprache" bei der Nutzung von Code aus anderen Sprachen.
Ein T. schrieb: > daß die beliebteste Spache in diesem > Bereich aktuell Python ist Fritz G. schrieb: > Was würde man heute nehmen, wenn man eine klassische "number > crunching"-Anwendung neu schreiben würde? Fritz G. schrieb: > Software mit hohem numerischen > Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder > Quantenchemie Ich glaube, da muss man deutlich differenzieren! Python ist absolut ungeeignet typische numerische Probleme "direkt" zu lösen. Ja, es gibt viele, die das quasi als moderneres Matlab verwenden (auch darin kann man Anwendungen machen und das wurde auch gerne gemacht, wenn man die numerischen libs gebraucht hat). Das, von dem der TO gesprochen hat, wird aber verteilt über mehrere Systeme mit diversen Beschleunigern gemacht. Da spielt die Zeit für's "schreiben" der Anwendung udgl. praktisch keine Rolle! Ja, wenn du alles in einer Maschine hast, dann kann das mit Python und den vorhandenen libs (die dann aber in C/C++, Fortran, "OpenCL" oder "CUDA" geschrieben wurden) schon funktionieren. Im Cluster, behaupte ich, schaut die Welt anders aus. Wenn ich infiniband interconnts im Cluster bezahlen würde, dann wär jeder der ohne Grund Python nimmt sofort auf der Straße. Wobei hier Python durch jede x-beliebige Sprache ersetzbar ist! In dem Bereich ist Hardware so teuer, dass sich noch jedes zusätzliche Mannjahr Arbeit auszahlen kann. Man beachte hier "kann". Was ich damit meine sah/sieht man bei den crypto mining rigs mir Grafikkarten schön. Da gab/gibt es Karten mit fetten GPS aber nur pci-e 3.0 x1 links. Auf dem Board, das 8 dieser karten fasst, werkelt dann daneben irgend eine (verglichsweise) "low-cost-cpu" Das wären dann Workloads, wo wahrscheinlich sogar javascript ohne JIT compiler schnell genug wäre die Karten zu fütten, weil dort tatsächlich der allergrößte teil der Arbeit über irgendeinen OpenCL/CUDA/... Kernel erledig wird und alles rundherum eigentlich 2. rangig bei der gesamt performance ist. Dort kann man auch recht problemlos den "cluster" über einen normalen Internet uplink verbinden und ihn dann mining-pool nennen. Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU taktzyklus vermeiden. Und gerade das macht Rust nun wieder interessant. Je mehr Annahmen ein Compiler treffen kann, desto mehr Optimierungsmöglichkeiten hat er. Der gcc hat z.B. dieses Flag: "-fopt-info". Damit kannst du dir ansehen, wo er warum nicht optimieren konnte. Mit den "restriktionen" von Rust sind einfach gewisse Probleme, die ein Optimieren verhindern, nicht möglich. Aktuell scheint C++ in benchmarks noch etwas schneller als Rust zu sein. Ich behaupte aber, dass die von Rust geforderte Disziplin das Durchschnittsprogramm schneller als eines in C++ machen sollte. Nicht jeder kennt den verwendeten compiler für seine zielarchitektur so genau, dass er genau die richtigen design-pattern anwendet... Nichtsdestotrotz werde ich auf absehbare Zeit hauptsächlich bei C++ bleiben. Insbesondere wenn der code schnell sein soll, habe ich dort einfach (noch) wesentlich mehr Erfahrung. Fritz G. schrieb: > C(++) ist zwar weit > verbreitet, aber für numerische Rechnung (z.B. lineare Algebra) eher > umständlich. Ist Python eine Alternative? Zum Schluss noch eine Anmerkung, weil da sicher wieder ein "aber python hat doch..." kommt. Eigen3 (in C++) ist eine header-only lib, die wirklich schnell (schneller als freie BLAS implementierungen!) und (in meinen Augen) extrem konfortable ist. Python gefällt mir sprachlich überhaupt nicht... aber ich nutze z.B Deno sehr gerne. Das hat auch numpy bindings. Wenn ich jetzt ein Problem habe, bei dem ich direkt in C++ schnell zum Ziel komme weil mir da vllt. Qt in die Hände spielt, dann macht man es da. Ist es aber bequemer mit Deno an die Daten ranzukommen und das Ergebnis lässt sich so hinreichend schnell berechnen (man muss dazu sagen, dass über den V8 JIT auch Deno Code richtig schnell sein kann!), dann wird das so gemacht. Habe ich aber Gründe, in denen ich nichtmal std::vector nehmen will, weil ich z.B auf die CPU cachline größe achtgeben darf, dann nehme ich hardcode-no-lib-c++. Was ich sagen will: Das eigentliche Problem diktiert die Sprach-Wahl. Nicht die verfügbaren Libs (es gibt so ziemlich jede schnelle Lib in jeder sprache) oder die zeit, die man für's schreiben braucht oder ähnliches. Kleines Beispiel. Sagen wir wir hätten ein Problem bei dem die a2-megagpu-16g bei google compute engine eine Woche rechnet. Kostet aktuell lt. Homepage $60.9/h on demand. Macht gut 10k pro Woche. Sagenwir dein "Coder" kostet dir 120€/h (damit 1k pro tag rauskommt). Ob der jetzt 1 oder 2 tage arbeitet macht nicht einmal 10% bei den Kosten aus. Nachdem das Thema HPC aber doch ziemlich divers ist, lässt sich diese Aussage natürlich auch auf den Kopf stellen... womit "Das eigentliche Problem diktiert die Sprach-Wahl." noch einmal bewiesen wäre! 73
Hans W. schrieb: > womit "Das eigentliche > Problem diktiert die Sprach-Wahl." noch einmal bewiesen wäre! Die "Lesenswert"-Einstufung finde ich, kann man hier direkt wörtlich nehmen. Ich hatte vor einigen Jahren mal eine Frage hier gestellt, die drehte sich in etwa um Optimierungen, Asm, Sprachen, Diskussionen. Da kamen dann über 200 Antworten, und nicht nur das, jede für sich einzigartig und hochinteressant, also sehr wenig Redundanz. Diese vielen hochkarätigen Beiträge unterstreichen letztendlich genau das was du hier schreibst. Es gibt ein schönes Rust-Programm, welches ein wenig POC ist, aber auch zeigt, wie weit man mit Rust kommen kann, wenn man sich etwas Mühe gibt: https://github.com/BurntSushi/ripgrep Wetterberechnungen, und das kam hier noch gar nicht zu Sprache, brauchen auch sowas wie MPI (Message Passing Interface) https://de.wikipedia.org/wiki/Message_Passing_Interface wo C++ mit seiner Objekt-Orientierung gewisse Vorteile hat. Naja und Haskell: https://hackage.haskell.org/package/haskell-mpi/docs/Control-Parallel-MPI-Fast.html (;) (typisch Haskell eben) Ein anderer problematischer Hintergrund ist die objektive Daten Interpretation. Und da sind wir dann schon mit einem Bein im politischen, da wollen wir gar nicht hin. Es wäre aber schön, wenn die Hintergründe, Handgriffe und Interpretationshilfen der üblichen Statistik-Nutzung einigermaßen bekannt sind.
Beitrag #7761448 wurde von einem Moderator gelöscht.
Hallo in die Runde, meiner Meinung nach, je nach was man machen will, ist Python die erste Wahl um zu experimentieren. Wenn der Python-Funktionsumfang ausreichend ist, dann kann man Cython nehmen, C-Code generieren und dann für die verwendete Platform kompilieren. Dadurch wird die Geschwindigkeit wesentlich verbessert. Eine sehr gute Alternative ist die Programmiersprache Julia. Diese Programmiersprache wurde genau für numerisches und wissenschaftliches Rechnen entwickelt. Diese Programmiersprache ist Open-Source.
Hallo Hans, lieben Dank für Deine langen Texte. Bitte verzeih', daß ich nicht auf jeden Punkt einzeln eingehen kann. Hans W. schrieb: > Ich glaube, da muss man deutlich differenzieren! Das glaube ich auch. > Das, von dem der TO gesprochen hat, wird aber verteilt über mehrere Genau hier geht die Differenzierung schon los. Dein Beispiel des Cryptomining gefällt mir für das eine Extrem sehr gut: da werden seit Jahren immer wieder dieselben Algorithmen gerechnet, und am Ende hängt das Einzig Wichtige (tm) dabei am Verhältnis zwischen den Kosten (im Wesentlichen für Hardware und Energie) und dem Ertrag (Coins). In solchen Fällen ist es natürlich klug, so effizient wie möglich zu rechnen, und eine umfangreiche Optimierung ist daher ausgesprochen sinnvoll. In anderen Fällen wie der Klimaforschung geht es hingegen darum, immer wieder mal mehr, mal weniger stark veränderte Modelle zu berechnen, die Daten nach den Rechenschritten immer wieder anders zu korrigieren, und dabei spielen die Entwicklungsaufwände und -Zeiten in seriösen Kalkulationen und Beurteilungen dann schon wieder eine gänzlich andere Rolle. Denn, übertrieben gesagt: noch schlimmer als ein langsamer Cluster ist einer, der gar nichts rechnet, weil die Entwickler noch in ihrer nächsten Iteration feststecken. ;-) > Ja, wenn du alles in einer Maschine hast, dann kann das mit Python und > den vorhandenen libs (die dann aber in C/C++, Fortran, "OpenCL" oder > "CUDA" geschrieben wurden) schon funktionieren. > > Im Cluster, behaupte ich, schaut die Welt anders aus. Das stimmt, aber nichts -- ich wiederhole: nichts! -- hindert Python daran, vorhandene Clusterarchitekturen zu benutzen, seien es Infrastrukturen zum Batchprocessing wie Apache Spark (PySpark!) oder Stream Processing Engines wie Apache Storm, Heron, oder Gearpump. MPI for Python [1] existiert, und es gibt sogar einen speziellen Just-in-time-Compiler für numerische Applikationen numba [2], dessen Ausführungsgeschwindigkeit häufig durchaus mit Fortran und C/Cpp mithalten kann. Schnittstellen zu CUDA, Vector und gibt es ebenso wie auf Python spezialisierte Distributed-Computing-Frameworks wie Ray. Naja, ich will hier nicht die ganze Landschaft der in Python oder für Python entwickelten Werkzeuge ausbreiten, das würde den meine zeitlichen Ressourcen und vermutlich auch den Rahmen dieses Forums sprengen. Tatsache ist aktuell, daß Python heute eine der, wenn nicht gar die verbreitetste Sprache ist, und das betrifft eben auch rechenintensive Bereiche wie Distributed Computing, Maschine Learning und Artificial Intelligence. [1] https://mpi4py.readthedocs.io/en/stable/ [2] https://numba.pydata.org/ [3] https://www.ray.io/ > Wenn ich infiniband interconnts im Cluster bezahlen würde, dann wär > jeder der ohne Grund Python nimmt sofort auf der Straße. Wobei hier > Python durch jede x-beliebige Sprache ersetzbar ist! Allerdings gibt es nichts, das Python daran hindern würde, Interconnects mit Infiniband oder [1248]00GBASE-X zu benutzen... > In dem Bereich ist Hardware so teuer, dass sich noch jedes zusätzliche > Mannjahr Arbeit auszahlen kann. Im Moment sehe ich eher ein Auseinanderdriften zweier Ansätze. Die riesigen, teuren Maschinen wie früher die E10k, um ein prominentes Beispiele zu nennen, verschwinden zunehmend in Nischen, in denen es aus welchen Gründen auch immer notwendig ist, sehr große Workloads auf einer Maschine zu verarbeiten. In der breiteren Anwendung sehe ich heute etliche große COTS-Cluster (Common Of The Shelf), deren Maschinen im Prinzip aus billiger Consumer-Hardware bestehen und je nach Anwendungsfall mit spezieller Hardware zum Beispiel für Interconnect und GPU-Computing nachgerüstet werden. Sehr häufig kosten die Nachrüstungen dabei sogar wesentlich mehr als der Rechner, in dem sie stecken. > Das wären dann Workloads, wo wahrscheinlich sogar javascript ohne JIT > compiler schnell genug wäre die Karten zu fütten, weil dort tatsächlich > der allergrößte teil der Arbeit über irgendeinen OpenCL/CUDA/... Kernel > erledig wird und alles rundherum eigentlich 2. rangig bei der gesamt > performance ist. Absolut richtig, nur daß Python im Gegensatz zu Javascript ausdrücklich mit (unter anderem) Ziel entwickelt wurde, eine Glue-Sprache zu sein. Und genau diese Eigenschaft ist es, warum es so viele in anderen Sprachen entwickelte Libraries und Frameworks für Python gibt, warum die Boost-Entwickler eigens Boost.Python zur Einbindung von Python in C++ und C++ in Python entwickelt haben, warum im Bereich der KI die verbreitetsten Frameworks, Tensorflow und PyTorch, auf Python ausgerichtet sind. All dies trägt dazu bei, daß Python auch im Bereich des High Performance Computing so beliebt und verbreitet ist: es bietet einen einfachen Zugang zu hoher Rechenleistung und verteiltem Rechnen, ist leicht les- und schreibbar, hat eine enorme Infrastruktur, und es funktioniert wunderbar als Glue-Code zwischen vielen, bisweilen sehr verschiedenen Domänen. > Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU > taktzyklus vermeiden. Wir scheinen, wie sage ich das... sehr unterschiedliche Ansätze zu verfolgen, denn wenn ich ein IO-lastiges Problem habe, dann kümmere ich mich zuerst um meinen I/O. Um die CPU-Taktzyklen kümmere ich mich nur, wenn mein Problem ein CPU-lastiges ist. Du hast Dich verschrieben, oder? ;-) > Aktuell scheint C++ in benchmarks noch etwas schneller als Rust zu sein. > Ich behaupte aber, dass die von Rust geforderte Disziplin das > Durchschnittsprogramm schneller als eines in C++ machen sollte. Naja... Rechnen müssen sie am Ende doch alle, und selbst mit größtmöglicher Optimierung kosten Berechnungen nun einmal Taktzyklen. Für ein paar Prozent höherer Rechenleistung von einer etablierten Sprache mit etlichen fertigen Libraries und Frameworks auf eine andere Sprache zu wechseln und dafür dann womöglich signifikante Teile einer Applikation neu schreiben und natürlich danach auch pflegen und warten zu müssen, ist eine eher selten getroffene Entscheidung, die vermutlich nur in wenigen Ausnahmefällen ökonomisch ist. Bisher sehe ich noch nicht, daß Rusts Infrastruktur an jene herankommt, die für C++ und Python bereits existieren. Aber warten wir ab, bekanntlich ist schließlich nichts so beständig wie der Wandel. > Nichtsdestotrotz werde ich auf absehbare Zeit hauptsächlich bei C++ > bleiben. > Insbesondere wenn der code schnell sein soll, habe ich dort einfach > (noch) wesentlich mehr Erfahrung. > [...] > Python gefällt mir sprachlich überhaupt nicht... Jaaa... weißt Du, für mich ist Python nur ein Werkzeug im Köcher, das sehr viele Anwendungsfälle mit guter bis ausreichender Performance löst. Wenn ich mehr Rechenleistung brauche, schreibe ich meine Software entweder in C++ oder als C++-Erweiterung für Python, in einigen Fällen greife ich auch zu Golang und in anderen auch mal zu Java- bzw. ECMAScript. Aber bei der Lektüre Deiner Ausführungen merke zumindest ich sehr deutlich, daß Du Python nicht magst, und Dich (vermutlich deswegen) auch noch nie so intensiv damit beschäftigt hast, als das Du wüßtest, was Pythons Tooling und Infrastruktur zu bieten haben. Das ist nicht schlimm, reicht IMHO aber auch nicht aus, um Dir ein realistisches Urteil zu bilden. > Wenn ich jetzt ein Problem habe, bei dem ich direkt in C++ schnell zum > Ziel komme weil mir da vllt. Qt in die Hände spielt, dann macht man es > da. Nicht "man", Du. Andere Entwickler nutzen andere Technologien, manche Python, andere Golang, noch andere C, C++, Julia, Erlang, Haskell, Clojure oder Julia, und wieder andere nehmen halt Rust. Finde ich gut, denn das Ergebnis dessen ist, daß dessen Teilnehmer in einem Wettbewerb und so unter einem gewissen Druck stehen, ihre Lösungen kontinuierlich zu erweitern und zu verbessern -- und genau deswegen können wir als Entwickler heute (meistens) frei wählen, welche Sprache, welche Frameworks und welche Libraries wir nutzen wollen.
:
Bearbeitet durch User
Ist doch immer geil, wenn der TO nach dem Eröffungspost völlig verschwunden ist. Da könnte der TO doch schreiben, dass sich das Problem erledigt hat oder er schon hier oder dazu tendiert. Aber ansonsten fand ich die Diskussion interessant.
Beitrag #7762016 wurde von einem Moderator gelöscht.
Fritz G. schrieb: > Quantenchemie, Im Hintergrund, ohne echten Quantencomputer, werden Module zur Simulation des Quantenrechners in Assembler geschrieben, wegen der . Das wirst Du aber nie machen oder reinschauen, weil dank API, Bibliotheken. Wenn grosse festgelegte Matrizen im Speicher gehalten werden mit entsprechenden Matrixoperationen, gibt es dafuer fertige ASM-Bibliotheken. Wobei wichtig dabei ist zu wissen, das der Compiler in C-geschrieben ist, der das in Maschinenbefehle umsetzt. Das ist sehr speziell und braucht der TO sicher nicht.
:
Bearbeitet durch User
Ein T. schrieb: >> Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU >> taktzyklus vermeiden. > > Wir scheinen, wie sage ich das... sehr unterschiedliche Ansätze zu > verfolgen, denn wenn ich ein IO-lastiges Problem habe, dann kümmere ich > mich zuerst um meinen I/O. Um die CPU-Taktzyklen kümmere ich mich nur, > wenn mein Problem ein CPU-lastiges ist. Du hast Dich verschrieben, oder? > ;-) Nein. I/O lastig bedeutet (vereinfacht), es müssen möglichst oft mit möglichst wenig Taktzyklen möglichst viele Bytes von der Quelle zur Senke bekommen... im Idealfall 0, weil alles per DMA über den memory controller mit maximaler Bandbreite läuft. Aber du musst diese Aussage auch im Kontext sehen! Hans W. schrieb: > Dort kann man auch recht problemlos den "cluster" über einen normalen > Internet uplink verbinden und ihn dann mining-pool nennen. > > Hast du aber ein IO-lastiges Problem, dann willst du jeden unnötigen CPU > taktzyklus vermeiden. > > Und gerade das macht Rust nun wieder interessant. Und hier dann weiter lesen... Ein T. schrieb: >> Aktuell scheint C++ in benchmarks noch etwas schneller als Rust zu sein. >> Ich behaupte aber, dass die von Rust geforderte Disziplin das >> Durchschnittsprogramm schneller als eines in C++ machen sollte. > > Naja... Rechnen müssen sie am Ende doch alle, und selbst mit > größtmöglicher Optimierung kosten Berechnungen nun einmal Taktzyklen. > Für ein paar Prozent höherer Rechenleistung von einer etablierten > Sprache mit etlichen fertigen Libraries und Frameworks auf eine andere > Sprache zu wechseln und dafür dann womöglich signifikante Teile einer > Applikation neu schreiben .... Meine Aussage war hier nur, dass Rust gewisse Eigenschaften besitzt, die mMn automatisch zu einem disziplinierten Programmieren führen und dadurch zu (im Schnitt) effizienteren Programmen. Meiner Erfahrung nach sind alle Optimierungs-"Hacks" am Ende kontraproduktiv, weil sie "global" (zu lesen: im Kontext der gesamten Applikation) betrachtet zu semioptimalen Lösungen führen. z.B lustige Pointer-Casts mit komplizieren Array zugriffen und dann brutalen Typumwandlungen meine ich damit. Das passt dann entweder nur gut für 1nen speziellen Anwendungsfall oder führt dann zu Aussagen wie "Der Datenfluss schaut an der Stelle so 'seltsam' aus, weil er historisch gewachsen ist". Meiner Einschätzung nach hilft dagegen nur Disziplin. Wenn die stimmt, sind meistens (Achtung: MEISTENS!) die Optimizer so gut, dass sie insgesamt mehr Performance rausholen wie jeder "Hack". Die Sprache ist da meist ziemlich egal. Nirgends stand da was von neu schreiben, libs weglassen udgl.! Ich habe auch kein "Rust rulez!!!11!!" abgelassen! Dinge wie die strenge Typisierung oder den borrow checker meinte ich. So etwas in einer Sprache durchzuziehen kann dem Optimizer massiv helfen. Und das finde ich interessant... nicht mehr, und nicht weniger! Ein T. schrieb: > Aber bei der Lektüre Deiner Ausführungen merke zumindest ich sehr > deutlich, daß Du Python nicht magst, und Dich (vermutlich deswegen) auch > noch nie so intensiv damit beschäftigt hast, als das Du wüßtest, was > Pythons Tooling und Infrastruktur zu bieten haben. Das ist nicht > schlimm, reicht IMHO aber auch nicht aus, um Dir ein realistisches > Urteil zu bilden.... Oh, ich glaube, ich habe durchaus genug Erfahrung in Python um mir ein Urteil zu bilden... Aber um das geht es mir aber nicht! Mir gefällt die Sprache nicht. Punkt! Habe ich auch deutlich geschrieben: Ein T. schrieb: >> Python gefällt mir sprachlich überhaupt nicht... Was nutzt mir Infrastruktur und Tooling, wenn ich sie nicht als elegant empfinde und mir Grammatik und Syntax auch nicht liegen. Leider ist dieses Argument für 99.8% der Python "Verehrer" nicht greifbar. Ich mag auch Java nicht. Dort gehts mir auch nicht um Swing, Gradle oder irgendeiner anderen Komponente in diesem Ökosystem. Ich meine damit die Sprache und die Design Pattern, die dort "vorgegeben" werden. Ein T. schrieb: >> Wenn ich jetzt ein Problem habe, bei dem ich direkt in C++ schnell zum >> Ziel komme weil mir da vllt. Qt in die Hände spielt, dann macht man es >> da. > > Nicht "man", Du. Andere Entwickler nutzen andere Technologien Sorry, Typo... 1 von 4 mal das falsche Pronomen... sorry! Ein T. schrieb: > Andere Entwickler nutzen andere Technologien, manche > Python, andere Golang, noch andere C, C++, Julia, Erlang, Haskell, > Clojure oder Julia, und wieder andere nehmen halt Rust. Und warum wirfst du mir dann vor, dass ich Python mir einfach nicht gut genug angesehen habe? Ich weiß nicht, warum die Python Community mit solchen Nachdruck zu missionieren versucht. Hans W. schrieb: > Was ich sagen will: Das eigentliche Problem diktiert die Sprach-Wahl. > Nicht die verfügbaren Libs (es gibt so ziemlich jede schnelle Lib in > jeder sprache) oder die zeit, die man für's schreiben braucht oder > ähnliches. Hier steht's doch! Nimm das für dein Problem richtige Mittel. Aber jeder, der ohne überlegen Python (zu ersetzen mit beliebiger anderer Sprache/Framework/OS/...) nimmt, fliegt bei mir raus. Ich denke da auch an die ganzen "excel tools", die mir bei Kunden unterkommen. Absolut nicht zu warten, und wenn man eines geschickt bekommt, ist man immer der "Dumme", weil man Excel nicht auf die einzige vernünftige Art und Weise konfiguriert hat. Ganz schlimm wirds, wenn man dann sagt, man nutze MS Excel gar nicht... Ein T. schrieb: > Allerdings gibt es nichts, das Python daran hindern würde, Interconnects > mit Infiniband oder [1248]00GBASE-X zu benutzen... Und genau das meinte ich mit Hans W. schrieb: > "aber python > hat doch..." Wenn du wie du oben sagst, fast so schnellen code in python wie z.B (!) in C++ bekommen würdest, egal wie (!), dann ist das eben nur fast so schnell. Ich habe nicht gesagt, dass es nicht ginge, ich habe nur gesagt, dass es Fälle gibt, wo eben ein callback vom Kernel in den userspace, in einen Python interpreter im Falle von Infiniband Interlinks vllt. nicht die optimale Lösung wäre... Klar, wenn du "nur" schnell ein "paar" GB austauschen musst... ja mach halt... low-latency IPC...never! Aber jetzt nochmal um auf den TO (falls er noch mitliest) einzugehen: Python mag ja recht nett sein... so wie Lua auch nett ist... aber wenn die Hauptarbeit dort drinnen "laufen" soll, dann ist das ungeeignet. Soll heißen, einen iterativen Solver schreibt man damit nicht (auch wenn es ginge... kann man auch in Excel). Das füttern des Selben... wenn _ich's_ danach nicht warten muss... warum nicht... gibt ja auch genügend "Manpower" die man sich dazu "einkaufen" kann. Das(!) ist der einzige für mich(!) wirklich relevante Vorteil von Python! Es gibt viele Code-Monkeys! Ich bin aber kein Software unternehmen, daher ist dieser für mich aber nicht wirklich von Bedeutung. Fortran lebt auch nicht nur wegen Legacy-Code! Da gibt es extrem hoch optimierte Compiler und es gibt Leute, denen gefällt auch diese Sprache sehr gut. Ich finde gewachsenen Fortran Code auch... hmmm... stark gewöhnungsbedürftig. 6 Zeichen Variablen Namen sage ich da nur... aber manchen gefällt sowas. Grundlegen gilt aber: Wenn du nicht akademisch arbeitest, dann zählt der Output. Damit meine ich nicht die Arbeit, die du verrichtest, sondern das Geld, was am Ende des Monats am Firmenkonto übrig bleibt. Ich habe oben beispielhaft 2 konträre Szenarien beschrieben, bei dem 1mal der angebliche Zeitvorteil von Python (den ich für mich persönlich nicht sehe) schon bei einer Milchmädchenrechnung egal ist. Beim angedeuteten zweiten Szenario aber eben nicht. Daher: Ein T. schrieb: > Hans W. schrieb: >> Ich glaube, da muss man deutlich differenzieren! > > Das glaube ich auch. 73
:
Bearbeitet durch User
Hans W. schrieb: > Was nutzt mir Infrastruktur und Tooling, wenn ich sie nicht als elegant > empfinde und mir Grammatik und Syntax auch nicht liegen. Kann zuweilen trotzdem wichtiger sein. Ich mag Git nicht, aber ich benutze es – weil Infrastruktur und Tooling drum herum den eigentlichen Mehrwert bringen. Ich mag auch diese Einrückungs-Verbissenheit von Python nicht, trotzdem ist Python aufgrund dessen, was es rundherum gibt oft für mich das Mittel der Wahl. Als Interface zu dem (meiner Meinung nach völlig undurchdringlichen) Fortran-Code von linpack etc. hilft es mir auf jeden Fall, wenn ich ein derartiges Problem lösen muss, und im Gegesatz zu Matlab (die auch so ein Interface gebaut haben) kann ich es ohne irgendein Lizenzgehampel einfach so benutzen.
Hallo, wenig bekannt und nicht unbedingt für intensive Rechenanwendungen oder hohe Datenmengen: https://en.wikipedia.org/wiki/Hoc_(programming_language) https://en.wikipedia.org/wiki/The_Unix_Programming_Environment http://ftp.math.utah.edu/pub/hoc/ https://neuron.yale.edu/neuron/static/docs/refman/hoc.html Läuft unter jedem Linux/Unix mit C-Compiler und yacc oder bison Parser.
Jörg W. schrieb: > und im Gegesatz zu > Matlab (die auch so ein Interface gebaut haben) kann ich es ohne > irgendein Lizenzgehampel einfach so benutzen. Kennst Du den Matlab Clone octave? https://octave.org/
Jörg W. schrieb: > aber ich benutze es – weil Infrastruktur und Tooling > drum herum den eigentlichen Mehrwert bringen Ja, damit kann ich gut, und so sehe ich das auch. Ich nutze Python deshalb auch dort, wo es nicht anders geht (z.B. KiCad scripts statt selbst parsen...wobei ich das in 1nem fall auch gemacht habe eben um von den KiCad Binaries unabhängig zu sein. ) In anderen Fällen nutze ich Deno. Das ist für mich 1. angenehmer und 2. bietet es über direkte Bindings, WASM cross-kompilate oder auch der NodeJS Kompatibilität für meine web-nahen Anwendungsfälle eigentlich ein super simples Framework. Ich behaupte jetzt einmal, dass sich für web-nahe Probleme python und NodeJS/Deno nicht viel unterscheiden. Einfache Frameworks gibts für beiden. Da ist das wirklich nur eine "Geschmackssache" welche der beiden "Frameworks" einem besser liegt. Genau die Fälle gibt es aber häufiger wie man meinen mag und ich sträube mich vehement hier Python zu nutzen... weil mir die Sprache an sich nicht gefällt! Jörg W. schrieb: > Als Interface zu dem (meiner Meinung nach völlig > undurchdringlichen) Fortran-Code von linpack etc. hilft es mir auf jeden > Fall, wenn ich ein derartiges Problem lösen muss von Linpak, lapak oder gar BLAS bin ich komplett abgekommen. Eigen3 kann ich da empfehlen, wenn man C++ mag... Geht aber auch nur, wenn man nicht z.B. auf die Intel MKL angewiesen ist. Schnell ist es auf jedenfall...schneller als die meisten BLAS implementierungen. Ich habe aber extrem selten mit einzelnen Matrix operationen zu tun. Meistens ist das eine Loop mit Updates von irgendwelchen Vectoren, die dann irgendwelche Matrizen "würzen". min 50% der Zeit geht da für's update der Vektoren drauf... eher 75%... Sowas in Python???? Ich weiß nicht... Als Matlab Ersatz... bin dabei! (also im Geiste... für mich reicht der gelegentliche Start von Maxima oder Octave).
Jörg W. schrieb: > aber ich benutze es – weil Infrastruktur und Tooling > drum herum den eigentlichen Mehrwert bringen Ja, damit kann ich gut, und so sehe ich das auch. Ich nutze Python deshalb auch dort, wo es nicht anders geht (z.B. KiCad scripts statt selbst parsen...wobei ich das in 1nem fall auch gemacht habe eben um von den KiCad Binaries unabhängig zu sein. ) In anderen Fällen nutze ich Deno. Das ist für mich 1. angenehmer und 2. bietet es über direkte Bindings, WASM cross-kompilate oder auch der NodeJS Kompatibilität für meine web-nahen Anwendungsfälle eigentlich ein super simples Framework. Ich behaupte jetzt einmal, dass sich für web-nahe Probleme python und NodeJS/Deno nicht viel unterscheiden. Einfache Frameworks gibts für beiden. Da ist das wirklich nur eine "Geschmackssache" welche der beiden "Frameworks" einem besser liegt. Genau die Fälle gibt es aber häufiger wie man meinen mag und ich sträube mich vehement hier Python zu nutzen... weil mir die Sprache an sich nicht gefällt! Jörg W. schrieb: > Als Interface zu dem (meiner Meinung nach völlig > undurchdringlichen) Fortran-Code von linpack etc. hilft es mir auf jeden > Fall, wenn ich ein derartiges Problem lösen muss von Linpak, lapak oder gar BLAS bin ich komplett abgekommen. Eigen3 kann ich da empfehlen, wenn man C++ mag... Geht aber auch nur, wenn man nicht z.B. auf die Intel MKL angewiesen ist. Schnell ist es auf jedenfall...schneller als die meisten BLAS implementierungen. Ich habe aber extrem selten mit einzelnen Matrix operationen zu tun. Meistens ist das eine Loop mit Updates von irgendwelchen Vectoren, die dann irgendwelche Matrizen "würzen". min 50% der Zeit geht da für's update der Vektoren drauf... eher 75%... Sowas in Python???? Ich weiß nicht... Aber als interatkiver Matlab Ersatz. Da wäre ich dabei! Also im Geiste... Ich bin da eher bei Maxima oder Octave mit entsprechender GUI. 73
Hans W. schrieb: > Sowas in Python???? Das Python Problem ist halt: du kannst nicht mal eben den Compiler bzw Interpreter umschreiben und "Maschinen-Tunings" gehen halt auch nicht, sondern man kann meist nur das nehmen, was schon da ist. Was am Ende dazu führt, dass etliche Python Programmierer verzweifelt fragen, wie kann ich mein Programm schneller rechnen lassen. https://www.netlib.org/lapack/lug/node140.html https://stackoverflow.com/questions/68234466/scipy-blas-lapack-force-use-of-avx-instruction-set https://discourse.julialang.org/t/about-julias-inline-assembly-usage/30352 Beim Cell hatte sich ja herausgestellt, dass der enorm von der Asm-Programmierung profitiert. Haskell parallelisiert zwar hervorragend, aber das braucht man vielleicht nicht immer und der Asm-Zugang ist da auch nicht mal eben abgewickelt. Und in der Parallel-Rechnung ist Asm eigentlich ziemlich schwierig. Was will man Leuten erzählen, die meinen, man kann mit Python alles machen, schließlich ist Python auch bewährte effektive Hackerprogrammiersprache? Oder was wollte man Mathematikern erzählen, die einfach mal schneller rechnen möchten, als das, was die vorhandenen Python-Werkzeuge im Angebot haben? Früher war Basic für vieles gut, es gab auch Interpreter-Code auf Heftdisketten, der war recht langsam. Allerdings konnte man Basic auch compilieren, nur waren die Compiler nicht immer leicht zu bekommen. Die Hex und Asm-Ebene nutzen konnte man auch, und so konnte man, wenn man wollte, mit Compiler und Asm-Tricks recht schnellen Basic-Code hinbekommen. Basic (oder Pascal) wurde(n) auch noch lange in der Schul-IT eingesetzt Haskell kann man ganz gut Codetechnisch optimieren. Dadurch kann man auch einiges lernen, was bei anderen Programmiersprachen nicht so deutlich rüberkommt. Aber tatsächlich, die Beliebtheit von Python ist auch ein Punkt - nur dass der eben eine gewisse Grenze hat. Performance-Tuning kann man nur per Bib machen, und per Code eher nur, wenn man die Möglichkeiten der Code-Optimierungen von Haskell kennt. Wobei bei Haskell vor allem die Doubles (und nicht die Floats) eingesetzt werden sollten, wegen einer besseren Performance. Die Probleme mit Fließkommazahlen werden dann allerdings nicht behoben. Fließkommafehler bei Haskell? http://wiki.haskell.org/Performance/Floating_point scheinbar nicht bekannt. Ganz anders Python: https://docs.python.org/3/library/decimal.html Wird allerdings schwieriger, wenn es um das schneller Rechnen geht. Ich denke, die traditionellen Werkzeuge sind nicht umsonst traditionell geblieben. Wegen dem OOP, oder weil es ja auch Java (+ die JVM) gibt könnte man Python-Programmierer C++ nahelegen - sofern die gängigen Methoden nicht ausreichen. C++ glänzt ja auch ein wenig als Funktions-Truthahn. Wenn man erstmal drin ist, hat man eine ganze Menge Möglichkeiten und ich würde die Lernzeit (so 2 Jahre) auch nicht als verschwendet ansehen.
Fritz G. schrieb: > Welche Programmmiersprache wird heute für Software mit hohem numerischen > Rechenaufwand, beispielsweise Wetter- und Klimasimulationen oder > Quantenchemie, verwendet? Eigentlich wollte ich schreiben guck in die Stellenanzeigen vom DWD. Aber guck halt in das Wettermodel vom DWD: ICON. Das gibt es anscheinend als OpenSource seit diesem Jahr. https://icon-model.org bzw. zum git Repository https://gitlab.dkrz.de/icon/icon-model
Mano W. schrieb: > Aber guck halt in das Wettermodel vom DWD: ICON. müffelt nach Fortran und C (C wohl u.a. auch für CUDA) https://fortran-lang.org/en/learn/os_setup/install_gfortran/ https://fortran-lang.org/en/learn/quickstart/hello_world/
Alexander S. schrieb: > Jörg W. schrieb: >> und im Gegesatz zu >> Matlab (die auch so ein Interface gebaut haben) kann ich es ohne >> irgendein Lizenzgehampel einfach so benutzen. > > Kennst Du den Matlab Clone octave? > https://octave.org/ Kenne ich, aber Python ist am Ende universeller.
Rbx schrieb: > Früher war Basic für vieles gut, Jörg W. schrieb: > aber Python ist am Ende universeller. Das ist glaube ich der Punkt. Leute (da zähle ich mich selber natürlich auch dazu!) sind faul und nehmen das was bequem ist. Das finde ich ist aber oft das Problem. "Nimm einen AVR" "Mach in Python" "Frag ChatGPT" Das sind für mich vergleichbare allgemeine "Empfehlungen". Optimal sind solche Empfehlungen oft/meist nicht... Müssen sie oft/meist auch nicht. Ich für mich mag halt Python nicht. Ich hab für mich aber eigentlich für alle Problemchen gute Lösungen gefunden die mir weniger Kopfweh bereiten als diese für mich seltsame Sprache. Aber das ist jetzt wieder OT. 73
Hans W. schrieb: > Optimal sind solche Empfehlungen oft/meist nicht... Müssen sie oft/meist > auch nicht. So isses. > Ich für mich mag halt Python nicht. Ich mag es auch nicht so sehr (und für Textbearbeitung mit regulären Ausdrücken greife ich nach wie vor lieber zu Perl), aber habe mich damit auch irgendwie arrangieren können – genauso wie halt mit Git. FORTRAN war anders seltsam :-), aber ich bin froh, dass ich das nicht mehr machen muss. Da war ich schon vor über 30 Jahren froh drüber. ;-) Die Produktivität stieg mit dem damaligen Pascal-Compiler um ein Vielfaches, und zu der Zeit war ich sicher noch unvoreingenommen gegenüber FORTRAN.
Jörg W. schrieb: > genauso wie halt mit Git Ich spiele da übrigens mit dem Gedanken wieder zu Mercurial zurück zu wandern. Ich finde persönlich Mercurial "besser". HgGit erlaubt sogar lokal Mercurial und remote git zu verwenden. Mir ist git einfach zu "komplex"/"universell". Mercurial beschränkt sich gefühlt mit nur 1/10tel der Funkionalität und trifft meine Arbeitsweise irgendwie besser. Bei mir hängt aber mein komplettes Unternehmen daran... Nennen wir es jugendlichen Leichtsinn und im Nachhinein gute Entscheidung jedes Kunden Projekt in ein gut repo am NAS zu legen (zum verständnis: git ist meine Lösung über mehrere Systeme die Projekt Daten konsistent zu halten), statt einfach nur eine Verzeichnisstruktur anzulegen. Aber da unternimmt man so einen Umstieg erst, wenn der Leidensdruck hoch ist. Wobei mich HgGit dazu verleitet, da es transparent wäre. An Server darf weiter GitTea laufen und ich bekomme mein Mercurial zurück :) Problematisch ist aber das Shell Script Set, das meine Arbeit quasi fool-proof macht. Man muss halt dauernd viel neues ausprobieren, sonst landet man im "haben wir/ich immer so gemacht"-sumpf. Das erfordert aber wieder die Konsequenz zu sagen "lass ich bleiben" oder "bringt mir signifikante Vorteile und zieh ich jetzt konsequent durch". Ansonsten blockiert man sich durch die dauernden veränderungen selbst. 73
Hans W. schrieb: > Ich finde persönlich Mercurial "besser". Ich auch, aber Mozilla ist beispielsweise von Mercurial zu Git gegangen, weil sie mit Mercurial in Performanceprobleme gelaufen sind. Aber lass uns das bitte in einen eigenen Thread nehmen, wenn du es weiter diskutieren möchtest.
Beitrag #7762441 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Giovanni schrieb: >> JULIA hat Suchtpotential - erfordert aber ein Umdenken. > > Inwiefern? OK, nach Fortran IV, Pascal, Octave, Python jetzt Julia. Julia setzt auf multiple dispatching - satt object oriented programming. Das ist schon mal ganz anders, eröffnet aber viele Möglichkeiten. Was mich aber beeindruckt hat, ist MetaProgramming. Also Programmteile erst zur Laufzeit zu erstellen. Interessant in der Simulationen & ML, wo Gleichungen symbolisch differenziert werden müssen. siehe : https://github.com/sciml Auch Julia verwendet die Standards wie BLAS, LAPACK, ..., hat Schnittstellen zu allen bekannten Solvern und auch zu Python Bibliotheken wie MATPLOTLIB. MetaProgramming macht das Ganze für mich so spannend.
Jörg W. schrieb: > Hans W. schrieb: >> Ich finde persönlich Mercurial "besser". > > Ich auch, aber Mozilla ist beispielsweise von Mercurial zu Git gegangen, > weil sie mit Mercurial in Performanceprobleme gelaufen sind. > > Aber lass uns das bitte in einen eigenen Thread nehmen, wenn du es > weiter diskutieren möchtest. Weniger OT wie man meinen würde. https://wiki.mercurial-scm.org/OxidationPlan Mit zahlen hinterlegt ist auch einiges hier drin zu finden: https://mercurial.paris/download/Rust%20in%20Mercurial%20in%202023.pdf Da steht ziemlich genau warum sie mit Python unzufrieden sind, was sie schon alles probiert haben, und wo die Reise hin gehen könnte. Ist imho lesenswert, weil da auch viel Hintergrundwissen drinnen steht 73
:
Bearbeitet durch User
Sheeva P. schrieb: > Giovanni schrieb: >> JULIA hat Suchtpotential - erfordert aber ein Umdenken. > > Inwiefern? Fragst du jetzt nach dem Suchtpotential, oder dem Umdenken? Ich habe den Verdacht, Worte bringen hier nicht viel. Ich kann mir zwar ein paar Eckpunkte denken - aber ich verstehe, so meine ich, in etwa schon den Spaßfaktor allein vom Durchlesen der Doku. Außerdem kann Julia von Haus aus plotten und Haskell eben nicht, ein nicht zu verachtender Vorteil, finde ich. (der übrigens auch für Python spricht) Jörg W. schrieb: > FORTRAN war anders seltsam :-) Fortran war der große Bruder von Basic. Oder umgekehrt, war Basic eigentlich ein Fortran für die kleinen Heimcomputerfreunde. Wenn dann in den Schulen Basic präsent war, dann war der Umstieg, zumindest in der Matheabteilung nicht so weit, außerdem hat Fortran ein paar Goodies für die Mathe-Programmierung, die es in anderen Programmiersprachen nicht gab. Zu allem Überfluss kann man Julia mit Fortran möglicherweise super kombinieren, falls man mal einen (sequentiellen) Turbo braucht ;)
:
Bearbeitet durch User
Rbx schrieb: > Jörg W. schrieb: >> FORTRAN war anders seltsam :-) > Fortran war der große Bruder von Basic. Oder umgekehrt, war Basic > eigentlich ein Fortran für die kleinen Heimcomputerfreunde. > Wenn dann in den Schulen Basic präsent war, dann war der Umstieg, > zumindest in der Matheabteilung nicht so weit, außerdem hat Fortran ein > paar Goodies für die Mathe-Programmierung, die es in anderen > Programmiersprachen nicht gab. "computed GOTO" und "arithmetic IF" zum Beispiel. :-) SCNR …
Jörg W. schrieb: > computed GOTO" und "arithmetic IF" zum Beispiel. :-) Immerhin kann man sich recht gut die Übersetzung nach Assembler vorstellen. Das geht bei verschachtelten Schleifen nicht mehr so gut und noch schwieriger bei schlimmeren Abstraktionen wie OOP z.B. Aber OOP..(wird das dann nicht auch leichter verständlich?) .. Jedenfalls kann man bei neueren Fortran-Ausgaben auch OOP nutzen, und schaut man sich Diskussionen an, kann man doch Lust bekommen, sich seine eigenen Dokus zu OOP nochmal anzusehen. Oder man denkt sich so: fehlen vielleicht noch ein paar richtig gute Java-Programmierer im Team? https://www.researchgate.net/publication/2644517_Performance_Benchmarking_of_Object_Oriented_MPI_OOMPI_Version_102g https://fortran-lang.discourse.group/t/a-cautionary-tale-on-object-oriented-programming/5674
:
Bearbeitet durch User
Hans W. schrieb: > Aber um das geht es mir aber nicht! > Mir gefällt die Sprache nicht. Punkt! Die Vielzahl Deiner Ausrufezeichen und Dein "Punkt!" scheinen mir Indizien dafür zu sein, wie emotional Du an die Sache herangehst. > Und warum wirfst du mir dann vor, dass ich Python mir einfach nicht gut > genug angesehen habe? Ich kann nicht für den anderen Herrn sprechen, bemerke jedoch dass Du auf kein einziges seiner Sachargumente eingehst. Zum Beispiel hattest Du behauptet dass Python sich nicht in verteilten Clustern benutzen ließe. "Ein Typ" hat mehrere Ansätze aufgezeigt mit denen genau das funktioniert. Aber obwohl Du sehr viele Worte schreibst gehst du mit keinem einzigen darauf ein. Des Weiteren ist es ja so dass Du Dinge behauptest die einfach falsch sind, wie zum Beispiel das mit dem Clustering. Da gibt es nur zwei Möglichkeiten: entweder Du weißt es nicht besser, hast Dir Python also "einfach nicht gut genug angesehen", oder Du lügst bewusst. > Ich weiß nicht, warum die Python Community mit solchen Nachdruck zu > missionieren versucht. Ich hatte nicht den Eindruck dass "Ein Typ" missioniert hätte. Er hat nur Deine Falschaussagen (siehe oben) richtig gestellt. Mir dagegen fallen die Emotionalität und die Intensität auf, mit der manche Menschen gegen Python missionieren. Emotionen scheinen dabei oft eine viel größere Rolle zu spielen als eine professionell sachliche Betrachtung.
Rbx schrieb: > Das Python Problem ist halt: du kannst nicht mal eben den Compiler bzw > Interpreter umschreiben und "Maschinen-Tunings" gehen halt auch nicht, > sondern man kann meist nur das nehmen, was schon da ist. In C, C++ oder Haskell schreibt man seinen Compiler oder Interpreter um? Und was hindert einen Python-Entwickler daran, andere Bibliotheken zu nutzen? > Was am Ende > dazu führt, dass etliche Python Programmierer verzweifelt fragen, wie > kann ich mein Programm schneller rechnen lassen. > > https://www.netlib.org/lapack/lug/node140.html > https://stackoverflow.com/questions/68234466/scipy-blas-lapack-force-use-of-avx-instruction-set > https://discourse.julialang.org/t/about-julias-inline-assembly-usage/30352 Lustig dass kein einziger Deiner Links auch nur entfernt etwas mit Python zu tun hat. Hast Du Deine eigenen Links nicht gelesen?
Sheeva P. schrieb: > Lustig dass kein einziger Deiner Links auch nur entfernt etwas mit > Python zu tun hat. Lustig, dass es in diesem Thread überhaupt nicht um vorrangig Python geht.
als Beitrag zur Diskussion über verschiedene Programmiersprachen. https://jcarroll.com.au/2024/10/26/polyglot-maxxie-and-minnie/ APL kannte ich bisher nicht. Finde die Syntax aber cool.
Rbx schrieb: > Sheeva P. schrieb: >> Lustig dass kein einziger Deiner Links auch nur entfernt etwas mit >> Python zu tun hat. > > Lustig, dass es in diesem Thread überhaupt nicht um vorrangig Python > geht. Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor? Beitrag "Re: Welche Programmiersprache für numerische Rechnungen"
Giovanni schrieb: > APL kannte ich bisher nicht. Finde die Syntax aber cool. Cool im Sinne von Cool oder im Sinne von WTF??? Für mich ist das, was im Screenshot zu sehen ist, seehr nahe an Brainfuck. Für gelernte Mathematiker mag das anders sein.
Rbx schrieb: > Was will man Leuten erzählen, die meinen, man kann mit Python alles > machen, schließlich ist Python auch bewährte effektive > Hackerprogrammiersprache? Nebenbei stellt sich mir gerade die Frage warum Du glaubst dass man Python-Entwicklern unbedingt etwas erzählen müsse? > Wobei bei Haskell vor allem die Doubles (und nicht die Floats) > eingesetzt werden sollten, wegen einer besseren Performance. > Die Probleme mit Fließkommazahlen werden dann allerdings nicht behoben. > Fließkommafehler bei Haskell? > http://wiki.haskell.org/Performance/Floating_point > scheinbar nicht bekannt. Ganz anders Python: > https://docs.python.org/3/library/decimal.html Hast Du Deine Links nicht gelesen oder nicht verstanden? In Deinem Link steht nicht dass Double eine bessere Performance hätte als Float. Da steht dass die Verwendung von Double "rarely a speed disadvantage" hätte also: "selten einen Geschwindigkeitsnachteil". Von einem Geschwindigkeitsvorteil wie Du ihn hier behauptest steht dort nichts. Dazu steht in der Dokumentation zum Glasgow Haskell Compiler (GHC) auch noch diese Aussage [1] zum Datentyp Double: "It is desirable that this type be at least equal in range and precision to the IEEE double-precision type". Haskell orientiert sich also an haargenau demselben Standard (IEEE-754) wie Python. [1] https://hackage.haskell.org/package/base-4.20.0.1/docs/GHC-Float.html#g:8
Klaus schrieb: > Für gelernte Mathematiker mag das anders sein. Ich glaub für die ist das auch gemacht... :)
Sheeva P. schrieb: > Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor? Sheeva P. schrieb: > Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor? > > Beitrag "Re: Welche Programmiersprache für numerische Rechnungen" Das ergibt sich aus dem Zusammenhang. Tut mir ja leid, dass du den Zusammenhang mit der Ausgangsfrage nicht verstehst, und deswegen einen auf Graf Zahl machen musst. Man könnte ja auch ein MinMax-Prinzip vermuten, sich selber gar nicht anstrengen, wenn es um tieferes Verständnis geht - und wenn schwierige Fragen auftauchen, einfach vom Thema weg antworten, Mutter beleidigen, publikumswirksame Wertverletzungen unterstellen usw. Oder einfach kurz: suchst du Streit, oder was? Versuche lieber mal ein paar Mitlesern zu erklären, wie du deine Pythonprogramme beschleunigst, wenn es um Wetterberechnung, Bitcoin oder einfach Wirtschafts-Hpc geht.
> "computed GOTO" und "arithmetic IF" zum Beispiel. :-)
Nee, COMPLEX!
Ich hab nen Schein in Fortran gemacht, ich weiss das. :-D
Vanye
Rbx schrieb: > Sheeva P. schrieb: >> Warum kommt das Wort Python dann neun Mal in Deinem Beitrag vor? >> >> Beitrag "Re: Welche Programmiersprache für numerische Rechnungen" > > Das ergibt sich aus dem Zusammenhang. Welcher Zusammenhang? Du schreibst einen Beitrag in dem neun (9) Mal das Wort Python vorkommt und in dem Du behauptest, das "Python Problem" sei dass man "nicht mal eben den Compiler oder Interpreter umschreiben" könne. Auf meine verwunderte Gegenfrage ob man das denn in C, C++ oder Haskell tun würde, hast Du bisher leider keine Antwort gefunden. Direkt danach behauptest Du, dass "etliche Python Programmierer verzweifelt fragen, wie kann ich mein Programm schneller rechnen lassen", und postest dann direkt drei Links. Naiv wie ich bin war ich jetzt davon ausgegangen dass Deine Links Deine Behauptung mit den "etlichen" belegen würden. In Wirklichkeit geht es in Deinem Links aber um LAPACK, um die Nutzung von Intels AVX- und AVX2-Instruktionssätze und im dritten um die Sprache Julia. Meine Gegenfrage was Deine Links mit Python zu tun haben, über das Du vorher und nachher redest, belehrst Du mich dass es in diesem Thread nicht vorrangig um Python gehe. Und meinen Hinweis, dass Du zuvor Deinerseits sehr ausführlich über Python geredet hast, konterst Du mit: > Oder einfach kurz: suchst du Streit, oder was? Nö, dazu sehe ich bisher noch keine Veranlassung. Allerdings befürchte ich, dass es zum Streit kommen kann, wenn Du weiterhin zusammenhanglosen Bullshit über Python erzählst und den mit wirren Links auf vollkommen andere Themen zu "belegen" versuchst. Wenn Du Deinerseits keinen Streit suchst könntest Du es einfach unterlassen solchen Unfug zu schreiben und alles wäre fein. Denn ich habe wirklich überhaupt kein Problem damit wenn Du und Hans Python nicht mögt. Niemand muss irgend etwas mögen. Nicht einmal Python. Aber wenn Ihr Bullshit darüber sabbelt, stelle ich das richtig. Zweifellos lesen hier nämlich Leute mit die sich nicht so gut auskennen und halten Euren Bullshit dann womöglich noch für zutreffend. Wir wollen doch nicht irreführen, oder? > Versuche lieber mal ein paar Mitlesern zu erklären, wie du deine > Pythonprogramme beschleunigst, wenn es um Wetterberechnung, Bitcoin oder > einfach Wirtschafts-Hpc geht. Für Interessierte gibt es da ein wundervolles Buch namens "High Performance Python" [1], das verschiedene performancekritische Aspekte der Sprache wie Speicherverwaltung, Parallelisierung, Profiling, die Kompilation von Python- in Maschinencode, die Nutzung von Clustern und weitere Themen anspricht. Für Anfänger ist dieses Buch nicht die erste Wahl. Ich selbst verwende je nach Aufgabe Frameworks wie numpy, Numexpr, scipy, Tensorflow/Keras, PyTorch, Caffe2, spaCy, Theano, Pyro, PyBrain, Cuda und natürlich Pandas, pandarallel und neuerdings auch Vulkan. Wenn die alle nicht bieten was ich brauche schreibe ich mir eigene Erweiterungen in C oder Cpp, letztere meistens mit Boost.Python. Häufig birgt auch der optimierte Pypy-Interpreter mit seinem Just-in-Time-Compiler grosse Performancegewinne. Die Compiler nuitka und numba wurden in diesem Thread IIRC schon genannt? [1] https://www.amazon.com/High-Performance-Python-Performant-Programming/dp/1492055026
Giovanni schrieb: > Julia setzt auf multiple dispatching - satt object oriented programming. > Das ist schon mal ganz anders, eröffnet aber viele Möglichkeiten. > Was mich aber beeindruckt hat, ist MetaProgramming. Also Programmteile > erst zur Laufzeit zu erstellen. Interessant in der Simulationen & ML, wo > Gleichungen symbolisch differenziert werden müssen. > siehe : https://github.com/sciml Lieben Dank für die Erklärungen und den Hinweis. Was ich bisher gesehen habe gefällt mir ausgesprochen gut. Ich habe gerade die Library Redis.jl [1] angeschaut, die benutzt einfach die Funktionen set() und get() mit einer Instanz von RedisConnection() als erstem Argument. Verstehe ich das mit dem multiple dispatching richtig, dass mehrere Pakete Funktionen get() und set() definieren und Julia an den Argumenttypen erkennt, welche Methode aus welchem Paket aufgerufen wird? Das würde ja dem Überladen von Methoden aus C++ ähneln, oder bin ich auf dem Holzweg? [1] https://github.com/JuliaDatabases/Redis.jl
Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel Schweiß und Blut investieren musste. Das führt dann zu solch emotionalen Reaktionen. Es ist doch so, das wir in einer arbeitsteiligen gesellschaft leben. Es gibt Leute die können super effiziente Programme für das lösen numerischer Gleichungen schreiben, es reicht aber wenn das ein paar in der Sprache ihrer Wahl tun. Andere haben Probleme, die sie numerisch lösen wollen, die befassen sich mit dem Problem, nicht mit bare metal Programmierung. Der Zeitaufwand dich da in alle Details einzuarbeiten ist viel zu groß und 99,9999% werden nix besseres abliefern, als es schon gibt. Rbx gehört sicher zu den 0,0001%. Dafür hat er halt Probleme vernünftige rote Linien in seine Argumentation zu bringen.
Sheeva P. schrieb: > Das würde ja dem Überladen von Methoden aus C++ ähneln, > oder bin ich auf dem Holzweg? Sehe ich auch so. ein sehr einfaches Beispiel:
1 | show wird immer aufgerufen wenn ich "MeineDaten" anzeigen will |
2 | struct MeineDaten |
3 | a::String |
4 | end |
5 | |
6 | function Base.show(io::IO, info::MeineDaten) |
7 | printstyled("$(info.a)", color=:red) |
8 | ... |
9 | end |
https://github.com/bkamins für Einsteiger DataFrames https://www.juliabloggers.com/ immer mit interessanten Beiträgen. https://github.com/CedarEDA/CedarSim.jl soll ein Spice Simulator werden. Hier geht man aber schon in den Compiler rein um die Performance zu verbessern (nichts für mich). Generelle Frage: Programmiersprachen sind ja nicht statisch, sondern werden immer wieder erweitert. * Wer verwendet den vollen Sprachumfang von Python 3.12?? Ehrlich. Ich komme mit dem Umfang Python2.7 aus. * Wer verwendet OOP in Fortran? * Wer verwendet OOP in MATLAB? Mein Eindruck: Die Sprachen werden sich immer ähnlicher. Ob OOP in FORTRAN Sinn macht, ist mir nicht klar.
:
Bearbeitet durch User
> Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit > Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel > Schweiß und Blut investieren musste. Ich stimme dir zu wenn es sich um gute abgeschlossene Libraries handelt und eine Mathelibrarie die viele Menschen auf der Welt nutzen gehoert sicher dazu. Ja, dann ist das ein Vorteil. Aber Problem ist leider das viele es auf Faulheit nutzen um doof bleiben zu wollen und selbst banale Sachen nicht mehr verstehen wollen und dann wiederum wackelige Murkssoftware produzieren. Hat also alles so seine Vor und Nachteile. .-) Allerdings bin ich manchmal noch Bonusgenervt wenn Library XY die Compilerwersen XZ braucht, und man bei aenderungen dann zehn alte Projekte nachziehen muss weil die leider nur mit Comilerversion AB gut liefen. Vanye
Giovanni schrieb: > Wer verwendet den vollen Sprachumfang von Python 3.12?? Ehrlich. Ich > komme mit dem Umfang Python2.7 aus. > Ich nutze modernes Python. > Wer verwendet OOP in Fortran? > Kp > Wer verwendet OOP in MATLAB? Ich. Massiv. Fast alle Neuentwicklungen in MATLAB bei uns sind klassenbasiert. Die Sprache hat sich extrem weiterentwickelt. Wenn man Apps/GUIs entwickelt kommt man daran auch gar nicht mehr dran vorbei (glücklicherweise)
Giovanni schrieb: > Mein Eindruck: Die Sprachen werden sich immer ähnlicher. Ob OOP in > FORTRAN Sinn macht, ist mir nicht klar. Oft sind wichtige Bibs auch noch in Fortran 77 geschrieben. Dein Link oben (https://jcarroll.com.au/2024/10/26/polyglot-maxxie-and-minnie/) hatte mich ein wenig angefixt, weil ich so dachte: hey, wie könnte man sowas in Assembler schreiben. Ist aber auf den ersten Blick nicht so einfach, weswegen ich mich dann etwas umgesehen hatte: - https://rosettacode.org/wiki/Sorting_algorithms/Permutation_sort - https://www.nature.com/articles/s41586-023-06004-9#code-availability - https://rosettacode.org/wiki/Sorting_algorithms/Insertion_sort - https://ceur-ws.org/Vol-2568/paper4.pdf (- https://github.com/ostafen/Fast-Insertion-Sort) usw.. Beim Durchlesen beim rosettacode dachte ich auch gleich, man könnte auch wieder was mit D machen. Ist zwar nicht unbedingt für MCs, aber performant ist D schon, nur leider etwas verwaist. Re D. schrieb: > Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit > Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel > Schweiß und Blut investieren musste. Ich habe nichts gegen Python, im Gegenteil, nur eben mit dem Auftreten von Sheeva und Ein T (https://de.wikipedia.org/wiki/Der_seltsame_Fall_des_Dr._Jekyll_und_Mr._Hyde) Es ist immer die selbe Nummer: Versuchen, eine lange Diskussion anzustoßen, dann auch zwischendurch persönlich werden, oder sich persönlich angegriffen fühlen, oder umgekehrt den Leuten immer wieder schön auf die Füsse treten usw. -> kein bisschen hilfreich, kein bisschen konstruktiv, einfach nur Flame-Wars (o.ä.) anzetteln - dabei hatte ich Sheeva früher schon als hilfreich empfunden.
Hannes J. schrieb: > Bist du dir sicher, dass deine "aufwendigen Rechnungen" heute noch als > aufwendig gelten? Bei Wettermodellen kannst du jeden beliebigen Rechenaufwand erzeugen, indem du an den Gittergrößen drehst. Da ist es egal, ob der Algorithmus von 1990 oder von 2024 stammt. Bei Spielen kannst du statt dessen Frameraten und Auflösung hochschrauben. Oder frag mal irgendwelche Großteleskope mit adaptiver Optik mit ihren Aktuatorzahlen und Aktualisierungsrate. Da kann man auch heutige Rechner gut beschäftigen und über Scripting die Zeit tot zu schlagen.
:
Bearbeitet durch User
Rainer W. schrieb: > Bei Wettermodellen kannst du jeden beliebigen Rechenaufwand erzeugen, > indem du an den Gittergrößen drehst. Es gibt aber Grenzwerte, ab denen die Verkleinerung des Netzes keinen Mehrwert an Information liefert. Rbx schrieb: > Ich habe nichts gegen Python, im Gegenteil, nur eben mit dem Auftreten > von Sheeva und Ein T Doch du hast ein Problem. Deine Äußerungen sind weder objektiv noch konstruktiv.
.Re D. schrieb: > Doch du hast ein Problem. Deine Äußerungen sind weder objektiv noch > konstruktiv. Fass dich an die eigene Nase, und höre auf Threadantworten zu verwechseln, zu vermischen oder zu vertauschen.
Python verwendet man nur wegen der vielen angeflanschten Bibliotheken, nicht wegen der "Schönheit" der Sprache oder Platform, da ist das grösse Müll und bietet absolut nix neues und kann nix richtig gut. Threads sind kaputt, die generelle Interprester-Performance ist unterirdisch im vergleich zu Java geradezu vorsinflutlich, die Versuche das alles zu verbessern sind mangelhaft und nicht offiziell (Jython, Cython, Schlagmichtot-thon). Das Objektsystem ist auch mangelhaft, funktionale Unterstützung wurde wieder rausgekickt, den Hirnfurzn dass Whitespace Syntaxelement ist muss man da gar nicht mehr erwähnen nach den ganzen viel grösseren Mängeln. Ich frage mich warum man diesen Mist explizit einsetzen will, aussern den Sahnebibliotheken aus dem KI-Bereich, OpenCV,... und bischen numerischer Rechnungen. Die Sprache finden nur Kinder und Idioten toll die noch nie was anderes gesehen haben wie früher die BASIC-Fans, so fühlt sich dieser Kindersprache auch an. Man muss nur mal schauen wie der Buchmarkt für Pyhton aussieht: 99% Anfängerbücher auf allerunterstem Level, oft so Namen wie "Pyhton für Kinds" und ähnlicher banaler Schrott, der Rest ist Python nur Beiwerk weil es um die entspr. libs wie Tensorflow, PySpark,... geht und nicht die Deppensprache. Python braucht kein Mensch, das wurde nur populär durch die Entscheidung der big player ihre Edellibs im oben genannten Bereich dort ranzupappen, was wohl auch damit zu tun hat dass US-Hochschulen sich verstärkt auf Python als Deppenlehrsprache eingeschossen haben, die Kinder sind ja heute generell zu doof für alles, das muss alles kindgerecht sein.
:
Bearbeitet durch User
Franko S. schrieb: > Ich frage mich warum man diesen Mist explizit einsetzen will, Ganz einfach. Nachdem alle anderen Programmiersprachen über die Zeit aus guten Gründen über Typsicherheit und ähnliches den "programmatischen Freiraum" des Programmierers sichtlich eingeschränkt haben, musste halt wieder was her, in dem sich völlig befreit von solchen Zwängen fröhlich drauflosgehackt werden konnte. Quick and dirty als Konzept. Oliver
Franko S. schrieb: > Python braucht kein Mensch, das wurde nur populär durch die Entscheidung > der big player ihre Edellibs im oben genannten Bereich dort ranzupappen, > was wohl auch damit zu tun hat dass US-Hochschulen sich verstärkt auf > Python als Deppenlehrsprache eingeschossen haben, die Kinder sind ja > heute generell zu doof für alles, das muss alles kindgerecht sein. Oliver S. schrieb: > Ganz einfach. Nachdem alle anderen Programmiersprachen über die Zeit aus > guten Gründen über Typsicherheit und ähnliches den "programmatischen > Freiraum" des Programmierers sichtlich eingeschränkt haben, musste halt > wieder was her, in dem sich völlig befreit von solchen Zwängen fröhlich > drauflosgehackt werden konnte. Quick and dirty als Konzept. Ersetzen wir Rbx durch Rbx, Franko S. und Oliver S.: Re D. schrieb: > Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit > Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel > Schweiß und Blut investieren musste.
Franko S. schrieb: > Die Sprache finden nur Kinder und Idioten toll Da ich vermutlich nicht mehr als Kind durchgehe, bin ich wohl ein Idiot. Na ja, schlimmer fände ich es, wenn mich jemand als Scheuklappenträger bezeichnen würde ;-)
Franko S. schrieb: > … Enorme Mengen dummes Zeug. Welches schon beim Lesen so dermaßen wehtut, dass man vermuten muss da wird jemand kontinuierlich vom Schwein gebissen um so etwas abzusondern. Erstaunlich mit welchen Individuen man sich diesen Planeten teilen muss.
:
Bearbeitet durch User
Re D. schrieb: > Ersetzen wir Rbx durch Rbx, Franko S. und Oliver S.: > > Re D. schrieb: >> Ich denke Leute Rbx kommen nicht damit klar, dass heute "jeder Depp" mit >> Python Probleme besser lösen kann, als er, wo er vor 40 Jahren viel >> Schweiß und Blut investieren musste. Ja Pippi.
Rbx schrieb: > Ja Pippi. Ich bin hier nicht der, der behauptet mal eben schnell den Compiler umzuschreiben. Komm zu Thema zurück oder lass es.
Oliver S. schrieb: > Nachdem alle anderen Programmiersprachen über die Zeit aus > guten Gründen über Typsicherheit und ähnliches den "programmatischen > Freiraum" des Programmierers sichtlich eingeschränkt haben, musste halt > wieder was her, in dem sich völlig befreit von solchen Zwängen fröhlich > drauflosgehackt werden konnte. Quick and dirty als Konzept. Ja, äh... falsch. "Quick and dirty" machen Perl, PHP und Lua, und die sind nicht typsicher. Python (und nebenbei auch Ruby) sind hingegen typsicher, deswegen führt die Addition einer Ganzzahl und eines Zeichens ("1 + '1'") unter Python auch zu dem Fehler
1 | Traceback (most recent call last): |
2 | File "<stdin>", line 1, in <module> |
3 | TypeError: unsupported operand type(s) for +: 'int' and 'str' |
und unter Ruby zu dem Fehler
1 | -:1:in `+': String can't be coerced into Integer (TypeError) |
2 | from -:1:in `<main>' |
Du siehst: Python und Ruby sind durchaus typsicher, sie händeln das nur ein bisschen anders als die klassischen statisch typisierten Sprachen. Python und Ruby binden den Datentyp nämlich nicht an den Namen einer Variablen, sondern an ihren Wert. Deswegen gibt es für Python auch die Type Hints sowie mypy [1] und für Ruby gibt es Sorbet [2]. Damit werden genau dieselben Typprüfungen durchgeführt, wie das in statischen kompilierten Sprachen vom Compiler gemacht wird. So erhalten die Entwickler die Vorzüge aus beiden Welten: einerseits die sehr schnelle und einfache Entwicklung, andererseits werden die Typen vor einem Release noch einmal geprüft und mögliche Fehler erkannt. Außerdem ist es natürlich fein, daß die Datentypen bereits im Code stehen und darum nicht separat dokumentiert werden müssen. [1] https://mypy-lang.org/ [2] https://sorbet.org/
Franko S. schrieb: > Python verwendet man nur wegen der vielen angeflanschten Bibliotheken, > nicht wegen der "Schönheit" der Sprache Hat du da einen Beleg? Ich finde Python sehr schön und gut leserlich. Aber klar man kann in jeder Syntax hässliches Zeug machen. Es gibt Leute die mögen Schachtelsätze weil sie damit intelligent wirken, es gibt Leute die können auch komplizierte Zusammenhänge einfach ausdrücken. Aber was schön ist, ist völlig subjektiv. Franko S. schrieb: > da ist das grösse Müll und bietet absolut nix neues und kann nix richtig > gut. Okay, welche Alternative zu mathplotlib empfiehlst du? Die Sprache soll bitte auch etwas äquivalentes zu f-Strings bieten. Franko S. schrieb: > Threads sind kaputt, die generelle Interprester-Performance ist > unterirdisch im vergleich zu Java geradezu vorsinflutlich, Was heißt Threads sind kaputt? Und die Performance ist trotzdem für vieles ausreichend. Ansonsten wurde genug genannt zur Beschleunigung. Franko S. schrieb: > Das Objektsystem ist auch mangelhaft, funktionale Unterstützung wurde > wieder rausgekickt, Was bitte ist zu bemängeln? Da bin ich neugierig. Franko S. schrieb: > den Hirnfurzn dass Whitespace Syntaxelement ist muss man da gar nicht > mehr erwähnen Vielleicht fehlt dir das Hirn das Konzept zu verstehen? Sagst du bei Fortran 77 da gleiche? Franko S. schrieb: > Ich frage mich warum man diesen Mist explizit einsetzen will, aussern > den Sahnebibliotheken aus dem KI-Bereich, OpenCV,... Weil es eine schöne und offene Sprache ist mit großer Community ❤️? Franko S. schrieb: > und bischen numerischer Rechnungen. Als ist Python gut für Numerik? Da sind wir ja beim Thema. Franko S. schrieb: > Die Sprache finden nur Kinder und Idioten toll die noch nie was anderes > gesehen haben So so, woran machst du das fest? Und hast du was gegen Kinder? Die sind nicht so engstirnig wie du? Franko S. schrieb: > Man muss nur mal schauen wie der Buchmarkt für Pyhton aussieht: 99% > Anfängerbücher auf allerunterstem Level, oft so Namen wie "Pyhton für > Kinds" und ähnlicher banaler Schrott, Ach und wie ist das bei anderen Sprachen? Wenn man sich eingearbeitet hat, braucht man in Python kein Buch, es gibt die Doku frei im Interner: python.org ist dein Freund. Aber für dich scheint das Neuland zu sein. Nenn doch mal eine Sprache, die was vergleichbares bietet. Franko S. schrieb: > der Rest ist Python nur Beiwerk weil es um die entspr. libs wie > Tensorflow, PySpark,... geht und nicht die Deppensprache. Was denkst du, warum die Entwickler die Deppensprache (Nur Deppen benutzen so ein Wort) supporten. Weil sie dumm und du schlau bist? Da musst du ja noch viel besseres Zeug auf Lager haben. Zeug mal! Franko S. schrieb: > Python braucht kein Mensch, Gott sei Dank, hat du nicht zu entscheiden, wer was braucht und wer Mensch ist. Franko S. schrieb: > das wurde nur populär durch die Entscheidung der big player ihre > Edellibs im oben genannten Bereich dort ranzupappen, was wohl auch damit > zu tun hat dass US-Hochschulen sich verstärkt auf Python als > Deppenlehrsprache eingeschossen haben, die Kinder sind ja heute generell > zu doof für alles, das muss alles kindgerecht sein. Ja, die trinken Kinderblut und werden von Reptiloiden regiert.
Re D. schrieb: > Ersetzen wir Rbx durch Rbx, Franko S. und Oliver S.: Es fällt RBX zwar manchmal schwer, seine Aussagen in einen stimmigen Kontext mit einer nachvollziehbaren Reihenfolge zu bringen, und Rückfragen zu seinen Äußerungen zu beantworten. Aber im Gegensatz zu Franko S und Oliver S ist er ganz sicher kein Troll.
Re D. schrieb: > Ich finde Python sehr schön und gut leserlich. > Aber klar man kann in jeder Syntax hässliches Zeug machen. Na, ich persönlich sehe in Python einige Unterschiede zu anderen Sprachen. Der erste ist, daß ich in Perl sehr diszipliniert sein und mir Mühe geben muß, um les- und wartbaren Code zu schreiben. In Python muß ich diszipliniert sein und mir Mühe geben, um unles- und unwartbaren Code zu schreiben. Nicht umsonst wird Python oft als "ausführbarer Pseudocode" bezeichnet. Zum Einen benutze ich Python-Syntax häufig beim Kommentieren von Code in anderen Sprachen, um bestimmte Abläufe und Algorithmen zu erläutern. Zum anderen hat Python für mich den Vorteil, daß ich meine Gedanken direkt aus dem Gehirn in meinen Editor tippen kann, ohne darüber nachdenken zu müssen, wie ich meinen Gedanken jetzt genau in meiner Zielsprache formulieren muß. Um der Vermutung vorzubeugen, daß das daran läge, daß ich Python nun schon so lange mache und deswegen daran gewöhnt bin: nein, in meinem Fall ist das ganz sicher nicht der Fall. Ich bin von C, C++ und Perl zu Python gekommen, war am Anfang auch -- nicht nur wegen der Sache mit dem Whitespace -- skeptisch, und diese einfache Gehirn2Editor-Eigenschaft war das allererste, was mir schon am ersten Tag mit Python sehr positiv aufgefallen ist.
Ein T. schrieb: > Na, ich persönlich sehe in Python einige Unterschiede zu anderen > Sprachen. Der erste ist, daß ich in Perl sehr diszipliniert sein und mir > Mühe geben muß, um les- und wartbaren Code zu schreiben. In Python muß > ich diszipliniert sein und mir Mühe geben, um unles- und unwartbaren > Code zu schreiben. Das sehe ich allerdings nicht so. Selbstverständlich hat jeder vernünftige Programmierer irgendeinen Programmierstil, der auch Einrückungen einschließt – egal in welcher Sprache, also auch in Perl. Nur, weil sie nicht syntaktisch relevant sind, heißt das ja nicht, dass sie in der Regel weggelassen würden. Außerdem habe ich auch schon genügend Python-Programme gesehen, die unleserlich genug sind, als dass man letztere Aussage so nicht stehen lassen kann. Es steht und fällt immer mit dem Programmierer selbst, wie das Ergebnis aussieht. (Objektsystem) Re D. schrieb: > Was bitte ist zu bemängeln? Es gibt da hin und wieder Inkonsequenzen, fällt einem meistens erst auf, wenn man drüber stolpert. Meine Lieblings-Inkonsistenz wäre, dass len ein Operator statt eine Methode eines Objekts ist.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Meine Lieblings-Inkonsistenz wäre, dass len > ein Operator statt eine Methode eines Objekts ist. len() ist eine Funktion, genauso wie range(). Die Funktion ruft die Methode __len__() eines Objekts auf. Was soll daran inkonsistent sein?
Jörg W. schrieb: > Außerdem habe ich auch schon genügend Python-Programme gesehen, die > unleserlich genug sind, als dass man letztere Aussage so nicht stehen > lassen kann. > > Es steht und fällt immer mit dem Programmierer selbst, wie das Ergebnis > aussieht. Es ist eine Frage der Verteilung.
Re D. schrieb: > Was soll daran inkonsistent sein? Dass es keine Methode ist, also nicht objekt.len(), sondern len(objekt).
Jörg W. schrieb: > Re D. schrieb: >> Was soll daran inkonsistent sein? > > Dass es keine Methode ist, also nicht objekt.len(), sondern len(objekt). Und wo ist da jetzt die Begründung? Wenn du den Sinus von pi haben willst, schreibst du doch auch nicht pi.sin() sondern sin(pi). Das ist bis jetzt eine Meinung von dir, dass das inkonsistent wäre, aber kein Fakt.
:
Bearbeitet durch User
Re D. schrieb: > Wenn du den Sinus von pi haben willst, schreibst du doch auch nicht > pi.sin() sondern sin(pi). Nicht alles, was hinkt, ist ein Vergleich.
Jörg W. schrieb: > Re D. schrieb: >> Wenn du den Sinus von pi haben willst, schreibst du doch auch nicht >> pi.sin() sondern sin(pi). > > Nicht alles, was hinkt, ist ein Vergleich. Wo bleibt denn jetzt deine Begründung? Und wo hinkt der Vergleich? Da hat man dich ertappt, dass du eine Funktion nicht von einen Operator unterscheiden kannst und dann kommt nix mehr? Mir scheint ehr, du hast die Logik und Funktionalität von len() und _len_ nicht verstanden.
:
Bearbeitet durch User
Re D. schrieb: > Wo bleibt denn jetzt deine Begründung? pi ist eine Zahl, kein Objekt. Aber weder pi noch sin gibt's in Python einfach so.
1 | >>> sin(pi) |
2 | Traceback (most recent call last): |
3 | File "<stdin>", line 1, in <module> |
4 | NameError: name 'sin' is not defined. Did you mean: 'bin'? |
Wenn du jetzt anfängst, jede Zahl auch noch als Objekt anzusehen, gut, kannst du machen. Dann bräuchtest du halt gar keine Funktionen als solche mehr, denn jede Zahl müsste von einer Klasse abgeleitet werden, die sowas dann als Methoden mit sich bringt. Eine Länge wiederum ist etwas, was nur in Verbindung mit manchen Objekten überhaupt als Konzept Sinn hat. Das sieht Python übrigens ganz genauso:
1 | >>> len(3.1415926) |
2 | Traceback (most recent call last): |
3 | File "<stdin>", line 1, in <module> |
4 | TypeError: object of type 'float' has no len() |
Damit ist eigentlich klar, dass die Länge nur als Attribut einiger Klassen zweckmäßig ist. Trotzdem wird sie dann aber (entgegen auch der Suggestion obiger Fehlermeldung) nicht als Methode gehandhabt, sondern als globale Funktion:
1 | >>> len(foo) |
2 | 3 |
funktioniert, also offenbar ist "foo" ein Objekt, für dass die Methode einer Länge Sinn hat. Aber es gibt es nicht als Methode:
1 | >>> foo.len() |
2 | Traceback (most recent call last): |
3 | File "<stdin>", line 1, in <module> |
4 | AttributeError: 'list' object has no attribute 'len' |
Für dich scheint das völlig logisch zu sein – für mich ist es inkonsistent. Ich kann mit dieser Inkonsistenz leben, aber ich nenne es trotzdem eine Inkonsistenz.
Jörg W. schrieb: > pi ist eine Zahl, kein Objekt. Pi ist ein Objekt vom Typ float. Jörg W. schrieb: >>>> sin(pi) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > NameError: name 'sin' is not defined. Did you mean: 'bin'? Probiere es mit from math import sin, dann bekommst du auch keine Fehlermeldung. Jörg W. schrieb: > Dann bräuchtest du halt gar keine Funktionen als > solche mehr, denn jede Zahl müsste von einer Klasse abgeleitet werden, > die sowas dann als Methoden mit sich bringt. Ja, macht das der Python-Interpreter. Jörg W. schrieb: > Eine Länge wiederum ist etwas, was nur in Verbindung mit manchen > Objekten überhaupt als Konzept Sinn hat. Ja, Listen, Tupel, Dictionaries ... alles Objekte. Bei denen macht die Funktion sin keinen Sinn, nach deiner Logik müssten also alle Objekte vom typ float und int die sin-Funktion haben, denn sonst macht das Konzept Sinus doch gar keinen Sinn. Nein natürlich ist es nicht so! Du verkennst, das Python als Multiparadigmen Sprache entworfen ist. Jörg W. schrieb: > Damit ist eigentlich klar, dass die Länge nur als Attribut einiger > Klassen zweckmäßig ist. Jetzt soll es auch noch ein Attribut sein? Also statt 's'.len() 's'.len? Ne, da bin ich nicht bei dir. Jörg W. schrieb: >>>> len(foo) > 3 > > funktioniert, also offenbar ist "foo" ein Objekt, für dass die Methode > einer Länge Sinn hat. Aber es gibt es nicht als Methode: >>>> foo.len() > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > AttributeError: 'list' object has no attribute 'len' > > Für dich scheint das völlig logisch zu sein – für mich ist es > inkonsistent. Ja, weil ich weiß, dass jemand entschieden hat dass len() eine Funktion ist die die Länge eines zählbaren Objektes wieder gibt, in dem es die Methode __len__() aufruft. "Es wird die Länge gezählt" und das geht mit unterschiedlichen Objekttypen. Nur weil du es 20 Jahre anders gemacht hast, ist das halt nicht inkonsistent. Es ist einfach anders entschieden.
:
Bearbeitet durch User
Re D. schrieb: > Nur weil du es 20 Jahre anders gemacht hast, ist das halt nicht > inkonsistent. Es ist einfach anders entschieden. Für dich ist das in Ordnung, weil es jemand so entschieden hat. Für mich ist es inkonsistent, weil ich von einem Objekt, welches eine Länge hat, eine entsprechende Methode erwarte. Belassen wir es dabei.
Jörg W. schrieb: > Belassen wir es dabei. Genau, rein subjektiv und somit kein Beleg, dass die Sprache besonders inkonsistent wäre. Sie ist einfach eine Multiparadigmensprache.
Jörg W. schrieb: > pi ist eine Zahl, kein Objekt. > ... > Wenn du jetzt anfängst, jede Zahl auch noch als Objekt anzusehen, gut, > kannst du machen. Im Gegensatz zu C++ sind Zahlen in Python tatsächlich Objekte:
1 | >>> type(42) |
2 | <class 'int'> |
3 | >>> type(3.14) |
4 | <class 'float'> |
5 | >>> type(3+4j) |
6 | <class 'complex'> |
Zahlen haben auch Membervariablen und -funktionen:
1 | >>> c = 3+4j |
2 | >>> c.real |
3 | 3.0 |
4 | >>> c.imag |
5 | 4.0 |
6 | >>> c.conjugate() |
7 | (3-4j) |
In Multiparadigmensprachen wie Python, C++ und Java liegt es im Ermessen des jeweiligen (Bibliotheks- oder Anwendungs-)Entwicklers, welche Funktionen er als Member- und welche als freie Funktion definiert. Da Geschmäcker verschieden sind, führt dies immer wieder zu Diskussionen. In C stellt sich diese Frage nicht: Da sind alle Funktionen frei. In Smalltalk (reine OO-Sprache) ist die Sache ebenfalls klar: Alle Funktionen sind Memberfunktionen (also auch abs, sin, cos usw.).
Jörg W. schrieb: > Das sehe ich allerdings nicht so. Selbstverständlich hat jeder > vernünftige Programmierer irgendeinen Programmierstil, der auch > Einrückungen einschließt – egal in welcher Sprache, also auch in Perl. > Nur, weil sie nicht syntaktisch relevant sind, heißt das ja nicht, dass > sie in der Regel weggelassen würden. Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, }, begin und end schlicht und ergreifend: redundant, zudem soll die Whitespace-Geschichte zu einem besser les- und wartbarem Code führen. Das sind die Argumente, die Guido van Rossum für seine Designentscheidung vorbringt, und nicht nur, aber auch wegen meiner Erfahrungen mit dem Code von anderen Entwickler in anderen Sprachen kann ich ihm nur zustimmen. Es ist zweifellos sinnvoll, dafür einen ordentlichen Programmiereditor (Emacs, anyone?) zu benutzen, aber das ist für Entwickler ja ohnehin sinnvoll und für die meisten wohl auch kein Problem. > Außerdem habe ich auch schon genügend Python-Programme gesehen, die > unleserlich genug sind, als dass man letztere Aussage so nicht stehen > lassen kann. Hättest Du dazu möglicherweise ein, zwei Beispiele für mich? Danke.
Ein T. schrieb: > Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, }, > begin und end schlicht und ergreifend: redundant, Lahmes Argument, finde ich. Wenn du alles weglassen willst, was redundant ist, bleibt nichts menschenlesbares mehr übrig. Auch viele Leerzeichen in irgendwelchen Ausdrücken sind redundant, und selbstverständlich reichen 6 Zeichen lange Bezeichner komplett aus, um genügend Namensraum für alle Programme zu bieten. Hatten wir ja schon mit FORTRAN damals. ;-) > zudem soll die > Whitespace-Geschichte zu einem besser les- und wartbarem Code führen. Für mich hat sie sich schon oft als das Gegenteil erwiesen. Die Redundanz von {} oder begin … end bringt es nämlich mit sich, dass man beispielsweise nach einer größeren copy&paste-Aktion den Code automatisch durch eine Maschine neu sortieren lassen kann. Und besser lesbar ist Code mit einer gewissen Redundanz ohnehin – siehe Leerzeichen innerhalb von Ausdrücken. >> Außerdem habe ich auch schon genügend Python-Programme gesehen, die >> unleserlich genug sind, als dass man letztere Aussage so nicht stehen >> lassen kann. > > Hättest Du dazu möglicherweise ein, zwei Beispiele für mich? Danke. Nein, ich archiviere so einen Kram nicht, wenn ich ihn mal irgendwo gesehen habe.
Diese ganze Einrücken-ist-schlecht Diskussion bei Python ist so dermaßen überflüssig, dass es der Sau graust! Als ich vor vielen Jahren damit anfing, hatte ich übrigens die gleichen blödsinnigen Vorbehalte. Dann habe ich ein paar Stunden damit gearbeitet und nie wieder darüber nachgedacht.
Norbert schrieb: > Diese ganze Einrücken-ist-schlecht Diskussion bei Python ist so dermaßen > überflüssig, dass es der Sau graust! Klar: diese Sprache ändert eh keiner mehr. ;-) > Als ich vor vielen Jahren damit anfing, hatte ich übrigens die gleichen > blödsinnigen Vorbehalte. Bei mir sind es keine Vorbehalte, sondern durchaus die Erfahrungen damit. Dabei ist Python wohl die Sprache, in der ich in den letzten Jahren (vor allem beruflich) am meisten programmiert habe. Ich weiß also durchaus, wovon ich schreibe, und nur weil ich einzelne Aspekte kritisiere heißt das nicht, dass ich diese Sprache jetzt insgesamt unbenutzbar fände.
Jörg W. schrieb: > Wenn du alles weglassen willst, was > redundant ist, bleibt nichts menschenlesbares mehr übrig. Was dann zu brainfuck geführt hat, und für die Leerzeichenfetischisten zu whitespace. Oliver
:
Bearbeitet durch User
Jörg W. schrieb: > Ein T. schrieb: >> Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, }, >> begin und end schlicht und ergreifend: redundant, > > Lahmes Argument, finde ich. Wenn du alles weglassen willst, was > redundant ist, Das möchte ich ja gar nicht, da bin ich selektiv. :-) >> zudem soll die >> Whitespace-Geschichte zu einem besser les- und wartbarem Code führen. > > Für mich hat sie sich schon oft als das Gegenteil erwiesen. Die > Redundanz von {} oder begin … end bringt es nämlich mit sich, dass man > beispielsweise nach einer größeren copy&paste-Aktion den Code > automatisch durch eine Maschine neu sortieren lassen kann. Reden wir gerade von Les- und Wartbarkeit, oder von Kopierbarkeit? Ich kenne Deinen Arbeitsalltag und Deine Arbeitsweise natürlich nicht, allerdings lese und warte ich Code sehr viel häufiger, als ich welchen kopiere. Aber in den seltenen Fällen, in denen ich Code kopiere oder in eine andere Datei lege, reichen mir die vielen Indentierungsbefehle (zum Beispiel "indent-region-{left,right}-to-tab-stop"), die der Emacs mitbringt. IIRC bist Du doch auch ein Emacs-User, oder habe ich das falsch in Erinnerung? Egal, wie dem auch sei: die seltenen Gelegenheiten, in denen ich Code von einer Datei in eine andere kopiere oder verschiebe, reichen mir bei Weitem nicht aus, um mich an der Sache mit dem Whitespace in Python zu stoßen. Da sehe ich dann letztlich dennoch mehr Vor- als Nachteile. > Und besser > lesbar ist Code mit einer gewissen Redundanz ohnehin – siehe Leerzeichen > innerhalb von Ausdrücken. Da geht es aber um Abgrenzung und nicht um Redundanz, oder? Wie auch immer: die Geschichte mit dem Whitespace in Python muß man nicht gut finden, auch wenn ich es tue. Aber das ändert ja nichts daran, daß man damit gut leben und arbeiten, und mit Python sehr schnell überaus leistungsfähige Programme entwickeln kann, auch für numerische Berechnungen -- um mal wieder auf das Thema dieses Threads zurückzukommen.
Jörg W. schrieb: > Norbert schrieb: >> Diese ganze Einrücken-ist-schlecht Diskussion bei Python ist so dermaßen >> überflüssig, dass es der Sau graust! > > Klar: diese Sprache ändert eh keiner mehr. ;-) Bython [1] existiert. :-) [1] https://github.com/mathialo/bython
Jörg W. schrieb: > Bei mir sind es keine Vorbehalte, sondern durchaus die Erfahrungen > damit. Dabei ist Python wohl die Sprache, in der ich in den letzten > Jahren (vor allem beruflich) am meisten programmiert habe. Ich weiß also > durchaus, wovon ich schreibe, und nur weil ich einzelne Aspekte > kritisiere heißt das nicht, dass ich diese Sprache jetzt insgesamt > unbenutzbar fände. Darum ging es in meiner Antwort überhaupt nicht. Es ging darum, dass hier wirklich überflüssige Kleinigkeiten in einer überzogenen Weise herangezogen werden, um eine komplette Programmiersprache zu bewerten. (Ob nun positiv oder negativ sei mal dahin gestellt) Ob's nun die Geschwätzigkeit von Pascal ist, das Ausrufezeichen bei C, ternäre Ops, oder was es sonst noch alles an Diskussionsmaterial gibt… Es wird alles bis zur Unkenntlichkeit aufgeblasen und alle vielleicht noch als vernünftig anzusehenden Argumente ad absurdum geführt. Nur damit mal der eine, dann der andere und dann der dritte irgendwie seine Befriedigung bekommt, Recht zu haben (oder es zumindest zu meinen oder zu glauben)
Jörg W. schrieb: > siehe Leerzeichen innerhalb von Ausdrücken. Auch wenn du es 3 mal wiederholst, ein Leerzeichen ist keine Redundanz, genauso wenig wie eine ordentliche Variablenbezeichnung. Deine vergleiche hinken nicht nur, die sitzen im Rollstuhl. Jörg W. schrieb: > Die Redundanz von {} oder begin … end bringt es nämlich mit sich, dass > man beispielsweise nach einer größeren copy&paste-Aktion den Code > automatisch durch eine Maschine neu sortieren lassen kann. Und besser > lesbar ist Code mit einer gewissen Redundanz ohnehin – siehe Leerzeichen > innerhalb von Ausdrücken. Und wenn du den coursor falsch vor einer Klammer positioniert hat?
Norbert schrieb: > Es ging darum, dass hier wirklich überflüssige Kleinigkeiten in einer > überzogenen Weise herangezogen werden, um eine komplette > Programmiersprache zu bewerten. Wenn man sich den Code im Hexeditor ansieht, interessiert das eh kaum noch. Das ist eine Kunst, die kaum gefördert wird. Bei Webseiten konnte man früher noch gut den Code nachvollziehen, bei aktuellen Webseiten braucht man aber schon gute Lesehilfen. Interessant ist bei Haskell, dass die Programmiersprache unglaublich gut ausbalanciert ist, und so sieht man (dank vieler Sprachzucker-Goodies) auch kaum so viele Klammern wie bei Lisp oder Closure. Was natürlich wirklich fehlt bei Haskell, dass kein Zugang für Hardware-Tuning da ist. Gut, man kann nicht alles haben. Dafür ist Haskell auf der anderen Seite richtig gut für Parallel-Programme. Und gerade, wenn es um Parallelisierung geht, kann man auf Haskell setzen, nur schade, dass der Hype vorbei ist, der Code so fremdartig und die Bibs wenig praxistauglich. Das heißt, bei Haskell gibt es schon einige größere Angriffsflächen für Optimierung. So ein paar grundlegende Infos zu C++ Optimierung gibt es hier und da auch noch, aber ich glaube, früher gab es davon noch mehr, im Moment werden Online viel Bücher zu C++ Optimierung in den Suchmaschinen vorgeschlagen. https://quantumzeitgeist.com/c-high-performance-computing/
Re D. schrieb: > Und wenn du den coursor falsch vor einer Klammer positioniert hat? Ist doch egal, du kannst die Einrückungen für völlig beliebige Bereiche neu berechnen lassen, bis hin zur ganzen Datei (ganz früher gern mit indent(1) so gemacht worden). Auf den Cursor kommt es nicht an. Ein T. schrieb: > Reden wir gerade von Les- und Wartbarkeit, oder von Kopierbarkeit? Beides möchte ich haben. Solche Kopierorgien entstehen beispielsweise, wenn man irgendwo merkt, dass die Verschachtelungstiefe zu groß wird und man lieber Teile als separate Funktion auskoppeln will. Solange das ein einziger Block ist, klappt das in der Tat mit den von dir genannten Emacs-Funktionen, aber wenn es von mehreren Stellen zu verschieben ist, dann landet man schnell an einem Punkt, an dem man anfängt, die gesamte (eigentlich bereits getestete) Logik in der Kopie nachzuvollziehen, um die korrekte Einrückung zu finden. Bei einer Sprache, die andere syntaktische Elemente für die Gruppierung benutzt, kann dagegen eine Maschine immer die passenden Einrückungen selbst berechnen, denn sie muss die Logik dahinter nicht nachvollziehen. Ein T. schrieb: > Wie auch immer: die Geschichte mit dem Whitespace in Python muß man > nicht gut finden, auch wenn ich es tue. Aber das ändert ja nichts daran, > daß man damit gut leben und arbeiten, und mit Python sehr schnell > überaus leistungsfähige Programme entwickeln kann, auch für numerische > Berechnungen -- um mal wieder auf das Thema dieses Threads > zurückzukommen. Ich gehöre zwar zu denen, die sie nicht gut finden, stimme aber mit dem Rest deiner Ausführungen ganz genauso überein.
Jörg W. schrieb: > Ist doch egal, du kannst die Einrückungen für völlig beliebige Bereiche > neu berechnen lassen, bis hin zur ganzen Datei (ganz früher gern mit > indent(1) so gemacht worden). Auf den Cursor kommt es nicht an. Du hast das Problem nicht verstanden. Und im übrigen, ein guter Struktur in Programm braucht keine 3 Verschlechterungen.
Jörg W. schrieb: > Solche Kopierorgien entstehen beispielsweise, wenn man irgendwo merkt, > dass die Verschachtelungstiefe zu groß wird und man lieber Teile als > separate Funktion auskoppeln will. Hat Deine IDE keine Refactoring-Funktionen? Ich programmiere Python unter Visual Studio Code, da kann man sowas machen: Refactor, extract Method.
> Aber wenn wir unseren Code ohnehin korrekt einrücken, sind die {, }, > begin und end schlicht und ergreifend: redundant, Nein, es ist Unsinn weil mein "einruecken" sicher ein anderes sein wird wie deines. Und ich plane nicht mich an einem Computer anzupassen sondern erwarte es anders rum! Vanye
Vanye R. schrieb: > Nein, es ist Unsinn weil mein "einruecken" sicher ein anderes sein wird > wie deines. Kannst Du machen, is dann halt Kacke. > Und ich plane nicht mich an einem Computer anzupassen > sondern erwarte es anders rum! Dann schreibst Du keinen Code.
Ein T. schrieb: > Dann schreibst Du keinen Code. Das ist 'ne blöde Unterstellung. Du weißt ganz genau, dass es durchaus sehr viele verschiedene Einrückungs-Stile gab und gibt. Jedes Projekt hat da andere Vorlieben. Trotzdem sind sie deshalb alle in sich konsistent und leiden nicht unter dem immer wieder behaupteten "das sei unleserlich und unübersichtlich". Ich habe in meinem Leben an so vielen verschiedenen Dingen mitgearbeitet, dass ich gar kein Problem habe, mich (bzw. meinen Editor) an den jeweiligen Stil des Projekts anzupassen.
Jörg W. schrieb: > Ein T. schrieb: >> Dann schreibst Du keinen Code. > > Das ist 'ne blöde Unterstellung. Denk noch mal drüber nach: Ein T. schrieb: >> Und ich plane nicht mich an einem Computer anzupassen >> sondern erwarte es anders rum! > > Dann schreibst Du keinen Code. Ist nicht so schwer zu verstehen, was Ein T. meint oder? Oder passt sich dein Compiler an dich an? Jörg W. schrieb: > verschiedene Einrückungs-Stile gab und gibt. Bei Python gibt es eine PEP. Jörg W. schrieb: > Ich habe in meinem Leben an so vielen verschiedenen Dingen > mitgearbeitet, dass ich gar kein Problem habe, mich (bzw. meinen Editor) > an den jeweiligen Stil des Projekts anzupassen. Du nicht, Vayne scheinbar schon. Der will seine Einrückung.
Re D. schrieb: >> verschiedene Einrückungs-Stile gab und gibt. > > Bei Python gibt es eine PEP. Dass man einem Programmierer mit der Syntax auch gleich noch den Stil diktiert, kann man aber eben durchaus als übergriffig betrachten.
Jörg W. schrieb: > Dass man einem Programmierer mit der Syntax auch gleich noch den Stil > diktiert, kann man aber eben durchaus als übergriffig betrachten. Dir ist aber schon klar dass das zweite ›P‹ für proposal steht? Mein Kommentar weiter oben scheint seine Gültigkeit zu behalten.
Jörg W. schrieb: > Dass man einem Programmierer mit der Syntax auch gleich noch den Stil > diktiert, kann man aber eben durchaus als übergriffig betrachten. Jo, ich fühle mich von DIN A4 auch im meiner künstlerischen Freiheit eingeschränkt.
PEP 8 ist halt ein Style-Guide. Er ist nur dann bindend, wenn man in einer Entwicklergruppe arbeitet, die auf dessen Einhaltung besteht. Das ist nicht anders als bei den mannigfaltigen Style-Guides für C, C++, Java usw. Ich persöönlich finde bspw. die im PEP empfohlene Einrückungstiefe von 4 Spaces/Level als übertrieben und verwende stattdessen nur 2 Spaces. Wenn ich mit Leuten zusammenarbeite, die 4 Spaces bevorzugen, passe ich mich entsprechend an. Bereits bestehender Code ist schnell mit reindent.py auf 4 Spaces umgestellt.
Ein T. schrieb: > Kannst Du machen, is dann halt Kacke. Quark (Inwiefern denn überhaupt??) Ein T. schrieb: > Dann schreibst Du keinen Code. Da haben wir es wieder: die Persönlichkeitsebene, nur grob holzschnittartig angepeilt und schon wieder herumstreiten. Bei Fortran 77 muss man auch auf die gezählte Position achten. Sollte man mal ausprobieren, wenn man das nicht kennt. (kann man aber auch nachlesen, falls keine Lust drauf: https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html) Und dann: Doppeldeutigkeit.. Auf jeden Fall ähneln sich ja (auch) (z.B.) Python und der Emacs in gewisser Weise. Ist halt viel Automagie mit im Spiel, und dann kann man natürlich schön drumherum blubbern, als gäbe es die nicht. Im Hexeditor dagegen muss man auch wieder zählen. Hm, und Java? Soll ja "plattformunabhängig" sein. Theoretisch ja, wenn man darüber hinwegsieht, dass es riesige (nix für Speichersparer) Runtime-Dateien für die passende Hardware-Plattform braucht. Und für Teams gibt es ja auch meist Code-Style-Pläne, was gar nicht ginge, wenn alles wie beim Hexeditor vorgegeben ist. https://www.w3schools.com/python/python_lists_comprehension.asp https://www.haskell.org (die übliche List Comprehension auf der Seite oben rechts) (wenn man die mathematischen Mengentechnischen Hintergründe vor Augen hat, fällt es wohl leichter, den Code nachzuvollziehen.) https://stackoverflow.com/questions/51775829/how-to-use-list-comprehension-in-haskell Vieles ist auch einfach eine Übungsfrage wo gar nicht so genau klar ist, wer sich jetzt an wen anpasst ;) (Wer "App" sagt, hat sich auf jeden Fall schon mal an den Java Jargon angepasst. :D )
Re D. schrieb: > Jo, ich fühle mich von DIN A4 auch im meiner künstlerischen Freiheit > eingeschränkt. Das ist auch was Doppeldeutiges, weil vor allem leere Seiten (kariert oder nicht) erstmal zu gar nix inspirieren. Das muss man überwinden können.
Jörg W. schrieb: > Du weißt ganz genau, dass es durchaus sehr viele verschiedene > Einrückungs-Stile gab und gibt. Jedes Projekt hat da andere Vorlieben. Richtig, und deswegen passe ich meinen Code natürlich auch den Vorlieben des Projekts an. Ich weiß nämlich auch, wie unfaßbar nervig und aufwändig es ist, mit Diven, Besserwissern und Querulanten zu arbeiten, die solche Dinge nur aus einem einzigen Grund anders machen: um der kleine große Held zu sein, der sich "von nichts und niemandem was vorschreiben" läßt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.