Octave hat zu lange auf ihrer Console herumgeritten und verpasst der CLI eine gute GUI zu verpassen. Der Hauptgrund warum die meisten Linux Anwendungen außerhalb von Spielereien unbrauchbar sind.
Programmierer wissen, dass eine ordentliche IDE einem sehr viel Debug arbeit abnehmen kann. Wir sind auch nicht in den 90er Jahren, wo man noch mit FPRINTF seine Debug Ausgaben getätigt hat.
Der scheinbar rettende Halm war das QtOctave Projekt. Die GUI ist im Moment aber eher unbrauchbar. Sogar das Setzen von Debug Punkten ist buggy.
Auch heute kämpft Octave noch mit immensen Performance Problemen. Ohne alternative BLAS Bibliotheken rechnet jeder Gameboy schneller. Der PARFOR Befehl ist nur ein Makro für ein simples FOR. Mathworks versteht seine Kunden und kitzelt aus jedem Algorithmus das letzte Stück Performance heraus. Man kann sich praktisch sicher sein, dass die gleiche Performance, egal in welcher Sprache, nur mit einem sehr hohen Programmieraufwand erreicht wird.
Wir haben Octave und Python bei uns kurz ausprobiert und dann dennoch 12.000 € je Nutzer für MATLAB samt Toolboxen ausgegeben. Das Gefälle an Performance und Produktivität ist einfach zu groß. Für Prototyping ist MATLAB unschlagbar. Vergleichen mit den Lohnkosten entsprechender Mitarbeiter ist es auch nur ein Bruchteil.
Werde aber dennoch spenden. Fehler hin, Fehler her. Konkurrenz belebt das Geschäft.
Zielgruppe: Denke das Ingenieure nicht die Zielgruppe von octave sind. Im Bildungssektor ist octave aber wirklich eine Alternative. Kostenlos und Bürokratielos kann man Schülern/Studenten "Matlab"-Syntax beibringen.
Zur Geschwindigkeit: Es ist in der Tat langsam. Wenn man große Projekte hat ist Matlab sinnvoller. Aber es gibt halt auch viele kleine Anwendungszwecke für die octave vollkommen ausreicht.
Zur GUI: Ich bevorzuge keine GUI, bin aber seit fast 20Jahre Linuxnutzer. In Gegenteil octave4 hat eine GUI (qtoctave ist gar nicht nötig) und seitdem startet und schließt octave langsamer. Ich verwende octave oft als TR und da ist es nun mal ein Vorteil, wenn ich die Enter-Taste noch gar nicht losgelassen habe und octave schon gestartet ist
Irgenwie wird mich das Gefühl nicht los, dass hier viele einfach kommentieren, ohne wirklich Ahnung von der Materie zu haben. Es fällt doch auf wenn ein Leihe über ein Thema spricht und versucht es als Wissen zu verkaufen.
Ich habe mal im Bildungssektor gearbeitet. Da ist MATLAB ebenfalls konkurrenzlos. Die Preise fallen ggü. der kommerziellen Version auf ein Bruchteil. Eine Klassenlizenz inklusive mehrerer Toolboxen kostet teilweise weniger als eine Einzellizenz für den professionellen Einsatz. Das Jährliche Update hatte damals < 100€ gekostet. Das ist geradezu lächerlich.
Dann kommen die bugs, nicht implementierte Funktionen und die lahmarschigkeit. So etwas tut keiner seinen Studenten an. Die meisten Cracken sich MATLAB, schreiben den Code, testen ihn unter Octave und gehen mit einem "Octave" Ergebnis an die Öffentlichkeit.
Programme ohne GUI bleiben ein nutzloses Nischenprodukt. Wir sind nicht in den 90er Jahren wo so sich Jemand noch sinnvoll damit befasst.
PS:Wenn du Octave wirklich benutzt hättest, würdest du auch wissen, dass QtOctave komplett übernommen wurde um die aktuelle Octave GUI zu stellen.
Ich sehe MATLAB zum Glück ganz und gar nicht mehr konkurrenzlos. Für die meisten wissenschaftlichen Anwendungsfälle ist es freien Lösungen basiert auf Python, R oder Julia klar unterlegen.
Dementsprechend wird Octave als freie Alternative zu MATLAB auch weniger interessant.
- Community niemals. Bei kommerziellen Versionen werden Fragen von Ingenieuren und Mathematikern per Telefon beantwortet. Sie liefern Codeschnipsel und optimieren bei bedarf lahmen Code. Die Community für die kostenfreie Version ist ebenfalls riesig.
- Erstverfügbarkeit von Algorithmen: MATLAB ist teilweise ein Jahr vor allen anderen Konkurrenten
Der einzige Vorteil sind eingesparte Kosten, die sich wiederum durch's Frickeln, Debuggen und lahmarschigen Code amortisieren.
Der Benchmark ist doch dummes Zeug und völlig irrelevant wenn nicht sogar OT.
1. Matlab selbst ist zum einen nicht mit C vergleichbar [1].
2. Die Perfomance mit Numpy ist erheblich besser als reiner Python Code. Die Syntax ist dennoch 100% Python. Weitere Pakete für Python, welche in ihrer Sparte die Performance erheblich steigern, sind Numba und PyTables. Diese Pakete müssen selbstverständlich berücksichtigt werden.
In Verbindung mit einer guten IDE (z.B. PyCharm) schreibt sich der Code unter Python fast von alleine und lässt sich vor allem vernünftig debuggen. Matlab-Anwender (und universitäre Lehrkräfte) sind immer wieder erschrocken, wie einfach es sein könnte. Gefrickelt wird mit Python also gar nicht. Im Gegenteil - mit Unittests können erstellte Funktionen abgesichert und eine optimale Codequalität auch über einen längeren Entwicklungszyklus gewahrt werden. Matlab bietet diese Funktionalität gar nicht erst an.
Von der Performance mag es bei vollständig durchoptimiertem Code möglicherweise einen Geschwindigkeitsvorteil mit dem Faktor 2-3 auf Matlabs Seite geben. In den wenigen Fällen, in denen dies relevant wäre, müsste der Programmierer aber auch in der Lage sein, dieses Potenzial heraus zu kitzeln. Dabei muss berücksichtigt werden, wie teuer die Entwicklungszeit ist (Personalkosten!). Diese ist bei Python in der Regel extrem niedrig.
Am Schluss also noch ein "Reale Welt Benchmark", bei welchem die Performancevorteile von reinem C-Code fast aufgezehrt werden [2].
Mein klarer Favorit für Scientific Computing ist demnach Python, wobei ich leider immer noch eine Simulink-Alternative vermisse - hier hat Matlab tatsächlich noch einen großen Vorteil. Ihre Argumentation lässt leider darauf schließen, dass Ihnen die Möglichkeiten von Python weitestgehend unbekannt sind, da Sie sich von scheinbar plausiblen Benchmarks in die Irre führen lassen. Geht es wirklich um die reine Performance, muss an eine Hybridlösung mit C++ gedacht werden.
Benchmarks sind das einzige greifbare. Intuition trügt öfters.
Zur ersten Referenz: In MATLAB gab es mit 2015b ein großes "Execution Engine" Update. Es ist kein MEX mehr notwendig, da es intern schon getätigt wird [1]
Deswegen lässt sich jetzt jedes M Programm auch als MEX Compilat betrachten, wenn alten Benchmarks nachgegangen wird oder die in der geplosteten Referenz. Außerdem lassen sich bei Mathworks Performance Issues angeben, die in den nächsten Versionen behoben werden. Daher ist es sehr wohl mit C vergleichbar. Hinzu kommt, dass nahezu alle Matrix Operationen intern als FORTRAN Calls realisiert sind.
Klar, Python ist in den letzten Jahren deutlich schneller geworden. Dennoch klafft bei numerischen Anwendungen eine Lücke von Faktor 10 und mehr. Wenn ein Algorithmus unter C eine Stunde braucht, wären es bei Python 10 oder mehr. Es sind nicht die 2-3 mal, selbst das wäre schon schlimm. Statt ner Stunde drei Stunden zu warten ist schon bitter bei den Lohnkosten je Stunde. Das ist leider nicht akzeptabel. Der Vorteil meines Links (Benchmarks) ist, dass jeder eine schnellere Implementierung vorschlagen kann. Da gibt es einige solche Seiten, alle geben ein einheitliches Bild ab. In den zitierten Papern ist dies nicht der Fall. Deswegen ist es weniger praxisnah.
Ich liebäugel schon lange mit Python und setze es immer dort ein wo es geht um Lizenzen zu sparen, von daher kann ich doch mitsprechen. Kann PyCharm Plots live bearbeiten? Ich hab ne IntelliJ Lizenz bin aber immer noch bei Jupyter.
"Im Gegenteil - mit Unittests können erstellte Funktionen abgesichert und eine optimale Codequalität auch über einen längeren Entwicklungszyklus gewahrt werden. Matlab bietet diese Funktionalität gar nicht erst an. Matlab bietet diese Funktionalität gar nicht erst an."
Hier noch ein Update [2]. MATLAB hat ein sehr ausgereiftes Test-Framework. Daneben gibt es Profiling, Pakettierung, Code Coverage usw..
Das Performance-Argument scheint die einzige wirklich greifbare Kritik zu sein und auch dann reden wir hier über Nischen bei komplexen Simulationen oder BigData-Geschichten, die lange nicht jeden betreffen. Dies als dramatisch schlimm hochzustilisieren halte ich für übertrieben, zumal Numpy das Einbinden von C++ und Fortran erlaubt. Hier macht sich dann auch der Speichervorgang auf die Platte bemerkbar, womit man letztlich wieder vergleichen kann, welche Sprache die besseren Tools für HDF5 anbietet - und ich denke, PyTables hat hier schon ziemlich effiziente Möglichkeiten zur Bearbeitung sehr großer Datenmengen.
PyCharm ist nicht für die live Bearbeitung von Plots geeignet. Dies muss die figure()-Umgebung von Matplotlib bereitstellen; dort ist in gewissen Bereichen eine live-Bearbeitung allerdings möglich. Die Community-Edition reicht eigentlich aus, außer man benötigt Tools für Datenbanken oder Web-Entwicklung. Jupyter-Notebooks lassen sich auch per PyCharm komfortabel bearbeiten.
Ein Nachteil - aber auch gleichzeitig ein Vorteil - von Python ist letztlich, dass durch die verschiedenen Module und unterschiedlichen Entwickler nicht alles aus einem Guss ist. Aber für viele Anwendungsfälle gibt es mehr als einen geeigneten Lösungsweg. Kommerzieller Support z.B. durch Entought ist im Einzelfall vielleicht eine Möglichkeit um das Optimum heraus zu holen.
Am Ende muss jeder selbst wissen, ob er sich und seine Firma vollständig in die Abhängigkeit von einem us-amerikanischen Unternehmen begeben möchte oder seinen Teil zu einer offenen Gesellschaft und Wissenschaft beitragen kann. Es mag kurzfristig einen kleinen Vorteil bieten, den "shut up and take my money" Weg zu gehen.
Ich habe aber die Hoffnung, dass die Entwicklung bei Python in Bezug auf Scientific Computing weiterhin mit großen Schritten vorangeht und mutige Unternehmen und Hochschulen frühzeitig an dieser Entwicklung teilhaben und Matlab & Konsorten weiter in die Nischen gedrängt wird.
Octave sehe ich auch als obsolet an. Problematisch ist aber folgender Zusammenhang:
An Hochschulen wird Matlab gelehrt, weil es in der Industrie verwendet wird (oder der Prof. nichts anderes kann). In der Industrie wird Matlab verwendet, weil genügen Hochschulabsolventen Matlab-Kenntnisse haben. Wie durchbricht man diesen Zyklus?
Meiner Meinung nach nicht durch das Aufspalten der OpenSource-Gemeinschaft in noch ein Projekt und noch ein Projekt und noch ein Projekt (Octave, Scilab, FreeMat und jetzt Julia).
Oder anders gefragt: Was können R und Julia so viel besser als Python mit den entsprechenden Paketen aus SciPy, sodass es sich lohnt, 3 Ökosysteme auf einem Rechner zu unterhalten und 3 verschiedene Sprachen zu lernen um ein und den selben Anwendungsfall zu bearbeiten?
Der Zyklus kann ganz einfach gebrochen werden, wenn auf die Wünsche der Anwender eingegangen wird. Das wären:
- Bugfreie GUI. - Performance ohne selbst mit OpenBLAS frickeln zu müssen. - Einfache Entwicklungswerkzeuge (!)
Die noch fehlenden Algorithmen können zur Not auch selbst geschrieben werden, hier sehe ich nicht das Problem.
Viele Profs. programmieren auch C++. Der Zeitaufwand ist aber im Moment MATLAB 1 zu C/C++ 10. Für einfache Übungen entsteht da zu viel Overhead.
Habe vor wenigen Monaten versucht ein Paar GUI Bugs selbst zu beheben, da begann schon das Problem. Ein fertiges Octave Kompilat zu bekommen ist für Außenstehende nicht einfach. Die Beschreibungen sind bescheiden. Ich spreche hier nicht vom (nicht vorhandenen) Windows Kompilat sondern die Linux Variante.
Mit R und Julia habe ich nicht gearbeitet. Was MATLAB nicht kann erledigt bei mir Mathematica.
Von 404namenotfound am Di, 14. Februar 2017 um 11:53 #
Da es sich hier um ein Opensource-Projekt handelt, sollte man doch lieber erst einmal versuchen mehr Entwickler ins Boot zu bringen, anstatt einen einzigen Entwickler zu sponsoren. Zumal man dann auch besser für den Fall gewappnet ist, dass einer der Entwickler ausfällt, was immer wieder vorkommen kann.
Hast recht. Selbst wenn Jemand 100 Euro spendet wird es immer noch weniger wert sein als wenn er eine fehlende Funktion implementiert oder einen Bug löst. Die meisten Octave Nutzer werden ohnehin Programmierer sein, die so etwas können sollten.
Von 404namenotfound am Di, 14. Februar 2017 um 14:31 #
Spenden an für sich ist nicht falsch. Jeder sollte für freie Software spenden, die er kostenlos nutzen darf. Gerade dann, wenn keine Sponsoren dahinterstehen. Der Entwickler hat das sicher verdient und bereichert sich nicht unverhältnismäßig. Allerdings scheint die GNU Foundation lange Zeit Sponsor gewesen zu sein und er der einzige Entwickler mit nennenswerten Beiträgen. Warum wurde diese Zeit nicht auch genutzt mehr Leute zur Mitarbeit zu bewegen. Nur so entsteht Nachhaltigkeit und evtl. wären mehr Fehler behoben bzw. Funktionen entwickelt worden.
Die meisten Octave Nutzer werden ohnehin Programmierer sein, die so etwas können sollten.
Ach und die anderen erfolgreichen Opensource Mediaplayer, Desktopmanager etc. haben natürlich einen weit höheren Anteil an Entwicklern als ein Matlab-Klon, der eine vollwertige Programmiersprache bietet.
Octave hat zu lange auf ihrer Console herumgeritten und verpasst der CLI eine gute GUI zu verpassen. Der Hauptgrund warum die meisten Linux Anwendungen außerhalb von Spielereien unbrauchbar sind.
Programmierer wissen, dass eine ordentliche IDE einem sehr viel Debug arbeit abnehmen kann. Wir sind auch nicht in den 90er Jahren, wo man noch mit FPRINTF seine Debug Ausgaben getätigt hat.
Der scheinbar rettende Halm war das QtOctave Projekt. Die GUI ist im Moment aber eher unbrauchbar. Sogar das Setzen von Debug Punkten ist buggy.
Auch heute kämpft Octave noch mit immensen Performance Problemen. Ohne alternative BLAS Bibliotheken rechnet jeder Gameboy schneller. Der PARFOR Befehl ist nur ein Makro für ein simples FOR. Mathworks versteht seine Kunden und kitzelt aus jedem Algorithmus das letzte Stück Performance heraus. Man kann sich praktisch sicher sein, dass die gleiche Performance, egal in welcher Sprache, nur mit einem sehr hohen Programmieraufwand erreicht wird.
Wir haben Octave und Python bei uns kurz ausprobiert und dann dennoch 12.000 € je Nutzer für MATLAB samt Toolboxen ausgegeben. Das Gefälle an Performance und Produktivität ist einfach zu groß. Für Prototyping ist MATLAB unschlagbar. Vergleichen mit den Lohnkosten entsprechender Mitarbeiter ist es auch nur ein Bruchteil.
Werde aber dennoch spenden. Fehler hin, Fehler her. Konkurrenz belebt das Geschäft.
Zielgruppe: Denke das Ingenieure nicht die Zielgruppe von octave sind. Im Bildungssektor ist octave aber wirklich eine Alternative. Kostenlos und Bürokratielos kann man Schülern/Studenten "Matlab"-Syntax beibringen.
Zur Geschwindigkeit: Es ist in der Tat langsam. Wenn man große Projekte hat ist Matlab sinnvoller. Aber es gibt halt auch viele kleine Anwendungszwecke für die octave vollkommen ausreicht.
Zur GUI: Ich bevorzuge keine GUI, bin aber seit fast 20Jahre Linuxnutzer.
In Gegenteil octave4 hat eine GUI (qtoctave ist gar nicht nötig) und seitdem startet und schließt octave langsamer. Ich verwende octave oft als TR und da ist es nun mal ein Vorteil, wenn ich die Enter-Taste noch gar nicht losgelassen habe und octave schon gestartet ist
Irgenwie wird mich das Gefühl nicht los, dass hier viele einfach kommentieren, ohne wirklich Ahnung von der Materie zu haben. Es fällt doch auf wenn ein Leihe über ein Thema spricht und versucht es als Wissen zu verkaufen.
Ich habe mal im Bildungssektor gearbeitet. Da ist MATLAB ebenfalls konkurrenzlos. Die Preise fallen ggü. der kommerziellen Version auf ein Bruchteil. Eine Klassenlizenz inklusive mehrerer Toolboxen kostet teilweise weniger als eine Einzellizenz für den professionellen Einsatz. Das Jährliche Update hatte damals < 100€ gekostet. Das ist geradezu lächerlich.
Dann kommen die bugs, nicht implementierte Funktionen und die lahmarschigkeit. So etwas tut keiner seinen Studenten an. Die meisten Cracken sich MATLAB, schreiben den Code, testen ihn unter Octave und gehen mit einem "Octave" Ergebnis an die Öffentlichkeit.
Programme ohne GUI bleiben ein nutzloses Nischenprodukt. Wir sind nicht in den 90er Jahren wo so sich Jemand noch sinnvoll damit befasst.
PS:Wenn du Octave wirklich benutzt hättest, würdest du auch wissen, dass QtOctave komplett übernommen wurde um die aktuelle Octave GUI zu stellen.
Ich sehe MATLAB zum Glück ganz und gar nicht mehr konkurrenzlos. Für die meisten wissenschaftlichen Anwendungsfälle ist es freien Lösungen basiert auf Python, R oder Julia klar unterlegen.
Dementsprechend wird Octave als freie Alternative zu MATLAB auch weniger interessant.
Kommt drauf an wie du unterlegen definierst.
- Kostenmäßig definitiv
- Performance: MATLAB wird 99% schneller sein.
Da können die von dir genannten Sprachen einfach nicht mithalten. Sie sind einfach zu lahm.
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=gcc
- Community niemals. Bei kommerziellen Versionen werden Fragen von Ingenieuren und Mathematikern per Telefon beantwortet. Sie liefern Codeschnipsel und optimieren bei bedarf lahmen Code.
Die Community für die kostenfreie Version ist ebenfalls riesig.
- Erstverfügbarkeit von Algorithmen: MATLAB ist teilweise ein Jahr vor allen anderen Konkurrenten
Der einzige Vorteil sind eingesparte Kosten, die sich wiederum durch's Frickeln, Debuggen und lahmarschigen Code amortisieren.
Der Benchmark ist doch dummes Zeug und völlig irrelevant wenn nicht sogar OT.
1. Matlab selbst ist zum einen nicht mit C vergleichbar [1].
2. Die Perfomance mit Numpy ist erheblich besser als reiner Python Code. Die Syntax ist dennoch 100% Python. Weitere Pakete für Python, welche in ihrer Sparte die Performance erheblich steigern, sind Numba und PyTables. Diese Pakete müssen selbstverständlich berücksichtigt werden.
In Verbindung mit einer guten IDE (z.B. PyCharm) schreibt sich der Code unter Python fast von alleine und lässt sich vor allem vernünftig debuggen. Matlab-Anwender (und universitäre Lehrkräfte) sind immer wieder erschrocken, wie einfach es sein könnte. Gefrickelt wird mit Python also gar nicht. Im Gegenteil - mit Unittests können erstellte Funktionen abgesichert und eine optimale Codequalität auch über einen längeren Entwicklungszyklus gewahrt werden. Matlab bietet diese Funktionalität gar nicht erst an.
Von der Performance mag es bei vollständig durchoptimiertem Code möglicherweise einen Geschwindigkeitsvorteil mit dem Faktor 2-3 auf Matlabs Seite geben. In den wenigen Fällen, in denen dies relevant wäre, müsste der Programmierer aber auch in der Lage sein, dieses Potenzial heraus zu kitzeln. Dabei muss berücksichtigt werden, wie teuer die Entwicklungszeit ist (Personalkosten!). Diese ist bei Python in der Regel extrem niedrig.
Am Schluss also noch ein "Reale Welt Benchmark", bei welchem die Performancevorteile von reinem C-Code fast aufgezehrt werden [2].
Mein klarer Favorit für Scientific Computing ist demnach Python, wobei ich leider immer noch eine Simulink-Alternative vermisse - hier hat Matlab tatsächlich noch einen großen Vorteil. Ihre Argumentation lässt leider darauf schließen, dass Ihnen die Möglichkeiten von Python weitestgehend unbekannt sind, da Sie sich von scheinbar plausiblen Benchmarks in die Irre führen lassen. Geht es wirklich um die reine Performance, muss an eine Hybridlösung mit C++ gedacht werden.
[1] http://economics.sas.upenn.edu/~jesusfv/comparison_languages.pdf
[2] http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt_computer2000.pdf
Benchmarks sind das einzige greifbare. Intuition trügt öfters.
Zur ersten Referenz: In MATLAB gab es mit 2015b ein großes "Execution Engine" Update. Es ist kein MEX mehr notwendig, da es intern schon getätigt wird [1]
Deswegen lässt sich jetzt jedes M Programm auch als MEX Compilat betrachten, wenn alten Benchmarks nachgegangen wird oder die in der geplosteten Referenz. Außerdem lassen sich bei Mathworks Performance Issues angeben, die in den nächsten Versionen behoben werden. Daher ist es sehr wohl mit C vergleichbar. Hinzu kommt, dass nahezu alle Matrix Operationen intern als FORTRAN Calls realisiert sind.
Klar, Python ist in den letzten Jahren deutlich schneller geworden. Dennoch klafft bei numerischen Anwendungen eine Lücke von Faktor 10 und mehr. Wenn ein Algorithmus unter C eine Stunde braucht, wären es bei Python 10 oder mehr. Es sind nicht die 2-3 mal, selbst das wäre schon schlimm. Statt ner Stunde drei Stunden zu warten ist schon bitter bei den Lohnkosten je Stunde. Das ist leider nicht akzeptabel. Der Vorteil meines Links (Benchmarks) ist, dass jeder eine schnellere Implementierung vorschlagen kann. Da gibt es einige solche Seiten, alle geben ein einheitliches Bild ab. In den zitierten Papern ist dies nicht der Fall. Deswegen ist es weniger praxisnah.
Ich liebäugel schon lange mit Python und setze es immer dort ein wo es geht um Lizenzen zu sparen, von daher kann ich doch mitsprechen. Kann PyCharm Plots live bearbeiten? Ich hab ne IntelliJ Lizenz bin aber immer noch bei Jupyter.
"Im Gegenteil - mit Unittests können erstellte Funktionen abgesichert und eine optimale Codequalität auch über einen längeren Entwicklungszyklus gewahrt werden. Matlab bietet diese Funktionalität gar nicht erst an. Matlab bietet diese Funktionalität gar nicht erst an."
Hier noch ein Update [2]. MATLAB hat ein sehr ausgereiftes Test-Framework. Daneben gibt es Profiling, Pakettierung, Code Coverage usw..
[1] https://de.mathworks.com/products/matlab/matlab-execution-engine.html
[2] https://de.mathworks.com/help/matlab/matlab-unit-test-framework.html
Das Performance-Argument scheint die einzige wirklich greifbare Kritik zu sein und auch dann reden wir hier über Nischen bei komplexen Simulationen oder BigData-Geschichten, die lange nicht jeden betreffen. Dies als dramatisch schlimm hochzustilisieren halte ich für übertrieben, zumal Numpy das Einbinden von C++ und Fortran erlaubt. Hier macht sich dann auch der Speichervorgang auf die Platte bemerkbar, womit man letztlich wieder vergleichen kann, welche Sprache die besseren Tools für HDF5 anbietet - und ich denke, PyTables hat hier schon ziemlich effiziente Möglichkeiten zur Bearbeitung sehr großer Datenmengen.
PyCharm ist nicht für die live Bearbeitung von Plots geeignet. Dies muss die figure()-Umgebung von Matplotlib bereitstellen; dort ist in gewissen Bereichen eine live-Bearbeitung allerdings möglich. Die Community-Edition reicht eigentlich aus, außer man benötigt Tools für Datenbanken oder Web-Entwicklung. Jupyter-Notebooks lassen sich auch per PyCharm komfortabel bearbeiten.
Ein Nachteil - aber auch gleichzeitig ein Vorteil - von Python ist letztlich, dass durch die verschiedenen Module und unterschiedlichen Entwickler nicht alles aus einem Guss ist. Aber für viele Anwendungsfälle gibt es mehr als einen geeigneten Lösungsweg.
Kommerzieller Support z.B. durch Entought ist im Einzelfall vielleicht eine Möglichkeit um das Optimum heraus zu holen.
Am Ende muss jeder selbst wissen, ob er sich und seine Firma vollständig in die Abhängigkeit von einem us-amerikanischen Unternehmen begeben möchte oder seinen Teil zu einer offenen Gesellschaft und Wissenschaft beitragen kann. Es mag kurzfristig einen kleinen Vorteil bieten, den "shut up and take my money" Weg zu gehen.
Ich habe aber die Hoffnung, dass die Entwicklung bei Python in Bezug auf Scientific Computing weiterhin mit großen Schritten vorangeht und mutige Unternehmen und Hochschulen frühzeitig an dieser Entwicklung teilhaben und Matlab & Konsorten weiter in die Nischen gedrängt wird.
Octave sehe ich auch als obsolet an. Problematisch ist aber folgender Zusammenhang:
An Hochschulen wird Matlab gelehrt, weil es in der Industrie verwendet wird (oder der Prof. nichts anderes kann). In der Industrie wird Matlab verwendet, weil genügen Hochschulabsolventen Matlab-Kenntnisse haben. Wie durchbricht man diesen Zyklus?
Meiner Meinung nach nicht durch das Aufspalten der OpenSource-Gemeinschaft in noch ein Projekt und noch ein Projekt und noch ein Projekt (Octave, Scilab, FreeMat und jetzt Julia).
Oder anders gefragt: Was können R und Julia so viel besser als Python mit den entsprechenden Paketen aus SciPy, sodass es sich lohnt, 3 Ökosysteme auf einem Rechner zu unterhalten und 3 verschiedene Sprachen zu lernen um ein und den selben Anwendungsfall zu bearbeiten?
Der Zyklus kann ganz einfach gebrochen werden, wenn auf die Wünsche der Anwender eingegangen wird. Das wären:
- Bugfreie GUI.
- Performance ohne selbst mit OpenBLAS frickeln zu müssen.
- Einfache Entwicklungswerkzeuge (!)
Die noch fehlenden Algorithmen können zur Not auch selbst geschrieben werden, hier sehe ich nicht das Problem.
Viele Profs. programmieren auch C++. Der Zeitaufwand ist aber im Moment MATLAB 1 zu C/C++ 10. Für einfache Übungen entsteht da zu viel Overhead.
Habe vor wenigen Monaten versucht ein Paar GUI Bugs selbst zu beheben, da begann schon das Problem. Ein fertiges Octave Kompilat zu bekommen ist für Außenstehende nicht einfach. Die Beschreibungen sind bescheiden. Ich spreche hier nicht vom (nicht vorhandenen) Windows Kompilat sondern die Linux Variante.
Mit R und Julia habe ich nicht gearbeitet. Was MATLAB nicht kann erledigt bei mir Mathematica.
Da es sich hier um ein Opensource-Projekt handelt, sollte man doch lieber erst einmal versuchen mehr Entwickler ins Boot zu bringen, anstatt einen einzigen Entwickler zu sponsoren. Zumal man dann auch besser für den Fall gewappnet ist, dass einer der Entwickler ausfällt, was immer wieder vorkommen kann.
Hast recht. Selbst wenn Jemand 100 Euro spendet wird es immer noch weniger wert sein als wenn er eine fehlende Funktion implementiert oder einen Bug löst. Die meisten Octave Nutzer werden ohnehin Programmierer sein, die so etwas können sollten.
Spenden an für sich ist nicht falsch. Jeder sollte für freie Software spenden, die er kostenlos nutzen darf. Gerade dann, wenn keine Sponsoren dahinterstehen. Der Entwickler hat das sicher verdient und bereichert sich nicht unverhältnismäßig.
Ach und die anderen erfolgreichen Opensource Mediaplayer, Desktopmanager etc. haben natürlich einen weit höheren Anteil an Entwicklern als ein Matlab-Klon, der eine vollwertige Programmiersprache bietet.Allerdings scheint die GNU Foundation lange Zeit Sponsor gewesen zu sein und er der einzige Entwickler mit nennenswerten Beiträgen. Warum wurde diese Zeit nicht auch genutzt mehr Leute zur Mitarbeit zu bewegen. Nur so entsteht Nachhaltigkeit und evtl. wären mehr Fehler behoben bzw. Funktionen entwickelt worden.