Hallo, auf mehreren Seiten wird Phyton empfohlen für wissenschaftliche Projekte wie z.B. Machine Learning, aber wenn ich mir die Benchmarks zwischen Phyton und C++ anschaue, dann würde ich doch eher zu C++ tendieren. Weiss jemand den Grund für Python für wissenschaftliche Projekte? https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gpp
:
Bearbeitet durch Admin
Dirk schrieb: > auf mehreren Seiten wird Phyton empfohlen für wissenschaftliche > Projekte wie z.B. Machine Learning Wer sind diese "mehreren Seiten"? Welche Gründe/Motive haben diese, überhaupt eine spezielle Sprache zu empfehlen - mit anderen Worten, worin besteht für diese "Seiten" der Profit durch eine solche Empfehlung? Was sind diese "wissenschaftlichen Projekte"; wie sind diese definiert? Dirk schrieb: > aber wenn ich mir die Benchmarks > zwischen Phyton und C++ anschaue, dann würde ich doch eher zu C++ > tendieren. Überraschung (naja, eher nicht - zumindest für jeden, der sich halbwegs mit "Programmiersprachen" auskennt): Eine interpretierte Skriptsprache läuft deutlich langsamer als nativ compilierter Maschinencode aus (hier beispielhaft) C++. => Was genau soll erreicht werden - geht es um ein "wissenschaftliches Projekt" im Sinne von Uni, Abschlussarbeit usw. (d. h. Augenmerk auf Funktionsnachweis eines Algorithmusses, Lesbarkeit des Codes etc.), oder um eine Serienentwicklung (d. h. Fokus auf möglichst hoher Ressourceneffizienz)?
Dirk schrieb: > Weiss jemand den Grund für Python für wissenschaftliche Projekte? Ease of use. Außerdem wird dort alles was nicht Spielzeuggröße hat dann eh' mit dicken Tools wie Tensorflow auf der GPU berechnet. Und für das reine Datenhandling zur Graka ist Python schnell genug.
Leichter Einstieg Läuft auf jedem Rechner Große Community
Bei wissenschaftlichen Arbeiten geht es im Allgemeinen nicht um Performance, sondern um die Entwicklung von Algorithmen und Verfahren oder Umsetzung von mathematischen Verfahren. Das geht in Python (Matlab, Scilab,...) deutlich einfacher als in C++. Wenn das Verfahren dann funktioniert, wird es manchmal in C/C++ umgesetzt, aber die wissenschaftliche Arbeit ist dann meistens schon beendet.
Dirk schrieb: > Phyton und C++ anschaue, dann würde ich doch eher zu C++ > tendieren. Dafür bekommst du bei Python, lesbaren Code, die möglichkeit "schnell mal was zu änderen" und wirklich viele Biblotheken. Geschwindigkeit ist nicht alles und bei vielen Aufgaben, reicht das was Python mitbringt, vollig aus. Ein Bespiel wäre Schrifterkennung mit KI, die wird mit der Grafikkarte brechnet, aber warum hierfür ein C++ Programm Coden wenn es reicht 2 Handvoll Pythoncode zu schreiben, die Berchnung findet so wie so wo anders statt. Oder das Entwicklen eines Exploit, auch hier macht es mehr Sinn schnell was am Code ändern zu können als jedesmal den Edit/Compile/Test Zyklus anstoßen zu müssen. In Beiden fällen kann man "später" immernoch, das mit Python erlangte Wissen in C/C++ transformieren.
Ist eben ein bischen so wie Arduino bei Mikrocontrollern ("welche
Bibliotheken muss ich zusammenstöpseln?").
Frag mal Andreas: Neue Algorithmen für Video- und Audiocodes werden zwar in C/C++ implementiert, aber größtenteils von ET-Ingenieuren ;-) Entsprechend sieht der Code aus. Erst im nachhinein wird dieser von Informatikern auf Effizienz optimiert. So ähnlich wird es sich mit Python verhalten.
Dirk schrieb: > Weiss jemand den Grund für Python für wissenschaftliche Projekte? 1. relativ einfach zu lernen, gut lesbarer Code 2. andere haben es auch schon so gemacht => viele Biblitheken und Tutorials 3. Geschwindigkeit ist meist "egal" Früher hat man halt "alles" in Fortran (Großrechner) oder Basic (Taschenrechner und Computer) programmiert.
Typischerweise ist Python-Code (übrigens: Python, nicht, Phyton) vor allem von Programmier-Anfängern deutlich besser zu warten und auch drei Jahre später vom Nachfolger noch zu verstehen als C-Code. C++ dürfte irgendwo dazwischen, aber (vor allem bei Programmier-Anfängern) näher an C liegen. Und Python nimmt dem Physiker, der Biologin, dem Bauingenieur, der Chemieingenieurin und auch dem theoretischen Informatiker eine ganze Menge Dinge ab, die diese vor Beginn der Arbeit meistens nicht können. Zum Beispiel Speicherverwaltung, Exception handling, Matrizenrechnung... Das führt idealerweise dazu, dass die Arbeit sich mehr um das zu lösende Problem als um das Werkzeug dreht. Und damit eine bessere Lösung für das Problem liefert. MfG, Arno
Python wird oft als einfach zu benutzendes High-Level-Frontend für verschiedene Bibliotheken genutzt¹, in denen die eigentliche Rechenarbeit getan wird. TensorFLow wurde schon genannt, weitere sind bspw. Numpy und OpenCV. Auf diese Weise können mit sehr geringem Entwicklungsaufwand Anwendungen realisiert werden, die in ihrer Ausführungsgeschwindigkeit reinen C++Implementationen kaum nachstehen. An Grenzen stößt man immer dann, wenn eine benötigte rechenintensive Basisfunktion nicht in den verwendeten Bibliotheken enthalten ist. In diesem Fall kann man die benötigte Funktion in C++ schreiben, sie in Python einbinden und dann wieder mit Python weitermachen. ————————————— ¹) Auch Matlab ist auf diese Weise entstanden, nämlich als Frontend für die Bibliotheken LINPACK und EISPACK
:
Bearbeitet durch Moderator
Danke, Teile die hier benannt wurden hatte ich vermutet, aber war mir unsicher.
Dirk schrieb: > Weiss jemand den Grund für Python für wissenschaftliche Projekte? weil es gerade "cool" ist! Ich mache für meine Diss alles in C++. Grund: Ich kann so gut C++, dass ich damit gleich schnell bin wie jemand anderes in Python. Vor Pyhton war Matlab das Mittel der Wahl... Ich bastle beruflich öfter kleine "Numeric-Tools".. also so 2d Finite Differenzen Solver udgl. ... neuerdings in Javascript im Browser :) Ich postuliere daher, dass bald komplett Browser basierte Lösungen hipp sein werden. Es ist richtig faszinierend zu sehen wie schnell Javascript in einem modernen Browser läuft (dank JIT eigentlich kein wunder)... mit etwas d3.js gewürzt sind da 10MB Rohdaten in 0,nix verarbeitet und visualisiert. 73
Hans schrieb: > Dirk schrieb: >> Weiss jemand den Grund für Python für wissenschaftliche Projekte? > > weil es gerade "cool" ist! > > Ich mache für meine Diss alles in C++. > > Grund: Ich kann so gut C++, dass ich damit gleich schnell bin wie jemand > anderes in Python. Sorry, aber das ist Unfug. Das Problem ist hier auch gar nicht die Sprache, sondern dass die Bibliotheken im Vergleich zu C++ sehr einheitlich, sehr gut verfügbar, sehr gut dokumentiert und sehr umfangreich sind. Wenn du in C++ ein CSV lesen und die Daten spaltenweise fouriertransformieren willst, wie lange bist du beschäftigt? Ich wette mit dir, du schaffst das nicht unter 10-15 Minuten, selbst wenn du sehr viel Übung im Umgang mit den geeigneten Tools hast. Den Anfänger kann das auch leicht mal 2-3 Tage kosten. In Python kannst du das live in die Shell tippen und bist in < 30 Sekunden fertig. Wenn du es dann auch noch in ein PDF plotten willst, wird das alles noch viel extremer. Bonus: langsamer ist die Python-Lösung in dem Fall auch nicht wirklich. Im Ernst: wieviele verschiedene Bibliotheken muss ich mir zusammensammeln, damit ich in C++ zumindest * Plots * FFT * File I/O in sinnvollen Formaten (ok, das kann man notfalls selber bauen) * Fit-Routinen (LM, ...) * Matrixoperationen habe? Ich denke, mindestens so 4 ... Ich glaube nicht, dass Python als Sprache wahnsinnig viel damit zu tun hat; das Ökosystem ist halt einfach in einem sehr guten Zustand für diesen Anwendungszweck, und das genügt für die "kritische Masse".
:
Bearbeitet durch User
Python ist vor allem bei den Wissenschaftlern beliebt, für die Programmierung nur ein Werkzeug ist, um ihre Fragestellungen zu lösen. Bibliotheken wie Scipy und Numpy liefern wichtige Funktionen für Berechnungen, andere Bibliotheken wie Matplotlib und Bokeh helfen die Ergebnisse ansehnlich zu präsentieren. Alles ist frei ohne Lizenzgedödelse.
Sven B. schrieb: > PDF plotten Das K.O. Argument gegen C++ in der Wissenschaft (zumindest für mich und alle die ich in der Wissenschaft kenne). Es gibt keine brauchbare Bibliothek für die Darstellung wissenschaftlicher Daten. Für Dinge, die man in Python 5 Minuten mit matplotlib benötigt braucht man in C++ (oder C macht in diesem Fall keinen Unterschied, da es eh fast nur C Bibliotheken gibt) mindestens mehrere Stunden.
Ich finde es kommt halt auch drauf an. Anwendung zum langfristigen Betrieb eines wissenschaftlichen Geräts, dafür kann C++ gut sein. Labor-Messdaten auswerten -- bestimmt nicht.
Dirk schrieb: > Hallo, auf mehreren Seiten wird Phyton empfohlen für wissenschaftliche > Projekte wie z.B. Machine Learning, aber wenn ich mir die Benchmarks > zwischen Phyton und C++ anschaue, dann würde ich doch eher zu C++ > tendieren. > > Weiss jemand den Grund für Python für wissenschaftliche Projekte? > > https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gpp Es heißt Python. Wie die Schlange. Wer Benchmarks liest, sollte sicherstellen, sie auch zu verstehen. Aber kommen wir zu den Punkten, weshalb Python in der wissenschaftlichen Community so beliebt ist: Zunächst ist es einfach zu erlernen und nutzen, überaus stabil, und für eine Skriptsprache auch sehr performant. Python wird häufig als Glue-Language verwendet; etliche Bibliotheken und Pakete in Wirklichkeit kompilierter Maschinencode und deswegen genauso schnell wie kompilierter Code nun einmal ist. Mit Nuitka und ähnlichen Werkzeugen kann aus Python-Code im Bedarfsfall C- oder C++-Code erzeugt und dieser dann nativ übersetzt werden. Es gibt zudem eine Reihe von JIT-Compilern sowie einen JIT-Compiler namens Numba für array-orientierten, rechenintensiven Code. Und wer seinen C- oder C++-Code in Python nutzen möchte, hat es mit Cython und Boost::Python sehr leicht. Frameworks aus dem Distributed Computing wie Apache Spark, Apache Storm, Gearpump, Heron und Tensorflow haben Schnittstellen, um Python-Code auf verteilten Clustern zu benutzen. Dadurch können Datensätze verarbeitet werden, für die einzelne Maschinen nicht mehr ausreichen. Python hat eine unglaublich große und vielfältige Infrastruktur, es gibt etliche fertige Bibliotheken aus dem numerischen Computing wie numpy, wissenschaftliche Werkzeuge wie Pandas, scipy und die daran gekoppelten SciKit-Module, und sehr leistungsfähige Werkzeuge zur Visualisierung wie Bokeh, Holoviews, Datashader und die gute alte Matplotlib. Und dann bietet Python obendrein noch Schnittstellen zu Software, die in der wissenschaftlichen Community ebenfalls manchmal benutzt wird, wie zum Beispiel die Desktop Environments KDE und GNOME oder die Office-Suiten OpenOffice und LibreOffice, alle verbreiteten Datenbanken und Volltext-Suchcluster wie Elasticsearch und Apache Solr. Und das Beste: die Python-Distribution Anaconda bringt das alles (bis auf die DC-Frameworks, Datenbanken etc.) fertig mit -- und noch viel mehr, das ich hier vergessen habe.
Hans schrieb: > Dirk schrieb: >> Weiss jemand den Grund für Python für wissenschaftliche Projekte? > > weil es gerade "cool" ist! Und das ist es geworden, weil? Genau: weil es so gut ist. > Ich mache für meine Diss alles in C++. > > Grund: Ich kann so gut C++, dass ich damit gleich schnell bin wie jemand > anderes in Python. Das ist bestenfalls naiv. > Ich postuliere daher, dass bald komplett Browser basierte Lösungen hipp > sein werden. Lustig: mit iPython und Jupyter gibt es interaktive, browserbasierte Visualisierungs- und Entwicklungswerkzeuge.
Dirk schrieb: > auf mehreren Seiten wird Phyton empfohlen für wissenschaftliche > Projekte wie z.B. Machine Learning, aber wenn ich mir die Benchmarks > zwischen Phyton und C++ anschaue, dann würde ich doch eher zu C++ > tendieren. Wissenschaftliche Arbeit heisst doch nicht, einen schnellen Algorithmus zu entwickeln, sondern einen Algorithmus schnell (weiter) zu entwickeln. Optimieren (in C/C++, Assembler, VHDL, ...) können Ingenieure, Programmierer, spätere Generationen. Fürs Forschen ist vor allem eine maximale Ausdruckskraft wichtig, und die ist z.B. mit umfangreichen Bibliotheken gegeben, die intuitiv und nicht kryptisch genutzt werden können.
Mit QT hat man in C++ alle Möglichkeiten um wissenschaftliche Daten zu visualisieren. Das Geschwindigkeit keine Rolle spielt halte ich für ein Gerücht. Die Argumentation das KI sowieso auf GPUs läuft ist auch ein verbreiteter Irrtum, viele Algos sind über GPUs gar nicht skalierbar und laufen auf CPUs schneller. Natürlich ist Python bei einfacheren Dingen der Weg des geringeren Widerstandes, kann aber je nach Anwendungsfall viel zu langsam sein. Für meine Diss. nutze ich C++ mit QT, alles andere wäre für meine Anwendung viel zu langsam. Es kommt meiner Meinung nach daher zu 100% auf den genauen Anwendungsfall an welche Sprache man wählt.
C++Daddy schrieb: > Das Geschwindigkeit keine Rolle spielt halte ich für ein > Gerücht. In vielen Fällen ist die Geschwindigkeit, in Grenzen, weitestgehend egal. Es geht erstmal darum die Funktionsfähigkeit zu demonstrieren und den Algoritmus praktisch einsetzbar zu machen. Ob man jetzt 100€ mehr oder weniger für Rechenzeit ausgeben muss, ist erstmal egal. Wenn er sich bewährt hat, wird sich irgendwann jemand daransetzen und ihn sauber und performanceorientiert implementieren. Sofern überhaupt Bedarf nach einer schnelleren Implementierung besteht.
C++Daddy schrieb: > Mit QT hat man in C++ alle Möglichkeiten um wissenschaftliche Daten zu > visualisieren. Das Geschwindigkeit keine Rolle spielt halte ich für ein > Gerücht. Die Argumentation das KI sowieso auf GPUs läuft ist auch ein > verbreiteter Irrtum, viele Algos sind über GPUs gar nicht skalierbar und > laufen auf CPUs schneller. > > Natürlich ist Python bei einfacheren Dingen der Weg des geringeren > Widerstandes, kann aber je nach Anwendungsfall viel zu langsam sein. > Für meine Diss. nutze ich C++ mit QT, alles andere wäre für meine > Anwendung viel zu langsam. > > Es kommt meiner Meinung nach daher zu 100% auf den genauen > Anwendungsfall an welche Sprache man wählt. Und wie oft läuft der Code einer Dissertation im Normalfall nachdem der Verfasser die Uni verlässt? Nie wieder...
C++Daddy schrieb: > Mit QT hat man in C++ alle Möglichkeiten um wissenschaftliche Daten zu > visualisieren. Ja! Auch mit MS Paint ist das möglich. Aber wie lange braucht man dafür, wenn man alles von hand selbst malen muss (bei QT fast alles)?
C++Daddy schrieb: > Mit QT hat man in C++ alle Möglichkeiten um wissenschaftliche Daten zu > visualisieren. Du hast auch mit C und Xlib alle Möglichkeiten, Daten zu visualisieren. Die Frage ist ja wieviel Aufwand das ist. Es gibt für Qt meines Wissens keine Bibliothek, die in vergleichbarer Flexibilität und Qualität Diagramme erstellt wie matplotlib, nicht mal näherungsweise. QtCharts ist jedenfalls ein totaler Witz, was das angeht. Das schafft es nicht mal selbst, sinnvolle Ticks an die Achsen zu schreiben. P.S.: Das Framework heißt "Qt".
Sven B. schrieb: > Im Ernst: wieviele verschiedene Bibliotheken muss ich mir > zusammensammeln, damit ich in C++ zumindest > * Plots > * FFT > * File I/O in sinnvollen Formaten (ok, das kann man notfalls selber > bauen) > * Fit-Routinen (LM, ...) > * Matrixoperationen > habe? Ich denke, mindestens so 4 ... und sind's in Python weniger??? Nein! Plots, File-IO usw würde ich sagen Qt... die bringt auch gleich eine nette IDE + compiler mit... seit einiger Zeit gibts QtCharts gratis... auch sehr brauchbar. Für den Rest könnte man die Math-Library von Intel nehmen... https://software.intel.com/en-us/mkl-developer-reference-c Also 2 libs to rule them all :) Da hat man dann auch gleich NL Optimizer, Neurale Netze,... dabei. Grafiken für wissenschaftliche Publikationen lässt man IMHO am besten latex zeichnen...pgfplots sei dank :) C++Daddy schrieb: > Natürlich ist Python bei einfacheren Dingen der Weg des geringeren > Widerstandes, kann aber je nach Anwendungsfall viel zu langsam sein. > Für meine Diss. nutze ich C++ mit QT, alles andere wäre für meine > Anwendung viel zu langsam. full ACK! Schreiber schrieb: > Es geht erstmal darum die Funktionsfähigkeit zu demonstrieren und > den Algoritmus praktisch einsetzbar zu machen. Ob man jetzt 100€ mehr > oder weniger für Rechenzeit ausgeben muss, ist erstmal egal. Naja, wenn du benchmarken willst, dann musst du im normalfall gegen eine optimierte Referenz bestehen... und die ist entweder Fortran oder C(++). Für jedes Problem gibt's das richtige Werkzeug... maxima, gnuplot, scilab und c++ sind meine bevorzugten. Dann wäre da noch http://toem.de/index.php/projects/impulse für VCD daten und https://labplot.kde.org/ für's "schnelle analysieren" von anderem zeugs Python sehe ich als Leatherman an... versucht alles zu können und ist überall schlechter wie das wirklich passende Werkzeug. Möglicherweise brauche ich ein paar Minuten länger in C++ weil ich ein paar Variablen deklarieren ein paar Klammern mehr braucht. Zur Problemlösung in openCV, fftw,... sind alle schritte ident... sind ja auch im hintergrund die selben Libraries! Für nicht triviale Probleme ist das Debuggen und verifizieren der wahre Zeitfresser... nicht das Kodieren! 73
Ich vergaß noch was zum Thema Grafiken plotten... Qwt und VTK sollten alle Bedürftnisse erfüllen um in einem Programm etwas anzuzeigen. 73
Hans schrieb: > Schreiber schrieb: >> Es geht erstmal darum die Funktionsfähigkeit zu demonstrieren und >> den Algoritmus praktisch einsetzbar zu machen. Ob man jetzt 100€ mehr >> oder weniger für Rechenzeit ausgeben muss, ist erstmal egal. > > Naja, wenn du benchmarken willst, dann musst du im normalfall gegen eine > optimierte Referenz bestehen... und die ist entweder Fortran oder C(++). Benchmarken muss man erst, NACHDEM man praktisch demonstriert hat, dass 1. der Algoritmus zumindest in der Theorie funktioniert 2. dieser lauffähig implementiert wurde 3. die Implementierung plausible Ergebnisse liefert 4. das ganze dokumentiert und nutzbar ist 5. es einen Algoritmus gibt, mit dem man die Performance vergleichen kann Optimiert wird oft erst dann, wenn das auch ökonomisch sinnvoll ist. Also wenn die Arbeitszeit durch geringere Kosten für Rechenzeit aufgewogen wird. Wenn das Programm zu langsam läuft, kann man sich einfach einen schnelleren Computer hinstellen oder bei Amazon AWS mehr Rechenleistung mieten.
Hans schrieb: > Python sehe ich als Leatherman an... versucht alles zu können und ist > überall schlechter wie das wirklich passende Werkzeug. ...und ist ein halbwegs brauchbarer ersatz für eine kleine Werkzeugkiste. Man muss erst was besseres griffbereit zur Hand haben, bevor man anfängt zu meckern oder vergleichen. Es geht in beiden Fällen nicht um die beste, sondern um die beste verfügbare Lösung. Wenn der betreffende Wissenschaftler nicht viel Erfahrung mit C++ hat, dafür aber mit Python in erträglicher Zeit "was lauffähiges" hinbekommt, dann nimmt er halt das. Matlab ist auch extrem beliebt, obwohl es teilweise unvorstellbar langsam ist. Aber es ist halt benutzerfreundlich, relativ einfach zu benutzen und verfügbar.
Hans schrieb: > und sind's in Python weniger??? Nein! Doch. numpy und matplotlib sind totale Standard-Libs, die immer überall leicht verfügbar sind. Bis du hingegen allein deinem Build-System beigebracht hast, fftw so zu linken dass es danach geht, bist du in Python für einen großen Teil der Aufgaben schon fertig. > Plots, File-IO usw würde ich sagen Qt... die bringt auch gleich eine > nette IDE + compiler mit... seit einiger Zeit gibts QtCharts gratis... > auch sehr brauchbar. Sorry, ne, ist es nicht. QtCharts ist nett, wenn du irgendwie eine bunte Linie flackern lassen willst in deiner Hipster-App, aber um -- wie in Matplotlib -- publikationswürdige Grafiken mit annehmbarem Aufwand zu erstellen ist es völlig ungeeignet. Allein der Line-Graph hat null Features, und die Wahl für z.B. Ticks und Labels die es automatisch macht ist völlig unansehlich (keine runden Zahlen auf den Ticks, etc). Qwt ist wohl ganz gut, aber kompliziert und auch eher für Echtzeit-Darstellung gedacht als zum Produzieren von vorzeigbaren PDFs. Ich denke ich kann das ganz gut beurteilen, weil ich beides viel mache. Ich schreibe oft Prototypen für Datenauswertung in Python, und muss das dann später in C++ nachbauen, weil es als Teil einer C++-Anwendung benötigt wird. Die C++-Variante zu schreiben kostet immer mindestens zehnmal so viel Zeit, und besonders die Visualisierung ist immer sehr schmerzhaft, und ich habe in meinem Leben schon erheblich mehr mit C++/Qt gearbeitet als mit Python. > Also 2 libs to rule them all :) Auf dem Papier, ja. Hast du das in der Praxis schonmal so angewendet? Auf die Featureliste auf der Webseite verweisen und die praktischen Hürden überwinden sind zwei sehr verschiedene Dinge. > C++Daddy schrieb: >> Natürlich ist Python bei einfacheren Dingen der Weg des geringeren >> Widerstandes, kann aber je nach Anwendungsfall viel zu langsam sein. >> Für meine Diss. nutze ich C++ mit QT, alles andere wäre für meine >> Anwendung viel zu langsam. > > full ACK! Aha, und das ohne dass du irgendeine Idee hast, was die Anwendung überhaupt ist? > Zur Problemlösung in openCV, fftw,... sind alle schritte ident... sind > ja auch im hintergrund die selben Libraries! Ok, ich schreibe mal den Python-Code auf, um ein CSV zu lesen und das Spektrum in ein PDF zu plotten, und du darfst mal den C++-Code (mit Build-System und allem) aufmalen um dasselbe zu tun:
1 | import numpy as np |
2 | import matplotlib.pyplot as plt |
3 | s = np.abs(np.fft.rfft(np.loadtxt("test.csv").T))
|
4 | plt.plot(np.fft.rfftfreq(s.shape[0]), s) |
5 | plt.savefig("test.pdf")
|
Das sind in C++ mindestens 40-60 Zeilen plus eine Viertelstunde rumgefrickel bis alle Header da sind wo der Compiler sie sucht und alle Libs gelinkt werden. Besonders unter Windows. Das liegt wie gesagt weniger an der Sprache, und mehr am Zustand des Ökosystems für diese Anwendung. > Für nicht triviale Probleme ist das Debuggen und verifizieren der wahre > Zeitfresser... nicht das Kodieren! Debuggen ist aber bei diesem Task hauptsächlich "jetzt bräuchte ich mal schnell das gegen das geplottet".
Sven B. schrieb: > Es gibt für Qt meines Wissens > keine Bibliothek, die in vergleichbarer Flexibilität vund Qualität > Diagramme erstellt wie matplotlib, nicht mal näherungsweise. Aber sicher, du musst nur PyQt verwenden ;) Oliver
Schreiber schrieb: > NACHDEM man praktisch demonstriert hat naja und auch hier bringt dir python keine vorteile... richtig zeit rinnt ins debuggen und verifizieren, nicht ins kodieren! und wenn ich zuerst in python zeige, dass es geht und danach alles in fortran oder c(++) neu mache um schneller zu werden, dann mache ich doch den algorithmus gleich in einer compiler sprache! Wie gesagt, gestern Matlab - heute Python. 73
Oliver S. schrieb: > Sven B. schrieb: >> Es gibt für Qt meines Wissens >> keine Bibliothek, die in vergleichbarer Flexibilität vund Qualität >> Diagramme erstellt wie matplotlib, nicht mal näherungsweise. > > Aber sicher, du musst nur PyQt verwenden ;) Hä, wovon redest du? PyQt ist eine Python-Schnittstelle für die C++-Bibliothek Qt. Das ist völlig orthogonal zum Thema ... > naja und auch hier bringt dir python keine vorteile... richtig zeit > rinnt ins debuggen und verifizieren, nicht ins kodieren! Richtig Zeit geht bei wissenschaftlichen Anwendungen in's nachdenken darüber was man eigentlich machen will. Und dafür ist Python besser, weil es weniger im Weg steht und viel schneller Feedback bietet (z.B. interaktive Notebooks etc).
Hans schrieb: > Ich vergaß noch was zum Thema Grafiken plotten... > > Qwt und VTK sollten alle Bedürftnisse erfüllen um in einem Programm > etwas anzuzeigen. Bei wissenschaftlichen Projekten geht es nicht darum etwas in einem Programm anzuzeigen, sonder in einer peerreviewten Publikation zu veröffentlichen. Und nein, Qwt ist dafür genauso wenig geeignet wie Excel Plots. Um nochmal auf deinem früheren Beitrag zurückzukommen: Hans schrieb: > Es ist richtig faszinierend zu sehen wie schnell Javascript in einem > modernen Browser läuft (dank JIT eigentlich kein wunder)... mit etwas > d3.js gewürzt sind da 10MB Rohdaten in 0,nix verarbeitet und > visualisiert. Funktioniert das System auch noch, wenn man es mit 10 oder 100GB zu tun hat? Funkionieren bedeutet in diesem Fall, dass ich in maximal 20 Sekunden den fertigen Plot habe. Wenn nicht, ist es nutzlos, weil ich dann wieder 2 Systeme brauche.
Sven B. schrieb: > Das sind in C++ mindestens 40-60 Zeilen plus eine Viertelstunde > rumgefrickel bis alle Header da sind wo der Compiler sie sucht und alle > Libs gelinkt werden. Besonders unter Windows. Das liegt wie gesagt > weniger an der Sprache, und mehr am Zustand des Ökosystems für diese > Anwendung. Dann verwendst du schlicht eine ungeeignete Entwicklungsumgebung! (Und damit ist nicht nur die IDE gemeint!) "qt csv files" gegooglet und 1. Hit von Stack-Exchange: https://stackoverflow.com/questions/27318631/parsing-through-a-csv-file-in-qt Zwar nur CSV parsen, aber nicht ineffizient. Dein beschriebenes Beispiel wäre in Matlab/Scilab ein 2-Zeiler... Ist damit Python jetzt automatisch schlechter??? Was habt ihr eigentlich mit eurem "in ein pdf plotten"... Mit dem Latex IEEE Template und TikZ/pgfplots braucht einem sowas doch überhaupt nicht zu kümmern! Btw: Ja fftw, mkl, petsc und konsorten habe ich am laufen. Und ums Speicher Alignment kümmere ich auch teilweise auch per Hand. Cachelines wollen richtig gefüllt werden!
Sven B. schrieb: > Hä, wovon redest du? PyQt ist eine Python-Schnittstelle für die > C++-Bibliothek Qt. Das ist völlig orthogonal zum Thema ... Ok, für dich noch extra die anscheinend fehlende Info: [Ironie]...[/Ironie] Qt ist immerhin so toll, daß sich jemand die Mühe gemacht hat, dafür eine Python-Schnistelle zu schreiben. Oliver
mh schrieb: > Bei wissenschaftlichen Projekten geht es nicht darum etwas in einem > Programm anzuzeigen, sonder in einer peerreviewten Publikation zu > veröffentlichen. > Und nein, Qwt ist dafür genauso wenig geeignet wie Excel Plots. Hans schrieb: > Qwt und VTK sollten alle Bedürftnisse erfüllen um in einem Programm > etwas anzuzeigen. Ähm... geht's jetz um Plots zur Laufzeit oder für Publikationen? Wie gesagt, publizieren tut man mit dem Tex-Template des jeweiligen Journals... und pgfplots macht dir dann genau dem template entsprechende Grafiken. Als nächstest kommt noch jemand und zeichnet Flussdiagramme öä. in Visio oder so... dafür gibts tikz. Beides ist dank der riesigen Anzahl an Beispielen ziemlich einfach zu nutzen. 73
Hans schrieb: > Sven B. schrieb: >> Das sind in C++ mindestens 40-60 Zeilen plus eine Viertelstunde >> rumgefrickel bis alle Header da sind wo der Compiler sie sucht und alle >> Libs gelinkt werden. Besonders unter Windows. Das liegt wie gesagt >> weniger an der Sprache, und mehr am Zustand des Ökosystems für diese >> Anwendung. > > Dann verwendst du schlicht eine ungeeignete Entwicklungsumgebung! (Und > damit ist nicht nur die IDE gemeint!) > > "qt csv files" gegooglet und 1. Hit von Stack-Exchange: > https://stackoverflow.com/questions/27318631/parsing-through-a-csv-file-in-qt > > Zwar nur CSV parsen, aber nicht ineffizient. Ich verstehe wirklich nicht, wovon du redest. Das sind doch schon deine 60 Zeilen, und du hast nur das "np.loadtxt(test.csv)" ersetzt. Von FFT, Plot oder Export ist da noch gar nichts. Und im Satz davor wirfst du mir vor, dass ich nur alles falsch mache. Hä?? > Dein beschriebenes Beispiel wäre in Matlab/Scilab ein 2-Zeiler... Ist > damit Python jetzt automatisch schlechter??? Ob es 2 oder 4 Zeilen sind, ist egal, aber ob es 4 oder 60 sind eher nicht so. > Was habt ihr eigentlich mit eurem "in ein pdf plotten"... Mit dem Latex > IEEE Template und TikZ/pgfplots braucht einem sowas doch überhaupt nicht > zu kümmern! Auch hier kapiere ich überhaupt nicht, wovon du (und andere) reden. Es geht doch nicht um eine API, mit der ich eine rote Linie malen kann! Es geht darum, dass ich sagen kann "ich will das gegen das geplottet haben mit Titel X und Achsenbeschriftung Y und logarithmischen Achsen und Grid und jetzt bitte hierhin exportieren" und fertig, und du das nicht selber schreiben musst. Die Grafik-API, die aus dieser Logik der Plot-Bibliothek dann Linien in ein PDF oder PNG oder auf den Bildschirm malt, hast du natürlich überall, aber die Logik der Plot-Bibliothek eben nicht. > Btw: Ja fftw, mkl, petsc und konsorten habe ich am laufen. Und ums > Speicher Alignment kümmere ich auch teilweise auch per Hand. Cachelines > wollen richtig gefüllt werden! Wenn das in C++ nicht aufwändiger ist als mein Beispiel, dann kannst du es ja einfach mal hinschreiben. Ich hab's in Python hingeschrieben, hat 30 Sekunden gekostet. Entweder du kannst es in 30 Sekunden in C++ machen, oder du stimmst zu dass es in C++ länger dauert, oder ich verstehe überhaupt nicht worüber wir eigentlich diskutieren.
:
Bearbeitet durch User
Warum nutzt man den kein C# mit .Net Core? Es ist doch laut diesen Benchmarks schneller und läuft auch auf Linux. Mit den richtigen Controls lassen sich auch sehr schöne Graphen erstellen. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=csharpcore&lang2=python3
Hans schrieb: > Ähm... geht's jetz um Plots zur Laufzeit oder für Publikationen? Bei mir gehts um beides, und bei mir sind die zu 90% identisch. > Wie gesagt, publizieren tut man mit dem Tex-Template des jeweiligen > Journals... und pgfplots macht dir dann genau dem template entsprechende > Grafiken. Also brauche ich 2 verschiedene Systeme. Eins um mir zur Laufzeit meine Daten anzuschauen und eins fürs Publizieren. Wie verhält sich pgfplots, wenn ich 10GB an Daten habe? Was mache ich, wenn ich ein 2D Datensatz habe und ihn auf ein Karte mit Umrissen der Kontinente darstellen will? Was muss ich machen, wenn ich die Projektion ändern will? Was mache ich, wenn ich von einem Kollegen einen Datensatz bekomme "zum schnellen Vergleich" und die sind jetzt im netCDF Format oder hdf5 statt in einer ".dat"? ...
Da es noch nicht erwähnt wurde, mit QT meine ich natürlich auch unter anderem die Nutzung von qcustomplot: http://www.qcustomplot.com/ Hab bisher nur positive Erfahrung damit gemacht und es ist nicht wirklich kompliziert, es gibt viele Beispiele, User interactions, etc. Aber wie gesagt alles Wohlfühlfaktor des jeweiligen Coders, ich denke es kommt immer auf den individuellen Usecase an, bei mir sind es eben globale Optimierungen extrem aufwendiger Funktionen daher kommt nur C++ in Frage weil ich sonst bei einem Durchlauf eine Woche auf das Ergebnis warten muss. Daher, sollte Performance eine Rolle spielen, dann kann ich nur für C++ die Lanze brechen und sagen mit QT und qcustomplot ist es kein großes Ding Daten gut und vor allem sehr hübsch darzustellen. Vorausgesetzt man fühlt sich ohnehin in C++ sehr wohl wie ich ;-)
Hans, du musst mal ein bischen über deinen Teller-(oder Rechner)rand hinausschauen. Ein Pytonscript kann ich nehmen und auf einem Rechner oder einem virtuellen Cloudrechner ausführen, völlig problemlos. Dein toller C Code muss ich erst mal compilieren, dann muss ich die passenden binären 3rd party libs auftreiben usw bis ich das alles vieleicht irgendwann zusammengelinkt und ans Laufen kriege. Mit Sprachen wie Phyton oder Java nehme ich den Sourcetopf und habe den Kram in Nullkommanix am Laufen egal auf welcher Plattform. Und genau das macht den Vorteil aus.
Dirk schrieb: > Warum nutzt man den kein C# mit .Net Core? Weil die Leute ernsthaft arbeiten wollen!?
Sorry, ihr seid alle weltfremd! 10Gig Daten in ein PDF plotten ??? Meine FEM Rechnungen ergeben schon Rohdaten in der Größenordnung, aber ich plotte doch nicht jeden einzelnen Vector! Da ist noch einiges an post-processing dazwischen. Dann kommen einige 100 Datenpunkte raus die dann eine schöne Kurve ergeben. Und ganz ehlich, wenn ich publiziere, dann sind das normalerweise Vergleiche mit anderen Rechnungen. Also z.B wie genau bin ich im Vergleich zur analytischen Lösung, oder wie schnell konvergiere ich im Vergleich zu einem anderen preconditioner. In der Anwendung interessiert mich ganz was anderes... normalerweise das transiente Ergebnis! IMHO habe nicht ich die Scheuklappen auf, sondern 90% der mitkommentierenden. Wie oben beschrieben nutze ich viele unterschiedliche Tools. Außerdem gibt's neben Python noch ganz andere Frameworks. wie z.B. R... Mir ist bewusst, das es für Python sogar Module für algebraisches Rechnen gibt. Trotzdem nutze ich für diese Dinge Maxima, da das einfach weniger Einschränkungen hat (und weil ich mich damit auskenne). Bei Scilab/Octave/Matlab gilt ähnliches. Labplot finde ich fürs Visualisieren auch unschlagbar. Python ist kein Allerheilmittel. Auch hier brauchst du binäre libs im Hintergrund! fftw, opencv,... das sind alles native-libs mit python bindings. hast du die nicht auf deinem super cloud-rechner zur Verfügung, dann hilft dir der Python Interpreter auch nicht! Vergleicht doch einmal die C++ und Python Examples von OpenCV. Der Unterschied im Codeumfang ist oft minimal! Sicher kann ich auch mit einem Hammer eine Schraube ins Holz bringen... nur wieso sollte ich das wenn ich einen Akkuschrauber habe. Mal heißt der Akkuschrauber bash, dann c++ und im nächsten Fall ist's das Microwave Studio von CST :) Es mag sogar sein, dass der Akkuschrauber für manche Personen in manchen Aufgabenstellungen python heißt. Ich für meinen Teil finde jedenfalls die Sprache nicht "schön" und auch nicht gut lesbar. Aber für gewöhnlich gibt's im Baumarkt mehrere Typen Akkuschrauber.. man muss einfach nur einen in der Werkzeugkiste haben! mh schrieb: > Wie verhält sich pgfplots, wenn ich 10GB an Daten habe? Was mache ich, > wenn ich ein 2D Datensatz habe und ihn auf ein Karte mit Umrissen der > Kontinente darstellen will? Was muss ich machen, wenn ich die Projektion > ändern will? Was mache ich, wenn ich von einem Kollegen einen Datensatz > bekomme "zum schnellen Vergleich" und die sind jetzt im netCDF Format > oder hdf5 statt in einer ".dat"? .. Das ist schon ein nettes Beispiel. Schon mal geschaut was gnuplot und labplot so können? zumindest hast du dir nicht angesehen was pgfplots ist! C++Daddy schrieb: > Da es noch nicht erwähnt wurde, mit QT meine ich natürlich auch unter > anderem die Nutzung von qcustomplot: http://www.qcustomplot.com/ > > Hab bisher nur positive Erfahrung damit gemacht und es ist nicht > wirklich kompliziert, es gibt viele Beispiele, User interactions, etc. > > Aber wie gesagt alles Wohlfühlfaktor des jeweiligen Coders, ich denke es > kommt immer auf den individuellen Usecase an, bei mir sind es eben > globale Optimierungen extrem aufwendiger Funktionen daher kommt nur C++ > in Frage weil ich sonst bei einem Durchlauf eine Woche auf das Ergebnis > warten muss. Daher, sollte Performance eine Rolle spielen, dann kann ich > nur für C++ die Lanze brechen und sagen mit QT und qcustomplot ist es > kein großes Ding Daten gut und vor allem sehr hübsch darzustellen. > Vorausgesetzt man fühlt sich ohnehin in C++ sehr wohl wie ich ;-) So sehe ich das auch! Irgendwie spannend... wenn man Arduino und Python als nicht uneingeschränkt wunderbar bezeichnet ist sofort die Hölle los. Btw: 16 Zeilen C++ Code sind notwendig um ein CSV in ein PDF zu verwandeln. Ich würde das so aber nicht verwenden... QtCharts ist in erster Linie dazu da auf der GUI was anzuzeigen. 73
1 | QFile file("foo.csv"); |
2 | QTextStream stream(&file); |
3 | |
4 | QChart *chart = new QChart(); |
5 | QChartView view(chart); |
6 | |
7 | file.open(QIODevice::ReadOnly); |
8 | |
9 | while (!stream.atEnd()) { |
10 | QStringList parts = stream.readLine().split(QRegExp("\\s+"), QString::SkipEmptyParts); |
11 | series->append(parts[0].toDouble(), parts[1].toDouble()); |
12 | }
|
13 | |
14 | chart->addSeries(series); |
15 | chart->createDefaultAxes(); |
16 | chart->setTitle("Simple line chart example"); |
17 | QPdfWriter writer("bar.pdf"); |
18 | QPainter painter(&writer); |
19 | view.render(&painter); |
20 | painter.end(); |
Hans schrieb: > Sorry, ihr seid alle weltfremd! Vllt. beschäftigen wir uns einfach mit Dinge die sich nicht vergleichen lassen. Ich habe mal hervorgehoben: Hans schrieb: > MEINE FEM Rechnungen ergeben schon Rohdaten in der Größenordnung, aber > ICH plotte doch nicht jeden einzelnen Vector! > Da ist noch einiges an post-processing dazwischen. Dann kommen einige > 100 Datenpunkte raus die dann eine schöne Kurve ergeben. Aus meinen Daten sind häufig Karten zu erstellen. Die Bilder sind am Ende natürlich nicht 10GB groß, aber warum sollte ich die Daten selbst interpolieren? Das mach matplotlib für mich. Hans schrieb: > Das ist schon ein nettes Beispiel. Schon mal geschaut was gnuplot und > labplot so können? Mit gnuplot habe ich viele Jahre gearbeitet. Das ist die beste Alternative, die du bis jetzt genannt hast. Aber ich möchte nie wieder zurück, nachdem ich matplotlib kenne. labplot? Meinst du das: https://labplot.kde.org/documentation/ ? Wenn etwas wie matplotlib für C++ existieren würde, ich würde es sofort nutzen. Gibt es aber leider nicht.
mh schrieb: > Hans schrieb: >> Sorry, ihr seid alle weltfremd! > Vllt. beschäftigen wir uns einfach mit Dinge die sich nicht vergleichen > lassen. das will ich auch hoffen! sonst hätte einer von uns beiden am ende problem mit plagiatsvorwürfen :) mh schrieb: > labplot? Meinst du das: https://labplot.kde.org/documentation/ ? Ja, meine ich. Ok, online-doku gibt's nicht... aber es kommt eine offline-hilfe mit: https://docs.kde.org/trunk4/en/extragear-edu/labplot2/labplot2.pdf Youtube wäre auch noch eine Quelle "leider" KDE only... aber nachdem das mein default-desktop ist, für mich kein Problem... Wie oben erwähnt wäre dann da noch Impulse: http://toem.de/index.php/projects/impulse Das ist ein Eclipse Plugin... damit lassen sich äußerst interessante dinge anstellen. Richtig gut zum Debuggen! Ich schreibe zu jedem Zeitschritt allerhand debug-werte in ein VCD file (Value Change Dump). Damit bekomme ich dann zu jedem Simulationsmodell hiarchisch alle Statevariablen zur Auswahl und kann beliebig gegeneinander plotten. z.B. State-Änderung in der Statemachine im Hysteresemodell gegenüber anzahl der verworfenen Steps... alles easy :) 73 73
Hans schrieb: > Btw: 16 Zeilen C++ Code sind notwendig um ein CSV in ein PDF zu > verwandeln. Jetzt fehlt nur noch die FFT, dann haben wir schon fast einen Vergleich. Außer, dass hier natürlich das komplette drumrum fehlt, sprich Includes, Main-Funktion, Build-System, ... > Ich würde das so aber nicht verwenden... QtCharts ist in erster Linie > dazu da auf der GUI was anzuzeigen. Und, hast du mal ein PDF da was dieser Code für einen Sinus produziert? Dann kann ich ja mal eins mit matplotlib generieren, und wir vergleichen mal die Qualität der Diagramme ... > while (!stream.atEnd()) { > QStringList parts = stream.readLine().split(QRegExp("\\s+"), > QString::SkipEmptyParts); > series->append(parts[0].toDouble(), parts[1].toDouble()); > } Das ist fürchterlicher Code, weil: - crasht wenn eine Zeile leer ist oder nur einen Wert enthält (bestimmt 80% der CSVs die ich so sehe haben am Ende der letzten Zeile ein \n -> Crash) - 6 (!) Memory Allocations, um zwei Zahlen zu lesen: QListData, QRegExpPrivate, QStringData für das Argument vom RegExp ("\\s+"), QStringData für die ganze Zeile, und zwei QStringData für die zwei Listen-Elemente -- plus natürlich das eventuelle realloc für die Daten von der Series. Nötig sind genau null. - regulärer Ausdruck ist hier Overkill, aber wenn schon, dann wenigstens QRegularExpression und nicht das veraltete QRegExp und außerhalb der Schleife initialisieren - besser: QString::section() verwenden oder noch besser, QTextStream::operator>>(double) -- wozu hat man sonst den Text Stream :D Von Fehlerbehandlung fangen wir gar nicht an -- gut, das kann man sich in dem Kontext tatsächlich oft sparen, das gebe ich zu. Ist aber trotzdem nett, wenn es da ist. Ich würde quasi wetten, dass die Python-Version hier auch nicht signifikant langsamer ist. Die kompilieren wenigstens ihren RegExp vorher, wenn man einen kurzen Blick in die Implementierung wirft. So kannst du dir das mit C++ aus Performance-Gründen auch sparen ...
:
Bearbeitet durch User
Python und C++ sind so unterschiedlich. Entweder man macht zeiteffektives Scripting für eine virtuelle Maschine oder man will hocheffizienten Maschinencode und keine Grenzen und nimmt dafür vielleicht ein wenig mehr Aufwand in Kauf. Den Aufwand hat man aber meiner Meinung nach sowieso nur 1x denn nach einiger Zeit hat jeder sowieso eine Sammlung mit Klassen für alles Nötige und benutzt sie ein Leben lang. Die meisten Sprachen haben ihre Daseinsberechtigung, am Ende hängt es davon ab worauf der Fokus liegen soll und das wurde bisher noch nicht gesagt.
C++Daddy schrieb: > Mit QT hat man in C++ alle Möglichkeiten um wissenschaftliche Daten zu > visualisieren. Das geht mit Python natürlich auch: mit PyQt und und PySide gibt es sogar gleich zwei Bibliotheken, die Python und Qt verbinden. > Natürlich ist Python bei einfacheren Dingen der Weg des geringeren > Widerstandes, kann aber je nach Anwendungsfall viel zu langsam sein. > Für meine Diss. nutze ich C++ mit QT, alles andere wäre für meine > Anwendung viel zu langsam. Ich vermute, Du hast es nicht einmal versucht, denn wenn Du Python kennen würdest, dann hättest Du von den Qt-Bindings gewußt. Insofern ist Deine Aussage eine reine Behauptung, die nur auf Vermutungen basiert.
C++Daddy schrieb: > Den Aufwand hat man aber meiner Meinung nach sowieso nur 1x denn nach > einiger Zeit hat jeder sowieso eine Sammlung mit Klassen für alles > Nötige und benutzt sie ein Leben lang. Das sehe ich anders. In Scipy kann ich auch mal eben schnell einen Wavelet-Filter auf meine Daten anwenden, und schauen ob das für meinen Anwendungsfall hilfreich ist. Dauert wenige Minuten. Dann kann ich vielleicht feststellen es ist gar nicht so gut, und was anderes machen. Ich muss eben nicht 10 Tage investieren, um die blöden Wavelets zu implementieren. Und Algorithmen dieser Art gibt es sehr viele, die eigentlich in keiner gängigen C++-Bibliothek so richtig verfügbar sind. Bestenfalls findet man noch Codeschnipsel auf github, die vielleicht funktionieren und vielleicht sogar das richtige Ergebnis berechnen. Performance-Diskussionen führen ohne konkretes Beispiel eigentlich nie zu irgendwas; ordentlicher numpy-Code kann in vielen Fällen relativ schnell sein, bzw. einfach "schnell genug". Ich stelle mal in den Raum, dass viele der Menschen, die nur mit C++ arbeiten, auch gar nicht wissen wie man Python-Code mit numpy so schreibt, dass er nicht langsam ist, weil es da ein relativ eigenes Set von Tricks gibt.
Auch wenn ich Python so gar nicht mag, einen großen Vorteil sehe ich für Leute, die es einfach nur als Werkzeug nutzen: Es ist universell einsetzbar. So wie man damit seine Daten verarbeiten kann, kann man damit Makros in LibreOffice schreiben, Geräte steuern oder in Minecraft rumprogrammieren...
C++Daddy schrieb: > Aber wie gesagt alles Wohlfühlfaktor des jeweiligen Coders, ich denke es > kommt immer auf den individuellen Usecase an, bei mir sind es eben > globale Optimierungen extrem aufwendiger Funktionen daher kommt nur C++ > in Frage weil ich sonst bei einem Durchlauf eine Woche auf das Ergebnis > warten muss. Daher, sollte Performance eine Rolle spielen, dann kann ich > nur für C++ die Lanze brechen und sagen mit QT und qcustomplot ist es > kein großes Ding Daten gut und vor allem sehr hübsch darzustellen. > Vorausgesetzt man fühlt sich ohnehin in C++ sehr wohl wie ich ;-) Lustigerweise bin ich selbst ein großer Freund von C++, in anderen Threads hier wurde mir sogar schon vorgeworfen, ich sei ein "Fänboi". ;-) Aber hier liegst Du, gemeinsam mit Hans, leider vollkommen daneben. Wenn Ihr ein bisschen Ahnung nicht nur von C++, sondern eben auch von Python hättet -- und dadurch also überhaupt erst für den Vergleich zwischen den beiden, oder auch nur für Aussagen über Python qualifiziert wärt -- dann wüsstet Ihr, daß es gar nicht um eine Frage des "entweder oder", sondern stattdessen vielmehr um ein "entweder und" geht. Du kannst also die "globalen Optimierungen extrem aufwändiger Funktionen" problemlos in C++ machen, das dank Boost.Python ganz einfach in Python einbinden und das Datenhandling, die Vor- und Nachbearbeitung, sowie die Visualisierung trotzdem mit Python und seinen leistungsfähigen Libraries machen. Vorteil: der schnelle Code läuft weiterhin nativ auf CPU oder GPU und ist daher genau so schnell wie Deine C++-Binaries, aber dafür hast Du all die vielen flexiblen, leistungsfähigen Libraries von Python für die weniger performancekritischen Dinge zur Verfügung. Leider fürchte ich allerdings, daß Du und der liebe Hans hier wie die Blinden von den Farben redet, weil Ihr beide Python nicht kennt und auch nicht für Eure Anwendungsfälle ausprobiert habt. Stattdessen behauptet Ihr einfach mal ins Blaue hinein, ausgerechnet für Eure Anwendungsfälle sei Python nicht geeignet, und faselt dann auch noch von "wissenschaftlichem Arbeiten". Wissenschaftliches Arbeiten funktioniert allerdings nicht auf Basis von Behauptungen oder Vermutungen, sondern so, daß man zuerst eine Hypothese aufstellt und sie dann verifiziert. Ihr hingegen spart Euch den Schritt der Verifikation gleich ganz, sondern stellt Eure Hypothesen gleich als Tatsachen dar. Das erinnert mich leider viel mehr an die Geschichte von "für den, der nur einen Hammer hat, sieht jedes Problem wie ein Nagel aus" als an wissenschaftliches Arbeiten. Und als jemand, der beruflich seit Jahren mit der Analyse und Visualisierung großer und größter Datenmengen (mehrere 100 GB sind da keine Seltenheit) beschäftigt ist und dabei sowohl Python als auch C++ und sie gern oft in Kombination benutzt, stelle ich jetzt mal zwei Gegenhypothesen auf: Wenn Ihr Python einmal für Eure Anwendungsfälle ausprobiert hättet, wärt Ihr erstens erstaunt, wie performant es in Wirklichkeit ist, und Ihr könntet zweitens auch etwas Sachkompetenz in diese Diskussion einbringen. An Ende ist es bei Einzelentwicklungen ja so: bis ich aus den Daten eine Erkenntnis gewonnen habe, kostet das die Summe aus der Entwicklungs- und der Laufzeit meines Programms. Ob ich da eine halbe Stunde Entwicklungs- und zwei Stunden Laufzeit oder zwei Stunden Entwicklungs- und eine halbe Stunde Laufzeit summiere: das Ergebnis ist am Ende dasselbe. Da reduziert sich die große Frage nur noch auf auf meine persönliche Vorliebe, ob ich lieber selbst arbeite, oder ob ich lieber den Rechner schwitzen lasse und währenddessen mit der netten Kollegin einen Kaffee trinken gehe. ;-)
Sven B. schrieb: > Und, hast du mal ein PDF da was dieser Code für einen Sinus produziert? Du hast es immer noch nicht kapiert! Wenn ich einen hochqualitativen Plot brauche mache ich sowas z.b. in gnuplot: plot [-10:10] sin(x),atan(x),cos(atan(x)) Implementiere ich einen Algorithmus ist es ziemlich egal in welcher Sprache ich arbeite! rosetta code bietet da viele Beispiele:
1 | double *cholesky(double *A, int n) { |
2 | double *L = (double*)calloc(n * n, sizeof(double)); |
3 | if (L == NULL) |
4 | exit(EXIT_FAILURE); |
5 | |
6 | for (int i = 0; i < n; i++) |
7 | for (int j = 0; j < (i+1); j++) { |
8 | double s = 0; |
9 | for (int k = 0; k < j; k++) |
10 | s += L[i * n + k] * L[j * n + k]; |
11 | L[i * n + j] = (i == j) ? |
12 | sqrt(A[i * n + i] - s) : |
13 | (1.0 / L[j * n + j] * (A[i * n + j] - s)); |
14 | }
|
15 | |
16 | return L; |
7 echte Statements
1 | def cholesky(A): |
2 | L = [[0.0] * len(A) for _ in range(len(A))] |
3 | for i, (Ai, Li) in enumerate(zip(A, L)): |
4 | for j, Lj in enumerate(L[:i+1]): |
5 | s = sum(Li[k] * Lj[k] for k in range(j)) |
6 | Li[j] = sqrt(Ai[i] - s) if (i == j) else \ |
7 | (1.0 / Lj[j] * (Ai[j] - s)) |
8 | return L |
6 statements. fft?? ok:
1 | def fft(x): |
2 | N = len(x) |
3 | if N <= 1: return x |
4 | even = fft(x[0::2]) |
5 | odd = fft(x[1::2]) |
6 | T= [exp(-2j*pi*k/N)*odd[k] for k in range(N//2)] |
7 | return [even[k] + T[k] for k in range(N//2)] + \ |
8 | [even[k] - T[k] for k in range(N//2)] |
1 | void fft(CArray& x) |
2 | {
|
3 | const size_t N = x.size(); |
4 | if (N <= 1) return; |
5 | |
6 | // divide
|
7 | CArray even = x[std::slice(0, N/2, 2)]; |
8 | CArray odd = x[std::slice(1, N/2, 2)]; |
9 | |
10 | // conquer
|
11 | fft(even); |
12 | fft(odd); |
13 | |
14 | // combine
|
15 | for (size_t k = 0; k < N/2; ++k) |
16 | {
|
17 | Complex t = std::polar(1.0, -2 * PI * k / N) * odd[k]; |
18 | x[k ] = even[k] + t; |
19 | x[k+N/2] = even[k] - t; |
20 | }
|
21 | }
|
6 zu 10 statements... wieder kein Beinbruch! du willst numpy verwenden? OK!
1 | >>> from numpy.fft import fft |
2 | >>> from numpy import array |
3 | >>> a = array([1.0, 1.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0]) |
4 | >>> print( ' '.join("%5.3f" % abs(f) for f in fft(a))
|
mit der fftw:
1 | #include <fftw.h> |
2 | ...
|
3 | {
|
4 | fftw_complex in[N], out[N]; |
5 | fftw_plan p; |
6 | ...
|
7 | p = fftw_create_plan(N, FFTW_FORWARD, FFTW_ESTIMATE); |
8 | ...
|
9 | fftw_one(p, in, out); |
10 | ...
|
11 | fftw_destroy_plan(p); |
12 | }
|
4 zu 5 statements... zugegeben, die daten müssen in c noch befüllt und ausgegeben werden... So und jetzt machen wir das noch in einer anwendungsspezifischen sprache: cholesky-decomposition: 1ne zeile in scilab
1 | [R]=chol(X) |
fft: 1ne zeile in scilab
1 | X=fft(A [,sign] [,option]) |
plot: 1ne zeile in scilab
1 | plot(x,y,<LineSpec>,<GlobalProperty>) |
Es mag schon sein, dass DU mit python alleine auskommst, ich tue es nicht und will es auch nicht! Mein Simulator hat nicht einmal eine GUI! Da geht die Problembeschreibung als javascript-code rein und verlässt die simulation als VCD file. Wieso? Weil ich automatisieren will und muss! ich generiere z.B. 100 JS files in bash (ja, bash!), und niete dann meine CPU mit parallel (gnu parallel meine ich ) nieder... auch wieder aus einem bash script. Selbiges trifft zu für meine FEM Rechnungen. Übrigens läuft da javascript weil die V8-engine wesentlich schneller ist als ein python interpreter. Wenn ich die Daten mir ansehen will nutze ich Impulse oder gtkwave (zwar nur in zwangslagen... hin und wieder kommt man aber nicht aus). Das ist für sowas gemacht! Schau dir an was zu data-cursors in der doku zu deiner geliebten matplotlib steht: https://matplotlib.org/examples/pylab_examples/cursor_demo.html Übersetzt: In dem Fall schlägst die Schraube mit dem Hammer ein! Ich gebe gerne zu, dass C++ eine gewaltige Einstiegshürde sein kann weil es eben eine komplexe Sprache ist. Python ist einfacher gestrickt (das bitte nicht negativ verstehen!) und daher einfacher zu erlernen. Das macht es sicher für viele attraktiv... immerhin willst du an deinem wissenschaftlichen Problem arbeiten und nicht C++ lernen. Ich kann C++ ausreichend gut (ich werde seit 17 Jahren dafür bezahlt!). Ich habe eine für mich effiziente Entwicklungsumgebung gefunden (Slackware, Qt5, Impulse, LaTex, gnuplot, Maxima,...). Ich beschäftige mich mit Algorithmen und nicht mit plotten. Daher habe ich postuliert, dass ich in C++ nicht langsamer bin als jemand anderes in Python. Und es finden sich im Netz genügend beispiele die das bestätigen. z.B. Cukoo-search https://github.com/Ashwin-Surana/cuckoo-search/blob/master/cuckoonew.py https://github.com/cuckoo-search/IASVP-cpp/blob/master/includes/CuckooSearch.h python etwa 100 zeilen; c++ knapp drüber... Mir gefällt die python als Sprache schon nicht. warum soll ich mich damit quälen? Sven B. schrieb: > C++Daddy schrieb: >> Den Aufwand hat man aber meiner Meinung nach sowieso nur 1x denn nach >> einiger Zeit hat jeder sowieso eine Sammlung mit Klassen für alles >> Nötige und benutzt sie ein Leben lang. > > Das sehe ich anders. In Scipy kann ich auch mal eben schnell einen > Wavelet-Filter auf meine Daten anwenden, und schauen ob das für meinen > Anwendungsfall hilfreich ist. Dauert wenige Minuten. Dann kann ich > vielleicht feststellen es ist gar nicht so gut, und was anderes machen. > Ich muss eben nicht 10 Tage investieren, um die blöden Wavelets zu > implementieren. Und Algorithmen dieser Art gibt es sehr viele, die > eigentlich in keiner gängigen C++-Bibliothek so richtig verfügbar sind. > Bestenfalls findet man noch Codeschnipsel auf github, die vielleicht > funktionieren und vielleicht sogar das richtige Ergebnis berechnen. Wie gesagt, man muss nur für jedes Problem seine Tools haben... für den Fall wäre es bei mir Scilab oder Octave. Mein Bruder bevorzugt R ... und? wo ist das Problem??? Sven B. schrieb: > Ich stelle mal in den Raum, > dass viele der Menschen, die nur mit C++ arbeiten, auch gar nicht wissen > wie man Python-Code mit numpy so schreibt, dass er nicht langsam ist, > weil es da ein relativ eigenes Set von Tricks gibt. Ich stelle in den Raum, dass das generell so ist und kein Problem, das python/numpy für sich gepachtet hat. Man kann durchaus in C++ auch sehr langsamen Code produzieren. Und nochmal, wenn man ein Problem hat, bei dem man große Teile der Algorithmen selbst machen muss, dann ist es scheiß egal ob man Python oder C/C++ nimmt. Libraries gibt's für beide Sprachen wie Sand am Meer. die GSL (gnu scientific library... für die, die sie nicht kennen) beinhaltet laut header z.B. seit 14 Jahren die wavelets die einem in C/C++ angeblich 10 Tage... Beispielcode hist hier: https://www.gnu.org/software/gsl/doc/html/dwt.html Ansonsten beinhaltet die Armadillo Library auch einiges an funktionalität. Und nein, um schnell mal Daten durch den Wolf zu jagen nehme ich für gewöhnlich nicht C/C++ sondern andere tools! 73
Hans schrieb: > Sorry, ihr seid alle weltfremd! Das mag für Dich so aussehen, weil wir im Gegensatz zu Dir eine Ahnung davon haben, worüber wir reden. > Meine FEM Rechnungen ergeben schon Rohdaten in der Größenordnung, aber > ich plotte doch nicht jeden einzelnen Vector! https://fenicsproject.org/ > Mir ist bewusst, das es für Python sogar Module für algebraisches > Rechnen gibt. Trotzdem nutze ich für diese Dinge Maxima, da das einfach > weniger Einschränkungen hat (und weil ich mich damit auskenne). Genau, weil DU Dich damit auskennst. Für den, der nur einen Hammer hat, sieht jedes Problem wie ein Nagel aus... > Python ist kein Allerheilmittel. Auch hier brauchst du binäre libs im > Hintergrund! fftw, opencv,... das sind alles native-libs mit python > bindings. hast du die nicht auf deinem super cloud-rechner zur > Verfügung, dann hilft dir der Python Interpreter auch nicht! Aber ja doch hilft der mir, dank des mitgelieferten Paketmanagers pip. Da mache ich in meiner Entwicklungsumgebung -- welche gerne auch ein Virtual Environment (virtualenv) sein kann -- ein "pip freeze > requirements.txt" und in meiner Laufzeitumgebung dann ein "pip install -r requirements.txt" und schon sind alle Bibliotheken installiert. Knorke, wa? ;-) Schau, wenn Du irgendwo qualifiziert mitreden treffen willst, solltest Du schon ein bisschen Ahnung von dem haben, worüber geredet wird. Von Python hast Du jedenfalls ganz offensichtlich keine. Bleib' doch einfach bei dem Zoo an unterschiedlichsten Programmen, die Du kennst, aber versuch lieber nicht, Leuten, die Python kennen, etwas darüber zu erzählen. > Es mag sogar sein, dass der Akkuschrauber für manche Personen in manchen > Aufgabenstellungen python heißt. Tja, nur daß Python eben kein einfacher Akkuschrauber ist, sondern eine ganze Werkstatt auf Anabolika und Steroiden! ;-)
Dirk schrieb: > Weiss jemand den Grund für Python für wissenschaftliche Projekte? Ein Mathematiker, Physiker, Chemiker, Etechniker abseits von Embedded (wo C/C++ zum Einmaleins gehört) z.B. Energietechniker, will einen möglichst vollständigen Werkzeugkasten mit dem er möglichst intuitiv und schnell ein Programm basteln kann, in das er oben seine Rohdaten reinkippen kann und unten Ergebnisse rauskriegt, ohne erst Programmieren auf hohem Niveau lernen zu müssen. Performance ist da zweitrangig. Diser Werkzeugkasten kann Pyhton, Matlab, SciLab, R, etc. cc. sein.
Sheeva P. schrieb: > An Ende ist es bei Einzelentwicklungen ja so: bis ich aus den Daten eine > Erkenntnis gewonnen habe, kostet das die Summe aus der Entwicklungs- und > der Laufzeit meines Programms. Ob ich da eine halbe Stunde Entwicklungs- > und zwei Stunden Laufzeit oder zwei Stunden Entwicklungs- und eine halbe > Stunde Laufzeit summiere: das Ergebnis ist am Ende dasselbe. Da > reduziert sich die große Frage nur noch auf auf meine persönliche > Vorliebe, ob ich lieber selbst arbeite, oder ob ich lieber den Rechner > schwitzen lasse und währenddessen mit der netten Kollegin einen Kaffee > trinken gehe. ;-) Das sehe ich doch genau so! Nur sehe ich Python nicht als diese Wunderwaffe. C++ ist auch auch "nur" eine general purpose sprache. Mir ist eben z.B. scilab lieber als Python für numerisches. oder maxima für algebra,... Bin ich jetzt ein schlechterer Mensch??? Sheeva P. schrieb: > Aber hier liegst Du, gemeinsam mit Hans, leider vollkommen daneben. Wenn > Ihr ein bisschen Ahnung nicht nur von C++, sondern eben auch von Python > hättet -- und dadurch also überhaupt erst für den Vergleich zwischen den > beiden, oder auch nur für Aussagen über Python qualifiziert wärt -- dann > wüsstet Ihr, daß es gar nicht um eine Frage des "entweder oder", sondern > stattdessen vielmehr um ein "entweder und" geht. Das stimmt so nicht! Sven B. schrieb: > Im Ernst: wieviele verschiedene Bibliotheken muss ich mir > zusammensammeln, damit ich in C++ zumindest > * Plots > * FFT > * File I/O in sinnvollen Formaten (ok, das kann man notfalls selber > bauen) > * Fit-Routinen (LM, ...) > * Matrixoperationen > habe? Ich denke, mindestens so 4 ... Es ging darum, dass python die eierlegende Wollmilchsau sei! Ich für meinen Teil bin jetzt raus... sollen die Python Jünger bei Python bleiben... ich nutze je nach Problem die Tools die ich für richtig halte. Auch gerne in Kombination! 73
C++Daddy schrieb: > Python und C++ sind so unterschiedlich. Entweder man macht > zeiteffektives Scripting für eine virtuelle Maschine oder man will > hocheffizienten Maschinencode und keine Grenzen und nimmt dafür > vielleicht ein wenig mehr Aufwand in Kauf. Du hast das, was ich oben über Transpiler, Compiler und JIT-Compiler geschrieben hatte, aber gelesen und verstanden?
Hans schrieb: > Wenn ich einen hochqualitativen Plot brauche mache ich sowas z.b. in > gnuplot: > plot [-10:10] sin(x),atan(x),cos(atan(x)) Naja, hochqualitativ sei mal dahingestellt, aber kann man machen, ja. > Implementiere ich einen Algorithmus ist es ziemlich egal in welcher > Sprache ich arbeite! Dem habe ich nie widersprochen! Aber: alle aufgelisteten Algorithmen gibt es in scipy schon, und zwar in guter Qualität (getestet, halbwegs optimiert, und mit Fehlerbehandlung). Wie ich oben kommentiert habe, ist das bei deinen zusammengehackten kurzen C++-Implementierungen eben eher nicht der Fall. Natürlich kann man das in C++ auch ordentlich schreiben, ich glaube dir auch dass du das kannst, aber es ist völlig fraglos dass das vom Aufwand her nicht konkurrenzfähig ist damit die fertige Implementierung aufzurufen. > 4 zu 5 statements... zugegeben, die daten müssen in c noch befüllt und > ausgegeben werden... Das ist halt alles total geschummelt, weil du in Python den kompletten Overhead dazunimmst, und ihn in C weglässt wo er viel größer ist. Der tatsächliche Code ist in Python "fft(x)", fertig. Die restlichen Zeilen sind in deiner C-Variante auch nicht enthalten. Ich glaube nicht dass wir das diskutieren müssen, das weißt du selber. Der faire Vergleich wäre ein vollständiges, kompilierbares C++-Programm, was irgendsowas macht, mit halbwegs realitätsnahem I/O etc. Ich sehe ein, dass du keine Lust hast das hier aufzuschreiben, aber das ist ja genau mein Punkt :D > Schau dir an was zu data-cursors in der doku zu deiner geliebten > matplotlib steht: > https://matplotlib.org/examples/pylab_examples/cursor_demo.html > > Übersetzt: In dem Fall schlägst die Schraube mit dem Hammer ein! Jo, für interaktive Darstellungen ist Matplotlib ungeeignet. Ist so. > Ich gebe gerne zu, dass C++ eine gewaltige Einstiegshürde sein kann weil > es eben eine komplexe Sprache ist. > Python ist einfacher gestrickt (das bitte nicht negativ verstehen!) und > daher einfacher zu erlernen. > Das macht es sicher für viele attraktiv... immerhin willst du an deinem > wissenschaftlichen Problem arbeiten und nicht C++ lernen. Ich kann C++, besser als Python. Ich verwende trotzdem Python für diesen Zweck. > Mir gefällt die python als Sprache schon nicht. warum soll ich mich > damit quälen? Ist ja ok. Ich glaube dir auch, dass deine Entwicklungsumgebung für deinen Anwendungsfall effizient ist. Aber hör auf zu behaupten, dass das nur verwendet wird, "weil es gerade cool ist". > Man kann durchaus in C++ auch sehr langsamen Code produzieren. Siehe oben. scnr > Und nein, um schnell mal Daten durch den Wolf zu jagen nehme ich für > gewöhnlich nicht C/C++ sondern andere tools! Vermutlich irgendwas, was ungefähr die gleiche API implementiert wie Matlab / numpy.
Toni Tester schrieb: > Überraschung (naja, eher nicht - zumindest für jeden, der sich halbwegs > mit "Programmiersprachen" auskennt): Eine interpretierte Skriptsprache > läuft deutlich langsamer als nativ compilierter Maschinencode aus (hier > beispielhaft) C++. Ja, in der Tat überraschend. Der Autor hat nicht verstanden, wozu Python nötig und sinnvoll ist. Nämlich binnen Minuten fertige mathematische Konstrukte zu nutzen, statt sie sich mit C++ binnen Tagen zusammenzustricken.
Hans schrieb: > Mir gefällt die python als Sprache schon nicht. warum soll ich mich > damit quälen? Weder hat jemand verlangt oder auch nur erwartet, daß Dir Python gefällt, noch, daß Du Dich damit "quälst". All das findet nur in Deinem Kopf statt.
Hans schrieb: > Sheeva P. schrieb: >> An Ende ist es bei Einzelentwicklungen ja so: bis ich aus den Daten eine >> Erkenntnis gewonnen habe, kostet das die Summe aus der Entwicklungs- und >> der Laufzeit meines Programms. Ob ich da eine halbe Stunde Entwicklungs- >> und zwei Stunden Laufzeit oder zwei Stunden Entwicklungs- und eine halbe >> Stunde Laufzeit summiere: das Ergebnis ist am Ende dasselbe. Da >> reduziert sich die große Frage nur noch auf auf meine persönliche >> Vorliebe, ob ich lieber selbst arbeite, oder ob ich lieber den Rechner >> schwitzen lasse und währenddessen mit der netten Kollegin einen Kaffee >> trinken gehe. ;-) > > Das sehe ich doch genau so! Davon lese ich in Deinen Ausführungen allerdings nicht viel. > Nur sehe ich Python nicht als diese Wunderwaffe. Aber genau das ist es, und zwar nicht zuletzt auch... > C++ ist auch auch "nur" eine general purpose sprache. ...weil sich Python für performancekritische Stellen ganz einfach um nativen C- und C++-Code erweitern läßt. > Mir ist eben z.B. scilab lieber als Python für numerisches. > oder maxima für algebra,... Ja dann benutz' das doch, hindert Dich ja keiner dran. > Bin ich jetzt ein schlechterer Mensch??? Abgesehen von meinen grundsätzlichen Schwierigkeiten damit, Menschen in Kategorien wie "besser" oder "schlechter" einteilen zu wollen, macht es jedenfalls nicht unbedingt den Eindruck eines besonders klugen Menschen, daß Du immer wieder inkompetenten Unsinn über Python schreibst, ohne es auch nur ansatzweise zu kennen. > Ich für meinen Teil bin jetzt raus... sollen die Python Jünger bei > Python bleiben... ich nutze je nach Problem die Tools die ich für > richtig halte. ...und jetzt stellst Du sogar eine religiöse Konnotation her. Oh Mann.
vn nn schrieb: > Ein Mathematiker, Physiker, Chemiker, Etechniker abseits von Embedded > (wo C/C++ zum Einmaleins gehört) z.B. Energietechniker,... Das bringt es doch prima auf den Punkt, es hängt eben individuell von den Programmierkenntnissen ab. Das ein Chemiker mit Python schneller am Ziel ist als mit C,C++,Fortran oder Brainfuck sollte klar sein. Wenn aber jemand sowieso hauptsächlich in C++ unterwegs ist und dort längst ein fertiger Workflow mit allen Wünschen existiert, wieso sollte man auf eine Skriptsprache wechseln oder gar Sprachen anfangen zu vermischen, aus dieser Sicht ist es ein Umweg, für mich wäre es ganz simpel unnötiger Aufwand. Gehört der Threadersteller zu zB der Gruppe Chemiker usw ist natürlich klar das dann wiederum aus dieser Sicht Python besser passt. Beide Sprachen sind in ihrem Bereich sehr gute Sprachen mit jeweiligen Stärken. Und um ein paar CSV-Spalten darzustellen oder für simple Berechnungen reicht auch Excel. Solang man nichts über den Hintergrund und die Absichten des Threaderstellers kennt, lässt sich sowieso nichts sagen. Da im ersten Beitrag "Machine Learning" genannt wurde, wäre erstmal zu klären ob es um bildverarbeitende Dinge geht oder nicht. Dann könnte man sehen ob es in Richtung GPU geht oder in Richtung CPU. Und dann erst kann man sich unterhalten welche Sprache, Frameworks, Libs usw für die gewollten Dinge Sinn machen.
C++Daddy schrieb: > Wenn aber jemand sowieso hauptsächlich in C++ unterwegs ist und dort > längst ein fertiger Workflow mit allen Wünschen existiert, ...ist ein seriöser Vergleich mit einer Umgebung, in der all dieses noch nicht vorhanden ist, nicht möglich. > wieso sollte > man auf eine Skriptsprache wechseln oder gar Sprachen anfangen zu > vermischen, aus dieser Sicht ist es ein Umweg, für mich wäre es ganz > simpel unnötiger Aufwand. Just das ist eine äußerst spannende Frage. Wenn Du durch den Erwerb und die Nutzung der Skriptsprache deutlich an Entwicklungszeit sparen könntest oder wenn Deine Kollegen alle mit Python arbeiten und kein C++ beherrschen, dann wäre dieser Umweg trotzdem zumindest langfristig ein lohnender Aufwand.
C++Daddy schrieb: > Wenn aber jemand sowieso hauptsächlich in C++ unterwegs ist und dort > längst ein fertiger Workflow mit allen Wünschen existiert, wieso sollte > man auf eine Skriptsprache wechseln oder gar Sprachen anfangen zu > vermischen, aus dieser Sicht ist es ein Umweg, für mich wäre es ganz > simpel unnötiger Aufwand. Ich bin auch in C unterwegs, trotzdem ist Python oder eine andere Scriptsprache super, um mal schnell was zum probieren zusammenzuhacken (neudeutsch rapid prototyping). Wenn ich nur mal sehen will, ob eine Idee wirklich funktioniert, ein Algorithmus wirklich das macht, was ich will, ist das einfachste, ein paar Werkzeuge aus dem riesigen Pyhton-Werkzeugkasten zusammenzustöpseln, anstatt alles aufwenig in C zu implementieren und dann draufzukommen, dass irgendeine Grundannahme falsch war. C++Daddy schrieb: > Und um ein paar CSV-Spalten darzustellen oder für simple Berechnungen > reicht auch Excel. Warum sollte ich mir Excel antun, wenn ich Python hab?
Hans schrieb: > Ich kann C++ ausreichend gut (ich werde seit 17 Jahren dafür bezahlt!). > Ich habe eine für mich effiziente Entwicklungsumgebung gefunden > (Slackware, Qt5, Impulse, LaTex, gnuplot, Maxima,...). > Ich beschäftige mich mit Algorithmen und nicht mit plotten. > Daher habe ich postuliert, dass ich in C++ nicht langsamer bin als > jemand anderes in Python. Oder anders gesagt: Jemand mit viel weniger Erfahrung kann in der gleichen Zeit dasselbe erreichen, nur durch Verwendung eines anderen Tools. Und von jemand anders ist deine Lösung dann auch nicht wartbar, weil nur du die Tools beherrscht. Als Bastelei für Privatzwecke okay, als professionelle Lösung eigentlich unbrauchbar (auch wenn mir klar ist dass viele Buden unprofessionelles Vorgehen dulden).
Claidhem schrieb: > Oder anders gesagt: Jemand mit viel weniger Erfahrung kann in der > gleichen Zeit dasselbe erreichen, nur durch Verwendung eines anderen > Tools. > > Und von jemand anders ist deine Lösung dann auch nicht wartbar, weil nur > du die Tools beherrscht. Als Bastelei für Privatzwecke okay, als > professionelle Lösung eigentlich unbrauchbar (auch wenn mir klar ist > dass viele Buden unprofessionelles Vorgehen dulden). Behauptest du jetzt allen ernstes, ich würde absichtlich möglichst aufwendige und unprofessionelle Problemlösungen entwickeln die nicht wartbar sind und die von einem dressiertem Affen in der halben Zeit machbar gewesen wären ??? Und/oder, dass ich Leute von python abhalten will um meine Inkompetenz zu verschleiern??? Sheeva P. schrieb: > Davon lese ich in Deinen Ausführungen allerdings nicht viel. Dann lies genauer! Als Beispiel: Hans schrieb: > Dann wäre da noch http://toem.de/index.php/projects/impulse für VCD > daten und https://labplot.kde.org/ für's "schnelle analysieren" von > anderem zeugs Und das wurde auch bestätigt... Sven B. schrieb: > Jo, für interaktive Darstellungen ist Matplotlib ungeeignet. Ist so. Und? Ist das schlecht??? Nein. Ich bin mir sicher, für interaktive Dinge gibt's auch unter python was geeigneteres... und wenn es nur die Qt über die python bindings ist. Aber wenn ich diese Funktionalität brauche, dann bin ich schneller beim Kaffee! Oder auch hier: Hans schrieb: > Es mag sogar sein, dass der Akkuschrauber für manche Personen in manchen > Aufgabenstellungen python heißt. > > Ich für meinen Teil finde jedenfalls die Sprache nicht "schön" und auch > nicht gut lesbar. > > Aber für gewöhnlich gibt's im Baumarkt mehrere Typen Akkuschrauber.. man > muss einfach nur einen in der Werkzeugkiste haben! Brauch ich schnell einen plot einer FFT, dann mach ich das mit scilab. Du in python. unterschied? .... 0! sogar das scaling der fft ist ident... ich nehme an, da in beiden Fällen im Hintergrund die fftw verwendet wird. => gleichzeitig beim Kaffee! Ich hoffe wir sind uns einig, dass man die Wurzel aus zwölfzig auch nicht in der python shell rechnet, sonder mit dem TI30 neben der Tastatur. (Ausnahme wäre, die shell ist gerade offen... dann wär mir aber auch ein Klick aus einem offenen Excel Fenster raus zu blöd...) > >> Nur sehe ich Python nicht als diese Wunderwaffe. > > Aber genau das ist es, und zwar nicht zuletzt auch... > >> C++ ist auch auch "nur" eine general purpose sprache. > > ...weil sich Python für performancekritische Stellen ganz einfach um > nativen C- und C++-Code erweitern läßt. kann ich mit einem mex-file unter matlab/octave auch. Hat aber auch seine Probleme... Wird zumindest in Sonderfällen in python nicht anders sein. > >> Mir ist eben z.B. scilab lieber als Python für numerisches. >> oder maxima für algebra,... > > Ja dann benutz' das doch, hindert Dich ja keiner dran. > >> Bin ich jetzt ein schlechterer Mensch??? > > Abgesehen von meinen grundsätzlichen Schwierigkeiten damit, Menschen in > Kategorien wie "besser" oder "schlechter" einteilen zu wollen, macht es > jedenfalls nicht unbedingt den Eindruck eines besonders klugen Menschen, > daß Du immer wieder inkompetenten Unsinn über Python schreibst, ohne es > auch nur ansatzweise zu kennen. Wo habe ich mich bitte inkompetent über Python ausgelassen??? Inkompetent ist zu sagen Python kann alles und das out of the box. Möglicherweise ist es als Distribution für dich Mittel der Wahl. Möglicherweise kannst du mit pip "schnell mal" module nachladen. Aber wenn's das gesuchte nicht gibt??? Genau, dann musst du das selbst implementieren! Und wie viel schneller bist du mit Algorithmus nachschlagen, eintippen und debuggen???? Wieder richtig, gleich schnell! Aus meiner Erfahrung dauert der 1. und letzte Schritt am längsten.... Also Paper rauskramen, verstehen, und mit Test-Daten verifizieren. Auf genau diesen Fall bezog sich mein "gleich schnell in C++" Tut mir leid das in meinem 1. Post nicht so deutlich geschrieben zu haben! Als kleines Beispiel zu einem Algorithmus, den es mit an Sicherheit grenzender Wahrscheinlichkeit als Python-Code nicht geben wird: Ich schreibe gerade an einem Hysterese Modell das mit der T(x) Funktion arbeitet und in einem transienten Netzwerksolver läuft. Der Netzwerksolver war ursprünglich SPICE... nach und nach habe ich das in modernem C++ nachimplementiert. Das eigentlich nur um allerhand Details zu verstehen... also Schritt für Schritt zum Thema passende Literatur gewälzt, Teile ausgetauscht und Ergebnisse nachvollzogen. Am Schluss war nicht mehr viel übrig vom solver. Ja, um zu zeigen, dass Modelle mit Hilfe der T-funktion sehr genau sein können, das könnte man mit Python sicher gut machen. Aber dazu kann ich dir auch ISBNs liefern... Btw.: Wie oben auch oft angedeutet mache ich mein rapid prototyping zu 90% nicht in C/C++! Mein Statement, Python wäre gerade Hip und "cool" war doch auch nicht rein negativ oder abwertend! Solltest du das so sehen, dann tut mir das Leid! Tatsache! Fakt ist nunmal, dass es je nach Forschungsfeld/Anwendungsfall unterschiedliche "Lieblingsframeworks" gibt. Statistiker mögen gerne R, andere Maple oder Mathematica und dann gibt's eben noch Python. Ich war auch nie beleidigend wie im Posting das ich hier am Anfang zitiert habe... oder dieses: Sven B. schrieb: >> Plots, File-IO usw würde ich sagen Qt... die bringt auch gleich eine >> nette IDE + compiler mit... seit einiger Zeit gibts QtCharts gratis... >> auch sehr brauchbar. > Sorry, ne, ist es nicht. QtCharts ist nett, wenn du irgendwie eine bunte > Linie flackern lassen willst in deiner Hipster-App, Irgend etwas passt einfach nicht... Arduino und Python Nutzer tendieren sofort auf die Barrikaden zu gehen wenn man nicht sofort ein Loblied anstimmt. Aber wer weiß, Julia wird eine sehr große Zukunft vorhergesagt... dann könnte ich sagen "nach Matlab kam Python und jetzt Julia" Hoffentlich ist dann die "neue große Community" dann weniger verbohrt. 73
> Mein Statement, Python wäre gerade Hip und "cool" war doch > auch nicht negativ oder abwertend! Dann solltest du an der Ausdruckskraft deiner Formulierungen arbeiten, weil so kam es m.E. nämlich rüber, und das hat die ganze Diskussion gestartet. Die Frage war "warum Python" und deine Antwort war "weil es gerade hip ist". Natürlich klingt das abwertend. Hättest du sowas gesagt wie "es ist nützlich, ein Prototyping-Tool dieser Art zu haben, es gibt allerdings auch einen Haufen andere als Python die ähnlich funktionieren, aber Python ist wohl das hipste am Markt" (was ja, wenn ich jetzt deine neueren Posts lese, eher deiner Auffassung entspricht) hätte ich dir direkt zugestimmt. Den Satz mit dem Loblied kapiere ich nicht. Wunderst du dich darüber, dass Menschen die gern Python benutzen sich kritisch über die Nützlichkeit von Frameworks äußern können, oder was? Ich bleibe übrigens dabei, an Qualität des Ergebnisses, welches sich mit tragbarem Aufwand erzielen lässt, hinkt gnuplot der matplotlib um einen Faktor hinterher, und QtCharts gnuplot nochmal um denselben Faktor.
:
Bearbeitet durch User
Hans schrieb: > Behauptest du jetzt allen ernstes, ich würde absichtlich möglichst > aufwendige und unprofessionelle Problemlösungen entwickeln die nicht > wartbar sind und die von einem dressiertem Affen in der halben Zeit > machbar gewesen wären ??? > Und/oder, dass ich Leute von python abhalten will um meine Inkompetenz > zu verschleiern??? Ständig liest Du Dinge, die niemand gesagt oder auch nur angedeutet hat. Bitte tu' Dir dringend den Gefallen und arbeite daran, diese merkwürdigen Einbildungen in Deinem Kopf wieder ins Lot zu bringen. > Sheeva P. schrieb: > Ich hoffe wir sind uns einig, dass man die Wurzel aus zwölfzig auch > nicht in der python shell rechnet, sonder mit dem TI30 neben der > Tastatur. Ich habe keinen TI-30 und auch nie einen gehabt. Und warum ich mir einen Taschenrechner auf den Schreibtisch legen soll, obwohl ich eine geradezu gigantische Rechenleistung darunter stehen hab, erschließt sich mir auch nicht wirklich. Ich nehme die Hand schon ungern von der Tastatur weg, um zur Maus zu greifen, und habe auf der fetten Rechenmaschine Kcalc, bc(1), sowie natürlich Python zur Verfügung... >> ...weil sich Python für performancekritische Stellen ganz einfach um >> nativen C- und C++-Code erweitern läßt. > > kann ich mit einem mex-file unter matlab/octave auch. Du verstehst aber schon, daß es darum gar nicht geht, oder? Und wenn ich mir Deinen Zoo an Programmen und Bibliotheken anschaue, die Du angeblich beherrschst: Python hättest Du in einem Bruchteil der Zeit gelernt und könntest Deine Probleme mindestens ebenso gut, vermutlich sogar deutlich flexibler und wiederverwendbarer lösen. > Hat aber auch seine Probleme... Wird zumindest in Sonderfällen in python > nicht anders sein. Schon wieder hast Du kein Wissen, ja sogar noch nicht einmal eine Ahnung, sondern nur Deine Vermutungen. > Wo habe ich mich bitte inkompetent über Python ausgelassen??? Vielleicht magst Du Deine "Beiträge" noch einmal lesen und Dir ernsthaft die Frage stellen, welche Deiner Äußerungen über Python tatsächlich auf Kenntnissen basieren -- siehe mein vorheriger Absatz. > Inkompetent ist zu sagen Python kann alles und das out of the box. Das wäre tatsächlich inkompetent, hat aber außer Dir gerade niemand hier auch nur angedeutet -- geschweige denn, behauptet. Obwohl, auch das ist ja nicht ganz richtig: die hier erwähnten Bibliotheken und Werkzeuge hat die Anaconda-Distribution bereits alle dabei, "out of the box". > Möglicherweise ist es als Distribution für dich Mittel der Wahl. ...was Dich so sehr zu stören scheint, daß Du unfaßbar viel Energie darauf aufwendest, um mir und anderen erklären zu wollen, - wie falsch das alles sei, - wie imperformant das alles sei, - daß Du in einer kompilierten, typsicheren Sprache ohne automatisches Speichermanagement und mit einem riesigen Zoo an Drittwerkzeugen und -Bibliotheken mindestens genau so schnell seist. > Möglicherweise kannst du mit pip "schnell mal" module nachladen. Nix "möglicherweise". Ganz sicher kann ich das. > Aber wenn's das gesuchte nicht gibt??? > > Genau, dann musst du das selbst implementieren! Ja, das ist das Schicksal des Entwicklers: Funktionen, die es noch nicht gibt, muß der Ärmste selbst entwickeln. > Und wie viel schneller bist du mit Algorithmus nachschlagen, eintippen > und debuggen???? Wieder richtig, gleich schnell! Ach, die meisten üblichen Algorithmen bringen die Python-Libraries schon fertig debuggt und getestet mit. > Aus meiner Erfahrung dauert der 1. und letzte Schritt am längsten.... > Also Paper rauskramen, verstehen, und mit Test-Daten verifizieren. > Auf genau diesen Fall bezog sich mein "gleich schnell in C++" Und dann schreibst Du Dir noch ein weiteres C++-Programm, um die Ist- gegen die Soll-Ergebnisse zu verifizieren? Wow... Da bin ich mit meiner netten Kollegin schon beim dritten Kaffee und beim Du. > Als kleines Beispiel zu einem Algorithmus, den es mit an Sicherheit > grenzender Wahrscheinlichkeit als Python-Code nicht geben wird: > [...] > Ja, um zu zeigen, dass Modelle mit Hilfe der T-funktion sehr genau sein > können, das könnte man mit Python sicher gut machen. Aber dazu kann ich > dir auch ISBNs liefern... Danke, ich hab' selbst genug ISBNs... Du scheinst da einem fundamentalen Irrtum aufzusitzen: ursprünglich wollte ich hier nur die Frage des TO beantworten, warum Python oft und gerne für wissenschaftliche Projekte eingesetzt wird. Plötzlich sind dann ein Haufen C++-Missionare wie Du aufgetreten, um zu erklären, daß Python eh nur benutzt würde, weil es so "hip und cool" sei, sie selbst hingegen als Superelite der wissenschaftlichen Datenanalyse natürlich nur C++ nutzen würden, was sie, ganz Superelite, natürlich so übernatürlich gut können, daß sie damit genauso schnell seien wie mit Python seien. Nee, ist klar. Diesen Quatsch wollte ich jedenfalls nicht unwidersprochen stehen lassen, immerhin lesen hier auch Kinder mit und könnten versucht sein, den Quatsch zu glauben. > Mein Statement, Python wäre gerade Hip und "cool" war doch auch nicht > rein negativ oder abwertend! Ach hör' doch auf, natürlich war es das, und es war auch ganz genau so gemeint, gedacht, und formuliert. > Fakt ist nunmal, dass es je nach Forschungsfeld/Anwendungsfall > unterschiedliche "Lieblingsframeworks" gibt. Ein "Lieblingsframework" ist schon vom Wortsinn her keines, das sich an einem Forschungsfeld oder Anwendungsfall orientiert, sondern stattdessen eines, das sich nach den Vorlieben des Nutzers richtet. > Ich war auch nie beleidigend wie im Posting das ich hier am Anfang > zitiert habe... oder dieses: Deine Einlassung, der zufolge Python nur benutzt werde, weil es "hip und cool" sei, war allerdings durchaus herabwürdigend. Und bitte erzähl mir jetzt nicht, daß das nicht auch genau so gemeint gewesen sei. > Irgend etwas passt einfach nicht... Arduino und Python Nutzer tendieren > sofort auf die Barrikaden zu gehen wenn man nicht sofort ein Loblied > anstimmt. Da kann ich nur für mich sprechen, aber ich widerspreche eben, wenn jemand gequirlten Unsinn erzählt. Wenn Du das vermeiden möchtest, dann red' halt keinen Unsinn über Dinge, von denen Du nichts verstehst. Eigentlich ganz einfach, findest Du nicht? > Aber wer weiß, Julia wird eine sehr große Zukunft vorhergesagt... dann > könnte ich sagen "nach Matlab kam Python und jetzt Julia" > > Hoffentlich ist dann die "neue große Community" dann weniger verbohrt. Diese Community wird Dir sicherlich genauso widersprechen wie wir, wenn Du über Julia ähnlichen Unfug erzählst wie über Python. Aber schön, daß gerad Du Dich schon wieder so herablassend äußerst wie in Deinem Eingangspost -- und bezüglich "verbohrt": wer im Glashaus sitzt, sollte im Keller schmusen.
Sven B. schrieb: > Ich bleibe übrigens > dabei, an Qualität des Ergebnisses, welches sich mit tragbarem Aufwand > erzielen lässt, hinkt gnuplot der matplotlib um einen Faktor hinterher, > und QtCharts gnuplot nochmal um denselben Faktor. Damit es hier auch noch was Konstruktives zu Lesen gibt: wenn Du gerne interaktive und gut aussehende Plots haben willst, lohnt sich häufig ein kleiner Webservice zum Beispiel mit Flask, bei dem das Plotten mit einem JavaScript-Plotter wie flot [1] oder jqPlot [2] gemacht wird, und für noch weitergehende Anforderungen sind D3 [3] und Plot.ly [4] schick. [1] https://www.flotcharts.org/ [2] http://www.jqplot.com/ [3] https://d3js.org/ [4] https://plot.ly/
Hans schrieb: > Ich hoffe wir sind uns einig, dass man die Wurzel aus zwölfzig auch > nicht in der python shell rechnet, sonder mit dem TI30 neben der > Tastatur. Ich hasse zwar Uneinigkeit, aber wenn bei mir der PC an ist, ist der Taschenrechner aus. Beides zusammen braucht mir zuviel Strom und Schreibtischfläche. > (Ausnahme wäre, die shell ist gerade offen... Bei mir ist praktisch immer ein Python-Fenster offen. Wenn nicht, öffne ich eines – so schnell kannst du gar nicht die Augen zu deinem TI-30 hinüberdrehen – mit einem extra dafür eingerichteten Hotkey :)
Sheeva P. schrieb: >> Hat aber auch seine Probleme... Wird zumindest in Sonderfällen in python >> nicht anders sein. > > Schon wieder hast Du kein Wissen, ja sogar noch nicht einmal eine > Ahnung, sondern nur Deine Vermutungen. Nein, habe ich in der Boost.python Doku nachgelesen! Function Pointer zurück in den Python Interpreter geht nicht. Die einleuchtende Begründung ließ bitte selber nach. Sheeva P. schrieb: >> Inkompetent ist zu sagen Python kann alles und das out of the box. > > Das wäre tatsächlich inkompetent, hat aber außer Dir gerade niemand hier > auch nur angedeutet -- geschweige denn, behauptet. Obwohl, auch das ist > ja nicht ganz richtig: die hier erwähnten Bibliotheken und Werkzeuge hat > die Anaconda-Distribution bereits alle dabei, "out of the box". Aha und was war das??? Hans schrieb: >> Nur sehe ich Python nicht als diese Wunderwaffe. > Aber genau das ist es, und zwar nicht zuletzt auch... Sheeva P. schrieb: > lohnt sich häufig ein kleiner Webservice zum Beispiel mit Flask Standalone reicht oft schon ... Die D3 ist wirklich nett... Btw, couchdb schonmal verwendet? Das kann die Daten verwalten und wenn's sein muss die Website hosten! 73
Hans schrieb: > Sheeva P. schrieb: > Nein, habe ich in der Boost.python Doku nachgelesen! Function Pointer > zurück in den Python Interpreter geht nicht. Die einleuchtende > Begründung ließ bitte selber nach. Meine Güte, jetzt hast Du Dir aber ein Szenario ausgedacht... Langsam werden Deine "Argumente" wirklich mehr als haarsträubend. Andererseits lassen sich alle Anwendungsfälle, in denen man so etwas brauchen könnte, vermutlich dadurch abfackeln, indem man wiederum einen Python-Interpreter in das von Boost.Python erzeugte Shared Object einbaut. > Sheeva P. schrieb: >>> Inkompetent ist zu sagen Python kann alles und das out of the box. >> >> Das wäre tatsächlich inkompetent, hat aber außer Dir gerade niemand hier >> auch nur angedeutet -- geschweige denn, behauptet. Obwohl, auch das ist >> ja nicht ganz richtig: die hier erwähnten Bibliotheken und Werkzeuge hat >> die Anaconda-Distribution bereits alle dabei, "out of the box". > > Aha und was war das??? Das ist die Feststellung, daß die Python-Distribution Anaconda alle hier angesprochenen Module bereits fertig und out-of-the-box mitbringt. Diese Feststellung paßt hier sogar ganz besonders gut in den Thread, weil diese Distribution sich insbesondere an Datenwissenschaftler richtet... > Hans schrieb: >>> Nur sehe ich Python nicht als diese Wunderwaffe. >> Aber genau das ist es, und zwar nicht zuletzt auch... Daß eine Standard-Distribution von Python nicht alles sofort out-of-the-box kann, ändert nichts daran, daß Python eine Wunderwaffe ist und ganz alleine vermutlich Deinen ganzen Zoo ersetzen könnte. Daß man dafür eine erweiterte Python-Distribution wie Anaconda benutzen, oder mithilfe des mitgelieferten Werkzeugs pip einige Bibliotheken aus dem zentralen Bibliotheksverzeichnis installieren müßte, ändert daran ebensowenig. Vor allem im Vergleich mit C++ kann ich mir aber jetzt mein fieses Grinsen nicht verkneifen -- das kann out of the box ja nichtmal handelsübliche und weit verbreitete Formate wie CSV, XML, YAML oder JSON lesen, mit Datum und Zeit rechnen oder ähnliche Basics. > Sheeva P. schrieb: >> lohnt sich häufig ein kleiner Webservice zum Beispiel mit Flask > > Standalone reicht oft schon ... Die D3 ist wirklich nett... Erfreulicherweise bringt Flask bereits einen eigenen Entwicklungsserver mit und ist daher für soetwas genau das: standalone. Kurz gesagt, sieht eine minimale Flask-Applikation etwa so aus:
1 | #!/usr/bin/env python
|
2 | from flask import Flask |
3 | |
4 | app = Flask(__name__) |
5 | |
6 | @app.route('/') |
7 | def index(): |
8 | return '<h1>Tja</h1>Da kiekste, wa?' |
9 | |
10 | if __name__ == '__main__': |
11 | app.run() |
Zeig' das doch bitte mal in C++. > Btw, couchdb schonmal verwendet? Natürlich, aber hier geht es meist entweder um schnelle Key-Value-Stores, dann paßt Redis in der Regel besser, oder um starke Suchmöglichkeiten und Datenanalysefähigkeiten, dann passen eher Elasticsearch und Kibana. Bisher hab ich noch keine praktischen Anwendungsfälle gehabt, bei denen Couchdb oder Mongodb besser gepaßt hätten. > Das kann die Daten verwalten und wenn's sein muss die Website hosten! Ach Gottchen, ja, Futon... aber das ist wohl eher ein Admin-Interface als eine brauchbare Datenvisualisierung, da bleib' ich dann doch lieber bei Elasticsearch und Kibana. Kann Futon denn mitterweile plotten?
Sheeva P. schrieb: > Meine Güte, jetzt hast Du Dir aber ein Szenario ausgedacht... Nein, du hast vermutet ich würde ahnungslos daherplappern. Ich habe so ziemlich jeden vermeintlichen Tipp mir rausgesucht und werde ihn im Fall des Falles auch beherzigen! Sheeva P. schrieb: > Daß eine Standard-Distribution von Python nicht alles sofort > out-of-the-box kann, ändert nichts daran, daß Python eine Wunderwaffe > ist und ganz alleine vermutlich Deinen ganzen Zoo ersetzen könnte. Ersetzen, mag sein. Aber ist es in jedem Fall besser??? Bezweifle ich! Sheeva P. schrieb: > Erfreulicherweise bringt Flask bereits einen eigenen Entwicklungsserver > mit und ist daher für soetwas genau das: standalone. Kurz gesagt, sieht > eine minimale Flask-Applikation etwa so aus: Ich meinte pures html5... Kann erstaunliches... Dein flask Beispiel wäre mit HTML,head und Body tags dann ein 7 Zeiler bei minimalem Aufwand. Sheeva P. schrieb: > Bisher hab ich noch keine praktischen Anwendungsfälle gehabt, bei denen > Couchdb oder Mongodb besser gepaßt hätten. Json rein -> map-reduce -> json raus und in d3 angezeigt.. Anwendung nicht ausgedacht, läuft als eine Art datalogger... Couchdb lief schon, also mittel der Wahl. Um auf das ursprüngliche Thema zurückzukommen. Wenn du mir vohältst, ich hätte eine verschrobene Auffassung, dann lass dir sagen, dass du auch nicht besser bist. Ich habe geschrieben, dass in meinem Anwendungsfall c++ aus mehreren Gründen nicht wesentlich aufwendiger ist. Ich habe geschrieben, dass ich für viele Dinge (für mich) sehr effiziente Tools gefunden habe. Ich habe nie behauptet, ich würde alles nur in c++ machen! Ich habe nur festgestellt, dass es mehr als nur ein einziges "richtiges" Werkzeug gibt! Alles andere entspringt deiner Fantasie! Sheeva P. schrieb: > Anwendungsfälle, in denen man so etwas brauchen könnte, vermutlich > dadurch abfackeln, indem man wiederum einen Python-Interpreter in das > von Boost.Python erzeugte Shared Object einbaut Sorry, aber genau um das geht's. Viele Wege führen nach Rom! Und Python löst nicht alle Problem. Möglicherweise aber für dich... 73
Und nun liebe Kinder hört ihr wieder eine Folge aus der Serie "Meine Lieblingssprache ist viel besser als Deine Lieblingssprache. " Eigentlich wollte de TO nur wissen, welche Vorteile Python gegenüber C++ hat und warum die Leute es benutzen. Eine legitime Frage. Jetzt sind wir bei HTML5 und Javascript im Browser. Jetzt muss noch jemand Perl ins Spiel bringen, damit ein abgerundeter Eindruck entsteht. Mal ehrlich: manche Dinge gehen besser in Python, andere in C++. Das hängt alles von den Requirements ab. Sogar Brainfuck ist angeblich für bestimmte Probleme besser geeignet als jede andere Sprache. "Ich mache alles in X, weil ich das so gut kann, dass ich damit schneller bin als ihr in Y" ist mit Abstand die dämlichste Begründung, die man sich ausdenken kann. Ich schneide mein Rumpsteak mit der Kettensäge, weil ich damit viel schneller bin als Du mit Deinem Messer. Wer ein gewisses Spektrum von Sprachen beherrscht (oder willens ist, sie zu lernen) und in der Lage ist, für ein gegebenes Problem die geeignete auszuwählen, findet bessere Lösungen als ein inselbegabter C++-Guru mit einem Compiler im Kopf (ersetze C++ durch was immer Du willst). The right tool at the right time.
Vancouver schrieb: > Und nun liebe Kinder hört ihr wieder eine Folge aus der Serie "Meine > Lieblingssprache ist viel besser als Deine Lieblingssprache. " Dazu macht es Sheeva Plug es gerade! Vancouver schrieb: > Mal ehrlich: manche Dinge gehen besser in Python, andere in C++. Das > hängt alles von den Requirements ab. Nichts, aber auch gar nichts anderes habe ich behauptet! Mein 2. Post: Hans schrieb: > Grafiken für wissenschaftliche Publikationen lässt man IMHO am besten > latex zeichnen...pgfplots sei dank :) > > C++Daddy schrieb: >> Natürlich ist Python bei einfacheren Dingen der Weg des geringeren >> Widerstandes, kann aber je nach Anwendungsfall viel zu langsam sein. >> Für meine Diss. nutze ich C++ mit QT, alles andere wäre für meine >> Anwendung viel zu langsam. > > full ACK! > > Schreiber schrieb: >> Es geht erstmal darum die Funktionsfähigkeit zu demonstrieren und >> den Algoritmus praktisch einsetzbar zu machen. Ob man jetzt 100€ mehr >> oder weniger für Rechenzeit ausgeben muss, ist erstmal egal. > > Naja, wenn du benchmarken willst, dann musst du im normalfall gegen eine > optimierte Referenz bestehen... und die ist entweder Fortran oder C(++). Oder auch später: Hans schrieb: > IMHO habe nicht ich die Scheuklappen auf, sondern 90% der > mitkommentierenden. Wie oben beschrieben nutze ich viele > unterschiedliche Tools. > > Außerdem gibt's neben Python noch ganz andere Frameworks. wie z.B. R... > > Mir ist bewusst, das es für Python sogar Module für algebraisches > Rechnen gibt. Trotzdem nutze ich für diese Dinge Maxima, da das einfach > weniger Einschränkungen hat (und weil ich mich damit auskenne). Ich habe nie gesagt meiner ist Größer, sondern ich nutze in definierten Fällen was anderes weil es mich_ bei _meinen Aufgabenstellungen schnell(er) ans Ziel bring. Jede Library, jede Sprache und eigentlich sogar jedes Ding auf diesem Planeten ist für manche Aufgaben geeigneter als für andere. Oben habe ich gezeigt, dass eine cholesky zerlegung, eine fft oder auch ein simpler plot z.B. in scilab ähnlich wenig aufwand bedeuten. Und wenn ich diese Algorithmen in C++ oder python implementieren müsste, dann wäre der Aufwand ähnlich. Einen Parser schreibe ich auch nicht in C++... auch wenn es Bison,Flex&Co gibt. Für meine Anwendung (Problembeschreibung) ist die V8 für mich das Mittel der Wahl gewesen. Python war da im Rennen, genau so wie Lua. C++ ist es geworden weil ich eben vom SPICE Quellcode gestartet bin. Die Qt ist es geworden weil viele dumme Tasks sich damit ausreichend einfach umsetzen lassen. Die V8 hat sich am schönsten ins Meta-Objekt-System eingefügt (also eigentlich die QJSEngine). Sicher, alles in python wäre auch gegangen... aber genau so in brainfuck oder Ook! Vancouver schrieb: > Wer ein gewisses Spektrum von Sprachen beherrscht (oder willens ist, sie > zu lernen) und in der Lage ist, für ein gegebenes Problem die geeignete > auszuwählen, findet bessere Lösungen als ein inselbegabter C++-Guru mit > einem Compiler im Kopf (ersetze C++ durch was immer Du willst). The > right tool at the right time. Dem kann ich nur beipflichten. Manchmal ist es mein TI30-XA Solar, manchmal lokales HTML5 mit JS, dann C++ und wenn's sein muss kämpfe ich mich auch wieder in eine Matlab-Toolbox rein damit später jemand anders damit weiterarbeiten kann. Das habe ich sogar im 1. Post schon angedeutet! Nur noch mal der Vollständigkeit halber:
1 | „Hip“ wird heute überwiegend in Bedeutungen etwa von „angesagt“[3], „schick“, zeitgenössisch, „trendy“[4] genutzt. |
1 | cool |
2 | ... |
3 | BEDEUTUNGEN, BEISPIELE UND WENDUNGEN |
4 | ... |
5 | 3. keinen, kaum Anlass zur Klage gebend, durchaus annehmbar, in Ordnung |
6 | 4. in hohem Maße gefallend, der Idealvorstellung entsprechend |
Sven B. schrieb: >> Mein Statement, Python wäre gerade Hip und "cool" war doch >> auch nicht negativ oder abwertend! > > Dann solltest du an der Ausdruckskraft deiner Formulierungen arbeiten, > weil so kam es m.E. nämlich rüber, und das hat die ganze Diskussion > gestartet. Die Frage war "warum Python" und deine Antwort war "weil es > gerade hip ist". Natürlich klingt das abwertend. Also wenn ich sage, dass etwas angesagt ist und jetzt gerade den Idealvorstellungen entspricht, dann tut es mir wirklich sehr leid wenn das jemand als zu tiefst negativ auffasst! Vancouver schrieb: > "Ich mache > alles in X, weil ich das so gut kann, dass ich damit schneller bin als > ihr in Y" ist mit Abstand die dämlichste Begründung, die man sich > ausdenken kann. Ich schneide mein Rumpsteak mit der Kettensäge, weil ich > damit viel schneller bin als Du mit Deinem Messer. Und das ist jetzt anders als mit aussagen wie "mit matplotlib kommt man aber immer schneller zu einem fancy bildchen"??? Für meine (anscheinend zu trivialen, gut, lass' ich mir einreden) Probleme war bisher gnuplot oder pgfplots genau das richtige. Falls jemand lieber zuerst python anwirft, eine csv-file läd und dann mit matplotlib sich den pgfplots code erzeugt, der dann von Latex in ein schönes pdf verwandeld wird - bitte, tut es! z.B. hier https://www.latex-tutorial.com/tutorials/pgfplots/ sieht man den aufwand der nötig ist falls in einem csv schon die daten in passender Form liegen... das kommt vor! ICH habe keine 10Gig Rohdaten auf Landkarten abzubilden! Das habe ich auch nicht behauptet! Ich habe wenn dann einige GB Rohdaten von irgendwelchen Vektorfeldern. Das muss ich postprocessen... teilweise reicht dazu aber schon das aus, was das Simulationspackage hergibt. (CST habe ich angesprochen, Onelab verwende ich in manchen Situationen auch). Übrigens danke für den Tipp mit FEniCS Project.... Dennoch lese ich lieber zuerst nach ob/mit welchem Aufwand ich z.B. entlang eines Pfades integrieren kann, oder ob ich über externe Tools einfacher mein Ergebnis erhalte. 73
@Hans "Ich habe nie gesagt meiner ist Größer, sondern ich nutze in definierten Fällen was anderes weil es mich_ bei _meinen Aufgabenstellungen schnell(er) ans Ziel bring." "Ich mache für meine Diss alles in C++. Ich kann so gut C++, dass ich damit gleich schnell bin wie jemand anderes in Python." Sehe nur ich da einen Widerspruch?
Hans schrieb: > Behauptest du jetzt allen ernstes, ich würde absichtlich möglichst > aufwendige und unprofessionelle Problemlösungen entwickeln die nicht > wartbar sind und die von einem dressiertem Affen in der halben Zeit > machbar gewesen wären ??? Nein. Ich sage nur, dass es unprofessionell ist, ein Werkzeug aufgrund der persönlichen Vorlieben zu wählen, wenn das Arbeitsergebnis für andere deutlich schwerer zu warten ist. Ob das in deinem Fall zutrifft und ob du das absichtlich oder unwissentlich machst musst du schon selbst bewerten. Nur die Aussage in die Richtung "ich mit meinen 17 Jahren Erfahrung mit C++ schaffe es gerade so, eine Aufgabe genauso schnell zu lösen wie jemand anders mit Python" deutet schon sehr darauf hin, dass deine Arbeitsergebnisse für andere schwer zu verwenden sind.
Ja, bei dieser_ _einen Aufgabe! Dagegen finde ich , zwanghaft allem Python überstülpen zu wollen eher einen Widerspruch zu ... Vancouver schrieb: > The > right tool at the right time. Ich nutze auch noch Papier und Bleistift! Nicht nur einen Taschenrechner!!! DAMIT kann man Algorithmen entwicklen!!! Ein paar Absätze darunter spreche ich davon, dass ich auch Javascript nutze wenn es passt! Auf "ich postuliere eine reine browser lösung" kam Jupyter. Schön, kenne ich! aber das ist keine reine javascript-browser lösung die ich postuliert habe, sondern ein Frontend für python! Mir würde etwas in Richtung Propel oder http://mathnotepad.com/ vorschweben... nur eben mit den üblichen mathematischen "standart"-tools. Kann ich etwas mit 3 python libs erschlagen, stehen die chancen gut, dass ich mit einer verfügbaren scilab, matlab oder octave toolbox gleich gute oder auch idente ergebnisse erhalte (weil ohnehin im hintergrund z.b. opencv, fftw,... angewendet wird)! Zu einer schönen Puplikation gehören für mich z.B grafiken, die den selben Font aufgreifen wie das restliche Dokument. Latex mit pgfplots ermöglicht mir das in sehr vielen fällen. In wenigen Fällen nutze ich gnuplot dazu ein pdf+tex file zu erstellen. Auch hier bringt mir python keine benefits zu meinen bisherigen tools. sorry, ist so! Wenn DU deine komplette Arbeit in einem Stück in python abliefern kannst, dann tu es doch bitte! Wenn ich eine Möglichkeit sehen würde, wär meine Faulheit garantiert stärker wie meine Syntaxabneigung! Aber 2/3tel vom Gesamtcode in wrapper-objekte zu stecken und dann noch einen python interpreter einzubinden nur damit ich python verwendet habe- sorry, da sehe ich wirklich keinen Vorteil! Ich hatte ein C gerüst. Dazu habe eine mächtige Library (Qt) ausgesucht die mir einen "Parser" (zufällig Javascript, hätte auch python, lua oder sonst was sein können!) mitbringt und dazugelinkt. Das ist sicher keine typische Rapid Prototyping Fragestellung, aber das war/ist meine Problemstellung. Und das Debuggen von den laufende Javascript-Problembeschreibungen, läuft komplett transparent im QtCreator neben der debuggerei von den C-Modellen. Suppi, oder? Ich nehme an, das geht mit dem gdb und python auch problemlos, aber beide Lösungen nehmen sich hier nichts! Wenn du dir über andere Probleme Gedanken machen darfst, freu dich doch! Mir würde python bei meinen Problemen mit effizienter Cachline-Nutzung NICHTS bringen! Ich brauche_ in _dieser fragestellung kein scipy, numpy, matplotlib udgl.! Es wird auch Gründe geben, warum TensorFlow neben Python auch C++, Java, Go und JavaScript bindings hat! Zumindest gibt es offensichtlich leute die eine dieser Sprache für IHRE Anwendung bevorzugen. Und dann kommt noch die oben bereits kommentierte Unterstellung: Claidhem schrieb: > Hans schrieb: >> Ich kann C++ ausreichend gut (ich werde seit 17 Jahren dafür bezahlt!). >> Ich habe eine für mich effiziente Entwicklungsumgebung gefunden >> (Slackware, Qt5, Impulse, LaTex, gnuplot, Maxima,...). >> Ich beschäftige mich mit Algorithmen und nicht mit plotten. >> Daher habe ich postuliert, dass ich in C++ nicht langsamer bin als >> jemand anderes in Python. > > Oder anders gesagt: Jemand mit viel weniger Erfahrung kann in der > gleichen Zeit dasselbe erreichen, nur durch Verwendung eines anderen > Tools. > > Und von jemand anders ist deine Lösung dann auch nicht wartbar, weil nur > du die Tools beherrscht. Als Bastelei für Privatzwecke okay, als > professionelle Lösung eigentlich unbrauchbar (auch wenn mir klar ist > dass viele Buden unprofessionelles Vorgehen dulden). Sorry, warum soll eine Pyton Lösung professioneller sein als die Anwendung einer Matlab Toolbox die 100% der Anforderungen erfüllt??? Selbst irgend ein Labview Ding kann eine Aufgabe perfekt erfüllen! Zu sagen, "das ist aber nicht python, das mache ich jetzt grundlos neu", das wäre wirklich unprofessionel! Auf die anderen Unterstellungen will ich garnicht mehr eingehen. 73
Claidhem schrieb: > Nein. Ich sage nur, dass es unprofessionell ist, ein Werkzeug aufgrund > der persönlichen Vorlieben zu wählen, wenn das Arbeitsergebnis für > andere deutlich schwerer zu warten ist. Aha... TIOBE Index for April 2018 Apr 2018 Apr 2017 Change Programming Language Ratings Change 1 1 Java 15.777% +0.21% 2 2 C 13.589% +6.62% 3 3 C++ 7.218% +2.66% 4 5 change Python 5.803% +2.35% C/C++ kann keiner Warten... i.O. und auf welche wundersame Weise löst Python alle Wartbarkeitsprobleme dieser Welt??? In selber weise, wieso in aller Welt setzt du einen Algorithmus in Python schneller um als jemand in einer beliebigen anderen Sprache ??? 73
Hans schrieb: > Schön, kenne ich! > > aber das ist keine reine javascript-browser lösung die ich postuliert > habe, sondern ein Frontend für python! Dash, Bokeh. Hans schrieb: > Auch hier bringt mir python keine benefits zu meinen bisherigen tools. > sorry, ist so! Aber auch kein Nachteil, außer dass du es nicht magst. Hans schrieb: > Ich hatte ein C gerüst. Dazu habe eine mächtige Library (Qt) ausgesucht > die mir einen "Parser" (zufällig Javascript, hätte auch python, lua oder > sonst was sein können!) mitbringt und dazugelinkt. Wie gesagt, bei Profis geht es nicht darum, was du gerade zur Verfügung hast. Sondern darum, was andere nutzen können. Wenn du nur fröhlich Lösungen für dich daher bastelst, kannst du natürlich immer nehmen was du willst. Hans schrieb: > Sorry, warum soll eine Pyton Lösung professioneller sein als die > Anwendung einer Matlab Toolbox die 100% der Anforderungen erfüllt??? Muss es nicht sein. Es ging nur um die Behauptung, dass deine selbst zusammengestrickte C++-Umgebung genauso gut handhabbar sei als eine Python-Umgebung. Und das stimmt im professionellen Umfeld eben nicht. Hans schrieb: > C/C++ kann keiner Warten... i.O. Du hast es nicht kapiert, worum es hier geht. Für normale Anwendungen und Embedded ist C/C++ eine feine Sache. Aber nicht für die hier diskutierten Anwendungen. Hans schrieb: > In selber weise, wieso in aller Welt setzt du einen Algorithmus in > Python schneller um als jemand in einer beliebigen anderen Sprache ??? Deine Behauptung war es, dass du in C++ gerade mal so schnell bist wie jeder andere in Python.
Hört auf zu streiten, nehmt Purebasic. Dessen Kompilate sind absolut schnell und klein. "Hallo Welt" ist zum Beispiel schlappe 3 KB groß. Schaut Euch Borland C++ an. 300 KB! ;-O Oder Python, wo ja der ganze "Interpreter" mitgeschleppt werden muß! ;-O Naja, ich würde für wissenschaftiche Arbeit Python UND C++ nehmen. Ja, man kann mit Python auch Spiele schreiben. Oder Programme, um die DNA zu simulieren, wie meine Tutorin. Aber eine vernünftige Wrapper Schnittstelle zu C++ Bibliotheken ist dabei Pflicht! Bedenkt bitte auch, das bei diesem Konzept Eure Arbeit praktisch Opensource wird, da Python eine "Interpretersprache" ist! mfg
Claidhem schrieb: > Du hast es nicht kapiert, worum es hier geht. Für normale Anwendungen > und Embedded ist C/C++ eine feine Sache. Aber nicht für die hier > diskutierten Anwendungen. habe ich ein einziges mal von embedded anwendungen gesprochen??? Und von "normalen Anwendungen" wird hier auch selten gesprochen... Claidhem schrieb: > Hans schrieb: >> Auch hier bringt mir python keine benefits zu meinen bisherigen tools. >> sorry, ist so! > > Aber auch kein Nachteil, außer dass du es nicht magst. Genau! Habe ich auch nicht behauptet. Ich habe folgendes geschrieben: Hans schrieb: > Ich mache für meine Diss alles in C++. > > Grund: Ich kann so gut C++, dass ich damit gleich schnell bin wie jemand > anderes in Python. Und wieder fasse ich zusammen: Wirklich Zeit rennt in andere Dinge als Kodierung. Da hatte ich gott sei dank schon teilweise Zustimmung erhalten. Und unterstellt habe ich nur, dass mir_ für _meine Aufgabe Python keinen Vorteil bietet hinsichtlich Umsetzungszeit! Ich sagte, ich sei bei meinem Problem gleich schnell da ich die Sprache gut kenne. Ich habe auch schon einige, bisher nicht widerlegte Begründungen dazu gegeben! Corner cases.. zugegeben... aber vieles in der Wissenschaft ist ein corner-case und trotzdem interessieren sich Menschen genau für dieses Detail! Claidhem schrieb: > Hans schrieb: >> Sorry, warum soll eine Pyton Lösung professioneller sein als die >> Anwendung einer Matlab Toolbox die 100% der Anforderungen erfüllt??? > > Muss es nicht sein. Danke! Claidhem schrieb: > Wie gesagt, bei Profis geht es nicht darum, was du gerade zur Verfügung > hast. Sondern darum, was andere nutzen können. Siehe oben. Ist doch scheiß egal in welcher Sprache etwas geschrieben ist! Pflichte ich dir total bei! Der JS solver von dem ich in meinem 1. posting geschrieben habe geht mit ein paar schiebereglern im HTML als ZIP an eine Behörde. Nach Rücksprache war das die einfachste Methode denen "nutzbare Programme" einfach so zur Verfügung zu stellen. Dieses Detail kann auch "Nutzbarkeit" bedeuten. gut, corner-case...ok! Wartbar/Nutzbar wirds in vielen Fällen aber auch durch ausreichende Dokumentation (und die kann auch unterschiedlichst ausfallen). Das nimmt dir keine Sprache ab. Nichtmal UML kommt meiner erfahrung nach ohne zusätzlicher doku aus. vllt. habe ich das bisher auch nie richtig gemacht oder auch nie richtig gemacht gesehen... ist ja auch wieder "corner-case" Manche Dinge sind aber schon durch die Unit-Tests ausreichend erklärt... hängt vom Problem ab das man löst. Hans schrieb: > Claidhem schrieb: >> Nein. Ich sage nur, dass es unprofessionell ist, ein Werkzeug aufgrund >> der persönlichen Vorlieben zu wählen, wenn das Arbeitsergebnis für >> andere deutlich schwerer zu warten ist. Bei der Umsetzung wird man immer den einen oder anderen Kompromiss eingehen müssen. Ich bin mir sicher, python bietet wesentlich mehr Packages für lineare Algebra an als nur numpy und tensor flow (wenn man das als solches bezeichnen will). wenn ich jetzt code für die eine lib schreibe und meine kollegen mehrheitlich die andere nutzen (oder sich diese Vorlieben verschieben... warum auch immer...), dann ist das auch semi-optimal. Wie kommst du jetzt darauf python würde daran was ändern??? Ich habe tatsächlich eine Zeit lang c in einem embedded umfeld programmiert. Da hatten wir einen Styleguide der gewisse Konstrukte/Sprachelemente verbot. Hauptgrund dafür war meist die Lesbarkeit. Dafür war die klammersetzung und so völlig wurscht! Wir hatten definiert in welche Form der pretty-printer im commit hook den code bringen soll. Dazu war definiert was in einem design-dokument stehen muss und wer in welchem "subsystem" der "architekt" war. DAS erzeugte Wartbarkeit. statt c hätten wir auch ada verwenden können ... 73
Hans schrieb: > Nein, du hast vermutet ich würde ahnungslos daherplappern. Da Du bereits mehrfach erwähnt hast, daß Du in die Dokumentation geschaut hast, ist das ja wohl auch zumindest anfangs so gewesen -- Du weißt schon, als Du noch erzählt hast, Python werde nur genutzt, weil es so cool sei. > Sheeva P. schrieb: >> Daß eine Standard-Distribution von Python nicht alles sofort >> out-of-the-box kann, ändert nichts daran, daß Python eine Wunderwaffe >> ist und ganz alleine vermutlich Deinen ganzen Zoo ersetzen könnte. > > Ersetzen, mag sein. Aber ist es in jedem Fall besser??? Hat das denn jemand behauptet? Nö. Vergiß' nicht: es warst Du, der mit der oben erwähnten steilen Behauptung in diesen Thread eingestiegen ist. > Bezweifel ich. Das kannst Du meinetwegen halten, wie Du magst. Ich habe kein Interesse daran, missionarisch tätig zu sein oder zu werden. Allerdings möchte ich auch nicht als blöder Hipster abqualifiziert werden, weil ich auch eine Skriptsprache nutze, welche sich in der Datenwissenschaft und in vielen anderen Bereichen größter Beliebtheit erfreut. Daß Python so beliebt, und in manchen Kreisen meinetwegen auch cool ist, dafür gibt es gute Gründe. Leistungsfähigkeit, Performanz, Flexibilität, eine herausragende Infrastruktur, ein besonders einfacher Zugang und die Plattformunabhängigkeit wurden bereits genannt. Noch nicht genannt wurde die Integration in andere Ökosysteme wie Java und .NET und noch so viele andere Fähigkeiten, daß es fast eine eigene ISBN dafür braucht. ;-) Letzten Endes hast Du das Pferd also ganz grundsätzlich von der falschen Seite aus aufgezäumt: Python wird nicht deswegen so gern benutzt, weil es cool ist, sondern es ist so beliebt und, meinetwegen, cool geworden, weil es so vielseitig und so mächtig ist. Du verwechselst Ursache und Wirkung. > Sheeva P. schrieb: >> Erfreulicherweise bringt Flask bereits einen eigenen Entwicklungsserver >> mit und ist daher für soetwas genau das: standalone. Kurz gesagt, sieht >> eine minimale Flask-Applikation etwa so aus: > > Ich meinte pures html5... Kann erstaunliches... Dein flask Beispiel wäre > mit HTML,head und Body tags dann ein 7 Zeiler bei minimalem Aufwand. Na wenn das so einfach ist, dann zeig diesen 7-Zeiler doch einfach. Dann können wir uns mal gemeinsam anschauen, ob da eine Routing-Engine, eine Template-Engine, ein Debuggingwerkzeug und auch nur ein Bruchteil jener vielen nützlichen Werkzeuge enthalten ist, die Flask mitbringt. Wenn wir schon dabei sind, können wir gleich auch nochmal schauen, ob sich damit ebenso einfach beliebige Datastore-Frameworks und diverse Erweiterungen verwenden lassen, wie das bei Flask der Fall ist. ;-) > Ich habe geschrieben, dass in meinem Anwendungsfall c++ aus mehreren > Gründen nicht wesentlich aufwendiger ist. > > Ich habe geschrieben, dass ich für viele Dinge (für mich) sehr > effiziente Tools gefunden habe. Dabei vergißt Du natürlich den Aufwand, diese Vielzahl an Werkzeugen und Bibliotheken zu suchen, zu lernen, und zu evaluieren, und nennst das dann einen seriösen Vergleich? Genau darin liegt eine der wesentlichen Stärken von Python, nämlich in der bereits erwähnten, sehr starken Infrastruktur, die eine enorm große Bandbreite von Anwendungsfällen abdeckt und dennoch konsistent, stabil und sehr leicht nutzbar ist, namentlich über den oben bereits erwähnten Paketmanager pip. > Ich habe nie behauptet, ich würde alles nur in c++ machen! Aus mir unerfindlichen Gründen hatte ich Deinen ersten Beitrag in diesem Thread allerdings ganz anders verstanden: Hans schrieb: > Dirk schrieb: >> Weiss jemand den Grund für Python für wissenschaftliche Projekte? > > weil es gerade "cool" ist! > > Ich mache für meine Diss alles in C++. > > Grund: Ich kann so gut C++, dass ich damit gleich schnell bin wie jemand > anderes in Python. Es warst doch Du, der das geschrieben hat, oder? Wie sonst wolltest Du das verstanden wissen als, frei übersetzt: "Python ist was für blöde Hipster, nur C++ ist gut genug für richtige Profis"? Von jemandem, der gerade seine Dissertation verfaßt und somit wohl kurz vor dem Ende einer akademischen Ausbildung steht, kann man doch wohl erwarten, daß er weiß, was er sagt, und versteht, welche Hybris aus solchen Aussagen spricht. Wenn nicht, solltest Du es sehr dringend lernen, sonst wirst Du damit im Berufsleben noch böse auf die Nase fallen. Ich jedenfalls habe ein paar Kollegen, die ziemlich allergisch darauf reagieren würden, wenn ihnen ein frisch aus der Uni gepurzelter Jüngling irgendwelchen Bullshit über ihre Werkzeuge erzählen und ihnen die Professionalität absprechen wollte. ;-) > Ich habe nur festgestellt, dass es mehr als nur ein einziges "richtiges" > Werkzeug gibt! Auch das hatte ich bei Deinem ersten Beitrag ganz anders verstanden. > Sheeva P. schrieb: >> Anwendungsfälle, in denen man so etwas brauchen könnte, vermutlich >> dadurch abfackeln, indem man wiederum einen Python-Interpreter in das >> von Boost.Python erzeugte Shared Object einbaut > > Sorry, aber genau um das geht's. > > Viele Wege führen nach Rom! Mag sein, daß es dir mittlerweile darum geht. Mir hingegen ging es zunächst darum, die Frage des TO zu beantworten, warum Python in der Wissenschaft so beliebt ist. Und nachdem ich diese Frage dann beantwortet hatte und Du mit Deinen steilen Thesen aus dem zitierten Eingangsbeitrag auftratest, wollte ich diesen Unsinn nicht unwidersprochen stehen lassen. > Und Python löst nicht alle Problem. Das hat doch auch niemand behauptet, und es stimmt natürlich: Python kann ganz sicher nicht alle Probleme lösen, die die Welt immer noch mit Krieg, Hunger und Armut hat. Es wäre aber auch ein bisschen vermessen, das von einer Programmiersprache zu erwarten. Für die meisten softwaretechnischen Probleme hingegen ist es ziemlich gut geeignet, solange es nicht gerade um spezielle Nischenthemen wie Embedded-, Kernel- und Treiberentwicklung oder hartes Numbercrunching unter Echtzeitbedingungen geht. Wobei auch das noch nicht ganz den Tatsachen entspricht: Im Embedded-Bereich soll Micropython auf besseren Mikrocontrollern gut funktionieren, höre ich. ;-) > Möglicherweise aber für dich... Nein, stell' Dir vor: sogar bei mir gibt es regelmäßig Dinge, für die ich andere Werkzeuge anstelle Pythons benutze. Triggerfunktionen in PostgreSQL zum Beispiel könnte ich zwar in Python schreiben, mach das aber nur in sehr wenigen Ausnahmefällen, weil PL/PGSQL direkt auf dem PostgreSQL-Core läuft. Für andere Programme benutze ich hingegen regelmäßig C++, mal eingebettet in Python und ein andermal auch standalone. Und dann benutze ich auch immer mal wieder die Bash, GNU Make, Java, ECMAScript und Perl -- nämlich immer genau dann, wenn das sinnvoll, also für den jeweligen Anwendungsfall die einfachste, schnellste, wartbarste, kurz: die langfristig effizienteste sowie natürlich eine hinreichende Lösung bietet. Der Punkt ist nämlich, daß Python zwar ein hervorragender Allrounder ist, trotzdem aber manchmal andere Werkzeuge besser zum Anwendungsfall passen. Ein Profi versteift sich dann nicht auf ein bestimmtes Werkzeug wie Du in Deinem Eingangsposting, sondern greift in eine (idealerweise) gut gefüllte Werkzeugkiste und wählt daraus ein möglichst gut passendes Werkzeug.
~Mercedes~ schrieb: > Hört auf zu streiten, nehmt Purebasic. > Dessen Kompilate sind absolut schnell und klein. Das stimmt, aber leider läuft Purebasic nicht auf dem Raspberry und es wird wohl nie einen Port geben.
Hans schrieb: > Vancouver schrieb: >> Und nun liebe Kinder hört ihr wieder eine Folge aus der Serie "Meine >> Lieblingssprache ist viel besser als Deine Lieblingssprache. " > > Dazu macht es Sheeva Plug es gerade! Nein, Du hast es dazu gemacht. Siehe dazu meinen gerade geposteten Beitrag mit einem Zitat Deines Eingangspostings. > Vancouver schrieb: >> Mal ehrlich: manche Dinge gehen besser in Python, andere in C++. Das >> hängt alles von den Requirements ab. > > Nichts, aber auch gar nichts anderes habe ich behauptet! Aber ja doch, siehe Dein Eingangsposting. > Mein 2. Post: > Hans schrieb: >> Grafiken für wissenschaftliche Publikationen lässt man IMHO am besten >> latex zeichnen...pgfplots sei dank :) Da warst Du immerhin schon klug genug, das mit dem "IMHO" nur als eine persönliche Meinungsäußerung zu entschärfen. Aber klar, wer braucht schon sowas wie Interaktion, Zoomen, Ein- und Ausblenden, ... sowas brauchen ja nur Weltfremde mit Scheuklappen, wer sonst? > Hans schrieb: >> IMHO habe nicht ich die Scheuklappen auf, sondern 90% der >> mitkommentierenden. Wie oben beschrieben nutze ich viele >> unterschiedliche Tools. Du benutzt einen Haufen Drittwerkzeuge und kaprizierst Dich ansonsten auf genau eine Programmiersprache -- während die, welchen Du "Scheuklappen" aufzuhaben vorwirfst, jeder neben Python auch noch andere Sprachen kennen und nutzen. Ausgerechnet Du, der Du Python "schon als Sprache" nicht magst und darum nicht lernen magst (Spitzenbegründung: der grüne Akkuschrauber gefällt mir nicht, darum drehe ich meine Schrauben lieber von Hand ein), und bisher nicht mehr vorzuweisen hast als eine akademische Ausbildung, wirfst berufserfahrenen Profis vor, sie hätten "Scheuklappen" auf, seien "weltfremd" und im Grunde nur Fänbois eines Hype? Respekt, mein Junge, darauf muß man erstmal kommen. ;-)
Beitrag #5387488 wurde von einem Moderator gelöscht.
~Mercedes~ schrieb: > Aber eine vernünftige Wrapper Schnittstelle zu C++ Bibliotheken > ist dabei Pflicht! Check. > Bedenkt bitte auch, das bei diesem Konzept Eure Arbeit praktisch > Opensource wird, da Python eine "Interpretersprache" ist! Man kann Python-Code auch in Python-Bytecode, Java-Bytecode, oder erst in C++-Code und dann in nativen Binärcode übersetzen.
Hans schrieb: > Claidhem schrieb: >> Hans schrieb: >>> Auch hier bringt mir python keine benefits zu meinen bisherigen tools. >>> sorry, ist so! >> >> Aber auch kein Nachteil, außer dass du es nicht magst. > > Genau! Habe ich auch nicht behauptet. Doch. > Wirklich Zeit rennt in andere Dinge als Kodierung. Ja: 1. Entwurf, 2. Planung, 3. Prototyping 4. Evaluieren, 5. Coding, 6. Debugging, 7. Performanceoptimierung, 8. Deployment, 9. Pflege. Zumindest für die Schritte 3 bis 9 bieten Python (und übrigens je nach Anwendungsgebiet und -Fall auch andere Skriptsprachen) klare Vorteile. > Da hatte ich gott sei dank schon teilweise Zustimmung erhalten. So ein Argumentum ad populum ist ja auch immer wieder lustig. > Und unterstellt habe ich nur, dass mir_ für _meine Aufgabe Python > keinen Vorteil bietet hinsichtlich Umsetzungszeit! Ich sagte, ich sei > bei meinem Problem gleich schnell da ich die Sprache gut kenne. Nichtmal Bjarne Stroustrup, Herb Sutter, Nikolai Josuttis, Bruce Eckel, Rainer Grimm oder Scott Meyers schaffen das. Trust me on this one.
Sheeva P. schrieb: >> Und Python löst nicht alle Problem. > > Das hat doch auch niemand behauptet doch wurde es, mehrfach! beispielsweise hier: Sheeva P. schrieb: >> Nur sehe ich Python nicht als diese Wunderwaffe. > > Aber genau das ist es, und zwar nicht zuletzt auch... > Und komm mir jetzt bitte jetzt nicht wieder mit "es gibt aber noch Möglichkeit C um das mit python zu tun". Wie z.B. hier: Sheeva P. schrieb: >> Sheeva P. schrieb: >>> lohnt sich häufig ein kleiner Webservice zum Beispiel mit Flask >> >> Standalone reicht oft schon ... Die D3 ist wirklich nett... > > Erfreulicherweise bringt Flask bereits einen eigenen Entwicklungsserver > mit und ist daher für soetwas genau das: standalone. Sheeva P. schrieb: >> Ich meinte pures html5... Kann erstaunliches... Dein flask Beispiel wäre >> mit HTML,head und Body tags dann ein 7 Zeiler bei minimalem Aufwand. Ich meinte was ich schrieb. HTML+JS+CSS-Files die ich als zip einem anwender schicken kann. Und nein, nicht jeder kann sich schnell mal python installieren, da es sicherheitsrichtlinien gibt, die das in der heutigen IT verbieten können. Wenn du auf jedes x-beliebige problem mit kanonen schießt... gern! mach! Aber erkläre mich nicht für ignorant! Ich habe leider im Tagesgeschäft sehr oft solche fälle! Problem A ist vllt. mit Werkzeug X und Y gut zu lösen aber wenn jemand den masochistischen drag verspürt Problem C im 68000 assembler zu implementiern wird er schon wissen warum! Sheeva P. schrieb: > ür andere Programme benutze ich hingegen regelmäßig C++, mal > eingebettet in Python und ein andermal auch standalone. Und dann benutze > ich auch immer mal wieder die Bash, GNU Make, Java, ECMAScript und Perl > -- nämlich immer genau dann, wenn das sinnvoll, also für den jeweligen > Anwendungsfall die einfachste, schnellste, wartbarste, kurz: die > langfristig effizienteste sowie natürlich eine hinreichende Lösung > bietet. na, schau... tatsächlich... ähnlich wie bei mir... Sheeva P. schrieb: > Allerdings möchte ich > auch nicht als blöder Hipster abqualifiziert werden, weil ich auch eine > Skriptsprache nutze, welche sich in der Datenwissenschaft und in vielen > anderen Bereichen größter Beliebtheit erfreut. > Das habe ich nicht! ICH wurde mit einer "Hipster-App" in verbindung gebracht!!!! Jedenfalls will ich nicht als irgnorrant hingestellt werden weil ich an anderen Problemen_ arbeite die _andere Werkzeuge erfordern! Oder das ich nur zu dumm/einfältig/ignorrant/... bin das "richtige" tool zu verwenden.... so stand es oben mehrfach. Du fühlst dich als "profi" anscheinend gekränkt weil ich behaupte meine Aufgabenstellungen ohne Python genau so gut erledigen zu können wie mit. Aber ich habe eine verschrobene Auffassung und verschleiere meine inkompetenz. (steht so von andern personen oben geschrieben) hast du schonmal überlegt was ich mit 17 jahren berufserfahung alles ausprobiert haben könnte???? Ja, Python war dabei! Vielleicht nicht in ausreichender Tiefe damit sich mir alle dir wichtigen vorteile erschließen, aber bei dem Ausmaß an Beleidigungen die diese nutzergemeine hier so von sich gibt...naja C/C++ sind die einzigen compilersprachen die ich regelmäßig verwende. Da mache ich keinen hehl darum. Mit octave, scilab und matlab fahre ich sehr gut. 90% der aufgaben die ich damit bearbeite laufen auf eingebaute funktionalitäten raus. also bei _mir, jetz gerade_ kein bedarf hier nachzujustieren.
1 | import numpy as np |
2 | import matplotlib.pyplot as plt |
3 | s = np.abs(np.fft.rfft(np.loadtxt("test.csv").T))
|
4 | plt.plot(np.fft.rfftfreq(s.shape[0]), s) |
5 | plt.savefig("test.pdf")
|
kann ich in scilab mit
1 | plot2d(abs(fft(csvRead("test.csv"))));
|
2 | xs2pdf(gcf(),filename); |
Und??? Ich bin mir sicher, wir wären gleichzeitig am ziel gewesen! Und bei meinem Dissertationsvorhaben spielen dinge die ich in c++ machen kann eine große rolle! Ich habe oben genau beschrieben was meine beweggründe waren! Dagegen sind z.B. "das KO für C++", nämlich plots, nicht mein Hauptproblem. Sheeva P. schrieb: > Hans schrieb: >> Claidhem schrieb: >>> Hans schrieb: >>>> Auch hier bringt mir python keine benefits zu meinen bisherigen tools. >>>> sorry, ist so! >>> >>> Aber auch kein Nachteil, außer dass du es nicht magst. >> >> Genau! Habe ich auch nicht behauptet. > > Doch. Wo??? Zeig! Sheeva P. schrieb: >> Und unterstellt habe ich nur, dass mir_ für _meine Aufgabe Python >> keinen Vorteil bietet hinsichtlich Umsetzungszeit! Ich sagte, ich sei >> bei meinem Problem gleich schnell da ich die Sprache gut kenne. > > Nichtmal Bjarne Stroustrup, Herb Sutter, Nikolai Josuttis, Bruce Eckel, > Rainer Grimm oder Scott Meyers schaffen das. Trust me on this one. Echt? Begründe es jetzt endlich! Vor allem weil du ja gar noch nicht weißt was ich treibe. Ich weiß es von dir auch nicht! Sheeva P. schrieb: >> Wirklich Zeit rennt in andere Dinge als Kodierung. > > Ja: > 1. Entwurf, > 2. Planung, > 3. Prototyping > 4. Evaluieren, > 5. Coding, > 6. Debugging, > 7. Performanceoptimierung, > 8. Deployment, > 9. Pflege. > > Zumindest für die Schritte 3 bis 9 bieten Python (und übrigens je nach > Anwendungsgebiet und -Fall auch andere Skriptsprachen) klare Vorteile. benenne sie jetzt! bitte!!!! Warum codierst du in python schneller??? wieso optimierst du in python schneller??? warum soll die pflege mit python einfacher sein??? warum ist bei dir das deployment einfacher???? zum 9. sage ich jetzt nochwas: es gibt winqtdeploy und die windows zip-möglichkeit. Deployment KANN heißen: schicke ein standalone laufendes paket in form einer zip-file an den benutzer. In dem Fall bringt dir python keinen vorteil. jaja, corner-cases... alle deine "kunden" sind in der lage pip auf der command-line zu nutzen. alle deine cloud server sind entsprechend gemanaged und überhaupt, python kannst du auch zu einem binary kompilieren. Gut, ich hab verstanden! Aber wundere dich bitte nicht von anderen als Fänboi hingestellt zu werden! Ich habe das wohlgemerkt nicht getan und werde es nicht tun. Schließe bitte nicht von deinen Anforderungen auf die allumfassende Eignung von Python... Du hast sogar geschrieben, du nutzt je nach Eignung auch andere Dinge! Jetzt mach bitte kein Drama wenn ich sage, dass ich für meine Aufgabenstellung keine Vorteile aus Python ziehen kann. Vom Ton angreifend wurde ich erst nach solchen dummheiten: Der Andere schrieb: > Hans, du musst mal ein bischen über deinen Teller-(oder Rechner)rand > hinausschauen. > Ein Pytonscript kann ich nehmen und auf einem Rechner oder einem > virtuellen Cloudrechner ausführen, völlig problemlos. > > Dein toller C Code muss ich erst mal compilieren, dann muss ich die > passenden binären 3rd party libs auftreiben usw bis ich das alles > vieleicht irgendwann zusammengelinkt und ans Laufen kriege. > Mit Sprachen wie Phyton oder Java nehme ich den Sourcetopf und habe den > Kram in Nullkommanix am Laufen egal auf welcher Plattform. > > Und genau das macht den Vorteil aus. Wenn ich numpy kein schnelles BLAS findet, dann verwendet es das auch nicht. Wenn ich das aber am cloud-rechner haben will, dann muss ich die "passende binäre 3rd party lib" auftreiben. Ja, es mag vllt. auch so rennen. Aber völlig problemlos würde ich das nicht nennen! Java ist im allgemeinen genau so wenig "Nullkommanix" kompiliert wie C. Und jede Plattform hat ihre Eigenheiten. Scheiße, üblicherweise hängts sogar ab wie die platte formatiert ist ob z.B. Groß/Klein im Filenamen eine rolle spielt oder nicht. Von unterschiedlichen Fähigkeiten in der Gui ganz zu schweigen. Kann die Plattform kein OpenGL, wird PyQt sich genau so schwer tun wie Qt unter C++ oder Qt mit QML das zu nutzen! Sheeva P. schrieb: > (Spitzenbegründung: > der grüne Akkuschrauber gefällt mir nicht, darum drehe ich meine > Schrauben lieber von Hand ein) Hör auf mir sachen anzudichten! Hans schrieb: > Aber für gewöhnlich gibt's im Baumarkt mehrere Typen Akkuschrauber.. man > muss einfach nur einen in der Werkzeugkiste haben! 73
So, hier ein kurzer Zwischenstand: [Hans] Beiträge in diesem Thread: 18 Getippte Zeichen: 34888 Verschwendete Lebenszeit [1]: 174 Minuten [Sheeva Plug] Beiträge in diesem Thread: 17 Getippte Zeichen: 23232 Verschwendete Lebenszeit [1]: 116 Minuten [Sven B.] Beiträge in diesem Thread: 10 Getippte Zeichen: 11530 Verschwendete Lebenszeit [1]: 58 Minuten [C++Daddy] Beiträge in diesem Thread: 4 Getippte Zeichen: 3392 Verschwendete Lebenszeit [1]: 17 Minuten [Claidhem] Beiträge in diesem Thread: 3 Getippte Zeichen: 1797 Verschwendete Lebenszeit [1]: 9 Minuten [1]: Bei einer Durchschnittlichen Tippgeschwindigkeit von 200 zeichen pro Minute. PS: Das verwendete wissenschaftliche Auswerteskript wurde natürlich in C# geschrieben :-)
:
Bearbeitet durch User
Besten Dank für diesen Hinweis... Wie wär's wenn ein Mod den Thread komplett schließt??? Kommt doch so oder so nix raus. 73
Python hat den Vorteil dass es fast alles fertig gibt. Möchte man die Messdaten vom Oszi aufbereiten? Einfach fertiges CSV Import Beispiel als Vorlage nehmen, Export entsprechend formatieren, fertig ist das Programm in weniger als 20 Minuten. Fällt mir auf dass ich etwas ändern muss ändere ich das schnell, muss nix neu kompilieren, fertig aus. Für mich fast das Arduino der PC Welt. ;) Wenn es performant sein soll ist C++17 mitsamt boost, parallel mode libstdc++ und z.B. gmplib natürlich auch interessant. FORTRAN soll auch nett sein wenn man auf fertige Bibliotheken zurückgreifen möchte. Processing wird für Einsteiger übrigens auch gerne für Videoerkennungskram genutzt, basiert auf der Arduino IDE. Kann man sehr leicht an z.B. reactivision anbinden, wobei die Performanz nicht sonderlich überragend ist...
Beitrag #5388039 wurde von einem Moderator gelöscht.
Beitrag #5388138 wurde von einem Moderator gelöscht.
Beitrag #5388150 wurde von einem Moderator gelöscht.
Beitrag #5388730 wurde von einem Moderator gelöscht.
Hans schrieb im Beitrag #5388138: > Ihm ist einfach kein Argument mehr eingefallen warum die matplotlib > (oder irgend ein anderes Python-Modul) für mich besser wäre! Wie kommst Du bloß darauf, daß es mir darum ginge? Ich widerspreche nur Deinem Python-Bashing, mit dem Du uns Python-Entwicklern pauschal die Professionalität und Rationalität bei der Auswahl unserer Werkzeuge für unsere Anwendungsfälle absprichst. Was Du tust und welche Werkzeuge Du benutzt, ist mir erstens egal und zweitens auch nicht mein Thema.
Mir scheint, wir nähern uns wieder mal dem "Peak of inflated expectations" ... https://en.wikipedia.org/wiki/Hype_cycle Was ist eigentlich mit Java los? Das ist doch plattformunabhängig (und damit besser). Und mit dem brandneuen Jazelle Befehlssatz sogar zukünftig auf allen Mikrocontrollern. C wird man dann nur noch brauchen um für Demonstrationszwecke Wild-pointer und Memory-Leaks zu produzieren. Außerdem gibt es in Java kein Goto. Die Embedded Entwicklung auf 8-Bit MCUs passiert morgen überwiegend in Java (habe ich erwähnt, das ist plattformunahängig). Die Konfiguration mache ich dazu immer in XML - wegen guten Lesbarkeit. Selbst mit 1000 Zeilen einfach und intuitiv verständlich, kann jede Friseuse. Dazu noch ein UML Diagramm zur Dokumentation. Alle anderen grafischen Veranschaulichungen versteht keine Sau. Ich erstelle Software immer so, dass ich mir erstmal für 20T Euro ein IBM Produkt kaufe und die blinkende LED dann mit 20 Seiten verschiedener UML Diagrammen entwerfe. Da UML, versteht jeder die blinkende LED sofort, was mich ohne UML Wochen gekostet hätte. In der Zukunft wird Software ohnehin nur noch modellbasiert entwickelt. Die Zukunft wird so aussehen, dass man nur noch einen LED Baustein auf einen Timerbaustein ziehen muss und dann auf Play klickt. Die Hälfte der Entwicklungsabteilung kann man auch entlassen, da mit Produktivitätstools wie DOORS und Rhapsody nur noch die Hälfte an Leuten notwendig sind. Round-trip engineering ist dabei unnötig und diff ist von gestern und überbewertet. Ein textuelles diff ist außerdem schwer verständlich, das versteht eh keine Sau, weswegen es besser ist, farbige Ausdrucke in Leinwandgröße auf dem Boden liegend auf Änderungen hin zu begutachten.
Horst meinte: > In der Zukunft wird Software ohnehin nur noch modellbasiert entwickelt. > Die Zukunft wird so aussehen, dass man nur noch einen LED Baustein auf > einen Timerbaustein ziehen muss und dann auf Play klickt. So funktioniert der Embarcadero C++ Builder schon heute, wenn man da die VCL oder Firemonkey benutzt. Trotzdem ist noch ne Menge "Glue - Code" zwischen den Komponenten nötig. Auch Together, die Rose oder Telelogic Tau bauen ja nur Rahmen. Meinst Du wirklich das sich dies in absehbare Zeit wirklich radikal ändern wird? mfg
~Mercedes~ schrieb: > Horst meinte: > >> In der Zukunft wird Software ohnehin nur noch modellbasiert entwickelt. >> Die Zukunft wird so aussehen, dass man nur noch einen LED Baustein auf >> einen Timerbaustein ziehen muss und dann auf Play klickt. > > So funktioniert der Embarcadero C++ Builder schon heute, > wenn man da die VCL oder Firemonkey benutzt. > Trotzdem ist noch ne Menge "Glue - Code" zwischen den > Komponenten nötig. > > Auch Together, die Rose oder Telelogic Tau bauen ja nur Rahmen. > Meinst Du wirklich das sich dies in absehbare Zeit wirklich > radikal ändern wird? > > mfg Dass Du den vor Ironie triefenden Beitrag scheinbar nicht als solchen erkannt hast, bereitet mir ernsthafte Sorgen... Die kurze Übersetzung ins Nicht-ironische ist: Das waren alles "inflated expectations" auf dem Höhepunkt des jeweiligen Hype Cycles.
Horst meinte: > Dass Du den vor Ironie triefenden Beitrag scheinbar nicht als solchen > erkannt hast, bereitet mir ernsthafte Sorgen... :--P Natürlich habe ich ihn erkannt, Horst. Trotzdem ich erst Mitte diesen Jahres 16 Jahre werde, hab ich den ganzen Kram bereits ausprobiert. Am Besten gefällt mir deshalb der Embarcadero C++ Builder. Nicht nur, das damit in der Firma meines Vaters geproggt wird, nein auch die Programmgröße hält sich in annehmbaren Grenzen. Und, es hat einen weiteren Grund. Schade, das es Borland nicht mehr gibt. Borland hat uns Ossis unsere Raubkopien von C++ und Turbo - Pascal nach der "Wende" kostenlos legalisiert. Das vergessen wir Borland nicht. mfg
Borislav B. schrieb: > [1]: Bei einer Durchschnittlichen Tippgeschwindigkeit von 200 zeichen > pro Minute. Wenn der ganze Ramsch in einem Lauf runtergetippt wurde... Bedenkt man aber noch die Zeiten, um sich den Text auszudenken und eventuelle Tippfehler zu korrigieren, das Gesagte des Gegners zu kopieren und zu zerreißen das ein oder andere nochmal umzuformulieren, dann ist eher ein Wert von 50 Zeichen pro Minute realistischer. Dann hat man schon einen ehrlicheren Wert, wie viel Lebenszeit da wirklich vergeudet wurde (zumindest bei den Spitzenreitern :D)
SciPy, Anaconda, Jupyter... und hunderte andere science Bibliotheken mit einer einfach zugänglichen aber mächtigen Programmiersprache. Und man sollte nicht vergessen das man Programmteile die in C oder C++ geschrieben wurden sehr leicht in Python einbinden kann. Wenn es mal also doch schnell sein soll muss man nicht komplett zu C/C++ wechseln. Das ganze wird durch durch die Tatsache abgerundet dass es freie Software ist. Man muss für diverse Erweiterungen und weitere Bibliotheken keine Lizenzgebühren an ein Unternehmen abdrücken.
Dr. X schrieb: > Ist eben ein bischen so wie Arduino bei Mikrocontrollern ("welche > Bibliotheken muss ich zusammenstöpseln?"). Ich will nicht wissen wie viel Lebenszeit du schon mit der Einstellung verschwendet hast und wie viel Pfuscharbeit dabei raus kam weil du meinst alles selber machen zu müssen. Schon mal von Spezialisierung gehört? Und der Vergleich mit Arduino hinkt massiv. Python Bibliotheken sind das selbe wie C++ Bibliotheken, etwa Boost.
Windstark schrieb: > Und der Vergleich mit Arduino hinkt massiv. Python Bibliotheken sind das > selbe wie C++ Bibliotheken, etwa Boost. Nur dass ihre Anwendung gelegentlich in lesbarem Code resultiert. scnr
Thread beobachten
Seitenaufteilung abschaltenBitte 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.