Forum: Digitale Signalverarbeitung / DSP Echtzeit: Matlab vs Python vs Octave vs SageMath vs


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,

Meine Programmiererfahrung:
HTML, C, Pure Data

Nun arbeite ich in letzter Zeit intensiv nur mit PD, für Echtzeitaudio.

Dabei treffe ich natürlich bei komplexeren Vorhaben immer wieder auf 
Matlab und Python.

Weil es Schnittstellen zwischen PD und Beiden gibt bzw. das Eine in das 
Andere einbetten kann, und mir die vorhandenen Tools und Bibliotheken 
sehr mächtig erscheinen meine Frage:
In was wäre es am sinnvollsten mich einzuarbeiten?

Grundsätzlich bevorzuge ich klar freie Entwicklungsumgebungen, um 
zumindest bei meinen über Jahre wachsenden Projekten weitgehend 
unabhängig vom Kapitalismus zu sein.
Allerdings möchte ich beim Neu Lernen das mächtigste Tool wählen, auch 
perspektivisch in die Zukunft gesehen.
Bei Pure Data vs. MaxMsp bin ich froh PD genommen zu haben, da dies frei 
ist letztlich in nichts nachsteht, auch wenn das Marketing und bunte GUI 
von Max das als Außenstehende zunächst vermuten lässt.
Zudem ist die Community in PD relativ stark.

Wie ist das in Matlab vs Python?
Wenn man alles in Python macht, äugt man immer wieder neidisch zu Matlab 
rüber?

In anderen Threads lese ich, dass Matlab in Teilen unlogisch sei und 
Ecken und Kanten habe, über die sich geärgert wird?
Und Matlab sei nicht wirklich zum Programmieren gedacht?

Das ist ja bei Python anders.

Ist Python schlanker?

Kann ich Matlabbibliotheken schnell in Python übertragen?

GUI Entwicklung und i/o Schnittstellen würde ich weiterhin in anderen 
Umgebungen machen, wie PD, OpenFrameworks ect.

Es geht mir bloß um sehr aufwändige Rechnungen, wie komplexe Filter, KI 
usw. wo mir Tools und Bibliotheken, die von Ingenieuren standartmäßig 
verwendet werden, mächtiger erscheinen.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Wie ist das in Matlab vs Python?
>Wenn man alles in Python macht, äugt man immer wieder neidisch zu Matlab
>rüber?

Ich verwende schon seit Jahren Matlab bzw. wenn es eng mit den Lizensen 
wird, Octave. Ich finde es besser und schneller zu bedienen als Python.

Python hat den Vorteil, dass es frei ist und man auch viele Sachen 
außerhalb der Numerik machen kann. Allerdings muss man sagen, dass der 
größte Teil der KI-Welt Python verwendet und viele große KI-Bibliotheken 
auf einem Python-Interface basieren.

Außerdem gibt es im Bereich Matlab auch Simulink, was besonders gut für 
den Reglerentwurf geeignet ist.

Aber wie gesagt, Matlab ist für die Numerik gemacht und damit noch etwas 
bequemer als Python.

von jan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Matlab kann man mittlerweile hervorragend klassenbasiert programmieren, 
inklusive Vererbung, Events, tollen Argument Validierern etc. Mathworks 
bohrt das Ganze im Moment ordentlich auf.
Auf gibt es in Matlab Schnittstellen zu .NET, Python, C und C++. Und 
zwar in beide Richtungen.
ML hat eine hervorragende Doku.

Nachteil: Teuer. Und man möchte jedes Jahr verlängern, weil neue 
Features hinzugekommen sind. Für jeden Kleinscheiß brauchst du ne neue 
Toolbox oder musst basteln (geht dank ML Fileexchange und vor allem der 
Python Integration ganz gut -> Statistik machen wir in Matlab nur noch 
über Python).

Die ML Syntax ist einfach noch ein vielfaches besser und einfacher als 
Python.

Ggf. ist auch Julia was für dich? Habe ich aber selbst noch nicht 
ausprobiert.

Achso, Simulink ist konkurrenzlos.

Octave ist für einfaches Zeugs in Ordnung, kann aber essentielle 
Datentypen wie tables (== Pandas Dataframes), datetime Objekte und echte 
Strings nicht.

von Max H. (metalmax83)


Bewertung
0 lesenswert
nicht lesenswert
Da muss ich ganz klar für Python votieren. Neben dem Open-Source-Vorteil 
ist die Community auch noch um einiges größer. Meinem Vorredner muss ich 
bzgl. einer Aussage widersprechen: die Syntax ist doch bei Matlab nicht 
einfacher, als bei Python! Besser lesbaren Code als mit Python bekommt 
man praktisch bei keiner anderen Sprache. Außerdem fängt Matlab bei 1 an 
zu zählen, statt bei 0 wie der Rest der Welt. Alleine das ist ein No-Go 
;-)

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Python ist halt eine richtige Programmiersprache. Das heißt, hier 
arbeiten seit 30 Jahren erfahrene Leute allein und ausschließlich daran, 
eine ordentliche Sprache zu bauen. Ich finde, das fällt auch sehr stark 
(positiv) auf, wenn man das Ergebnis mit den Sprachen vergleicht, die 
Matlab oder Octave anbieten.

von Alter Knacker (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Was soll denn die Frage "Echtzeit" im Zusammenhang mit der 
Programmierun? MATLAB läuft nirgens in Echtzeit, allerhöchstens daraus 
erzeugter Code.

von Hans W. (Firma: Dipl.-Ing. Johann Maximilian W) (hans-)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Python ist halt eine richtige Programmiersprache. Das heißt, hier
> arbeiten seit 30 Jahren erfahrene Leute allein und ausschließlich daran,
> eine ordentliche Sprache zu bauen

Meiner Erfahrung nach bricht bei Python öfter mit seinen Interfaces.

Beispielsweise geht gerade die GUI vom Joulescope (das ist ein 
Poweranalyzer) nicht mit Python 3.8, weil wieder irgendwelche 
Sprachdetails geändert wurden.

Das passiert meiner Erfahrung leider viel öfter bei Python/NodeJS/... 
als in "alteingesessenen" Sprachen/Packages.

Übrigens gibt's noch SciLab. Das ist auch nicht schlecht aber im 
Gegensatz zu Octave Syntax mäßig anders als Matlab.
Scilab kommt mit XCos das angeblich Simulink ähnlich ist. Ehrlich gesagt 
habe ich das noch nie gestartet...

73

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Hans W. schrieb:
> Beispielsweise geht gerade die GUI vom Joulescope (das ist ein
> Poweranalyzer) nicht mit Python 3.8, weil wieder irgendwelche
> Sprachdetails geändert wurden.

Mh, also wenn ich mal so kurz rumlese, ist das nicht richtig 
wiedergegeben so. Das war kein Bruch in einem Interface oder Änderung 
eines Sprachdetails seitens Python, sondern
1. in einem 3rd-Party-Package (pyside), was mit Python als Sprache 
erstmal nichts zu tun hat, und
2. eine Regression, die als "Prio 1" klassifiziert und innerhalb einiger 
Tage repariert wurde, und keine absichtliche Änderung.

Ein Bruch in einem Interface der Sprache wäre sowas wie die 
String-Encoding-Änderungen in Python 2 -> Python 3.

Warum ist das ein Unterschied: in dem von dir beschriebenen Fall wird 
vom Downstream erwartet, dass er seine Software umbaut, um mit der neuen 
Version kompatibel zu sein. Im vorliegenden Fall repariert der Upstream 
das, und die Benutzer des Interfaces müssen lediglich ein paar Tage 
warten und z.B. die alte Version weiterbenutzen.

: Bearbeitet durch User
von Joggel E. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
Erst mal sollte benannt werden was Echtzeit denn bedeutet resp in 
welcher Anzahl ASM Instruktionen sich die Reaktionszeit bewegen darf.
Wnn du alle Paar minuten ein Relais anziehen musst und einen 400MHz 
Boliden hast ist das etwas anderes wie einen Stromspar Tiny fuer 
Videostreams..

von Daniel -. (root)


Bewertung
0 lesenswert
nicht lesenswert
ich denke, matlab ist vendor lockin, so wie apple.
nimm das was deine direkte umgebung verwendet.
falls du in einem jahr umsteigst, sind die konzepte die gleichen
die sind wichtiger

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
Moin,

sobald man sich aus der DSP-Box wegbewegt und komplexe Sachen 
regresstesten muss, wird's IMHO mit Python deutlich leichter.
Gerade bei Bildverarbeitung macht Matlab jetzt nicht die beste Nummer.

Und Simulink flog auch schon mehrmals in die Ecke und wurde einfach 
durch ein Python-Modell ersetzt (dank HLS-Erweiterungen und Transfer per 
MyHDL laesst sich das elegant in synthetisierbare Hardware giessen).
Es ist immer das gleiche, entweder hat man schnell ein Ergebnis mit der 
Kaufware und es tut, oder man debuggt ewig und ist mit einer eigenen 
Toolbox schliesslich effizienter.

von Md M. (Firma: Potilatormanufaktur) (mdma)


Bewertung
1 lesenswert
nicht lesenswert
Daniel -. schrieb:
> ich denke, matlab ist vendor lockin

Erstens das, das würde mich persönlich stören. Aber zweitens habe ich 
Matlab auch noch nie außerhalb von Hochschulen angetroffen. Möglich, 
dass ich aber auch einfach nur im falschen Bereich tätig bin. Aber wie 
verbreitet ist Matlab jenseits von Uni und co eigentlich wirklich?

: Bearbeitet durch User
von Dreister Frager (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
tom schrieb:
> Guten Abend,
>
>
>
> Wie ist das in Matlab vs Python?
> Wenn man alles in Python macht, äugt man immer wieder neidisch zu Matlab
> rüber?
>
> In anderen Threads lese ich, dass Matlab in Teilen unlogisch sei und
> Ecken und Kanten habe, über die sich geärgert wird?
> Und Matlab sei nicht wirklich zum Programmieren gedacht?


Nein die Leute sind zu doof Matlab zu verstehen!

> Das ist ja bei Python anders.
>
> Ist Python schlanker?
>
> Kann ich Matlabbibliotheken schnell in Python übertragen?

Ja z.B bei Anaconda
>
> GUI Entwicklung und i/o Schnittstellen würde ich weiterhin in anderen
> Umgebungen machen, wie PD, OpenFrameworks ect.
>
> Es geht mir bloß um sehr aufwändige Rechnungen, wie komplexe Filter, KI
> usw. wo mir Tools und Bibliotheken, die von Ingenieuren standartmäßig
> verwendet werden, mächtiger erscheinen.

von Jan K. (jan_k)


Bewertung
0 lesenswert
nicht lesenswert
Md M. schrieb:
> Aber wie
> verbreitet ist Matlab jenseits von Uni und co eigentlich wirklich?

Die gesamte Auto-, Medizin- und Luftfahrtindustrie und viele Läden, die 
mit Regelungstechnik (Antriebe, Pumpen, ...) zu tun haben nutzt 
Matlab/Simulink für "model based development" alias 
Seriencodegenerierung aus Simulink Modellen. Du bekommst die 
Zertifizierung gleich mit, kannst SiL/HiL/PiL usw machen, hast 
Requirement Management mit dabei und so weiter. Zahlst halt dann 30-40 
k€ pP alle 3 Jahre, es sei denn man ist groß genug um Volumenverträge zu 
bekommen.

Wir haben keine Code Generierung in der Firma, nutzen aber Matlab und 
Simulink für Datenanalyse (Messdatenauswertung, Statistik und ganz 
besonders gute und schnelle Grafiken), Machine Learning, Simulation all 
unserer Produkte (Sensor(en) + Mikrocontroller + komplexe 
Kalibrieralgorithmen) für schnelle Anpassung an die Kundenwünsche, 
Ausprobieren von neuen Konzepten und Validierung (nicht Erzeugung) von 
C-Seriencode. Geschriebene C# Interfaces zur Kommunikation können mit 
minimalem Aufwand eingebunden werden, ebenso C und C++. Und auch Python 
(z.B. kann man eine Optimierung in Python machen, und ohne Umwege die 
Daten in Matlab weiterverarbeiten). Sogar Kalibrierprogramme sind in 
Matlab geschrieben (mit dem Matlab Compiler -> wird zu einer exe). Da 
kann man am Arbeitsplatz 1 zu 1 das selbe nachspielen und in jeder Zeile 
debuggen. Oder mal schnell ein paar Einstellungen im µC ändern (über ein 
definiertes Interface), einfach in der Kommandozeile, inkl. Tab 
Vervollständigung. Geht mittlerweile in VS über das "immediate window" 
auch, aber nicht so gut.

Daniel -. schrieb:
> ich denke, matlab ist vendor lockin, so wie apple.
Stimmt, und geht mir auch auf den Sack. Ist aber in manchen Bereichen 
alternativlos (bei uns noch nicht unbedingt, bei der oben genannten Code 
Generierung quasi schon).
Aber mal als Vergleich, welche (professionellen) Tools haben keinen 
Vendor Lockin? Altium/OrCad? Ansys? SolidWorks und co? Mathematica? 
µVision/IAR? Microsoft Office? ;)
Muss man nicht mögen, ist aber Realität.

Dafür bekommst du bei Matlab prompten Support (24 h), wenn wirklich mal 
was klemmen sollte (auch inhaltlich, am Code) und bekommst die beste 
Doku, die du jemals gesehen hast. Das ist beides viel wert.

Sven B. schrieb:
> Python ist halt eine richtige Programmiersprache. Das heißt, hier
> arbeiten seit 30 Jahren erfahrene Leute allein und ausschließlich daran,
> eine ordentliche Sprache zu bauen

Ich würde sagen, auch Matlab ist mittlerweile eine vollwertige 
Programmierspache. Da arbeiten verdammt viele Informatiker. Die 
Entwicklung des aktuellen Grafik Subsystems hat über 10 Jahre gedauert 
(ich weiß, das ist nicht unbedingt ein pro Argument, zeigt aber die 
Komplexität). Es gibt Klassen, Vererbung, Interfaces, reference und 
value types, du kannst mit zig externen Programmiersprachen direkt 
kommunizieren (und anders rum!). Die meisten aktuellen Sprachfeatures 
sind selbst als Klasse implementiert, man hat also sehr ähnliche 
Konzepte mit gleicher Nomenklatur (nicht wie bei Python, mal sind es 
getter/setter, mal properties, dann mal Funktionen und jedes Paket hat 
eigene Konventionen). Du willst die Eigenschaften einer Linie (plot) 
ändern? Easy, nimm das Objekt und schau durch die Properties. Das selbe 
gilt für die Achsen, die figure selbst oder die gesamte GUI. Oder für 
tables (python pandas datastore), oder für datetime Objekte usw usf.
Es ist auch schneller geworden, es gibt JIT Compiler, eine (schon immer) 
extrem starke Vektorisierung und das performanteste Plotting System 
aller Sprachen die ich bisher gesehen habe.

Hauptprobleme: Multithreading nicht vorhanden (nur über C#/C++ threads 
oder über Timer callbacks), man braucht für jeden Scheiß eine Toolbox, 
Java Unterbau (mit unperformanten Timern ;)). Aber auch hier - Aufgaben, 
bei denen es primär um den Kontrollfluss oder um viele kleine 
Datenpakete geht werden einfach nach C# ausgelagert und im eigenen 
Thread geparkt und ab und zu synchronisiert), große (vektorisierbare) 
Rechnungen, Grafik etc. wird dann wieder in ML gemacht.

Es ist alles nicht perfekt, aber bisher die beste Sprache für unsere 
Vorhaben.

Wenn mir jemand für all die genannten Dinge freie Äquivalente nennen 
kann steige ich sofort um. Meine Chef würds freuen.

Martin S. schrieb:
> Und Simulink flog auch schon mehrmals in die Ecke und wurde einfach
> durch ein Python-Modell ersetzt (dank HLS-Erweiterungen und Transfer per
> MyHDL laesst sich das elegant in synthetisierbare Hardware giessen).
> Es ist immer das gleiche, entweder hat man schnell ein Ergebnis mit der
> Kaufware und es tut, oder man debuggt ewig und ist mit einer eigenen
> Toolbox schliesslich effizienter.

Das interessiert mich sehr, magst du da mal etwas ausführen?


Max H. schrieb:
> Meinem Vorredner muss ich
> bzgl. einer Aussage widersprechen: die Syntax ist doch bei Matlab nicht
> einfacher, als bei Python!

Kommt drauf an bei was. Bei der Ablaufssteuerung/Iterieren etc. 
vielleicht. Nicht aber bei (und darauf kommt es [bei uns] an) der 
linearen Algebra.

Tu mir mal bitte den Gefallen und lass diese Tabelle auf dich wirken: 
https://cheatsheets.quantecon.org/

Und jetzt überlege, du starrst den halben Tag auf Algorithmen, in denen 
irgendwelche Arrays und Matrizen vereiert werden. Und dann vergleich mal 
Python mit Matlab oder Julia ;)

Die Diskussion, dass Arrays bei 1 starten (weiß nicht mehr ob das in 
diesem Thread war) ist auch Geschmackssache. Die Mutter der mathematisch 
angelehnten Sprachen war/ist Fortran, da hat halt der Index bei 1 
gestartet.

Upppsi, wall of text, sorry :)

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Jan K. schrieb:
> Tu mir mal bitte den Gefallen und lass diese Tabelle auf dich wirken:
> https://cheatsheets.quantecon.org/

Hmm, also ich muss sagen, für mich liest sich die Matlab-Variante nicht 
wesentlich einfacher. Sperrig sind bei Python vor allem die 
Namespace-Präfixe, aber wenn du die nicht willst, ändere einfach den 
Import entsprechend oder lege Aliase an (arr = np.array oder so). Einige 
Dinge sind in der Python-Variante auch einfach suboptimal 
aufgeschrieben.

von Jan K. (jan_k)


Bewertung
0 lesenswert
nicht lesenswert
Hi,
A = [1; 2; 3]
vs 
A = np.array([1, 2, 3]).reshape(3, 1)

finde ich z.B. schon recht hart, auch mit prefix für das numpy array. 
Ebenso bei den Matrix/Vektor Multiplikationen.
Tatsächlich sieht es aber mit dem @ Operator schon etwas besser aus, 
(ist aber tatsächlich noch recht neu, von 2018 oO): 
https://www.python.org/dev/peps/pep-0465/
S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r)
vs
S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)

ist schon etwas besser, aber auch nicht schön oder?

nur zu Info, in ML wäre es
S = (H*b-r)'*inv(H*V*H')*(H*b-r)
oder besser
S2 = (H*b-r)'*((H*V*H')\(H*b-r))
Kann ich zumindest sofort lesen auch ohne Leerzeichen. Oben sind ein 
paar viele @ drin ;)
Man gewöhnt sich aber sicherlich und es gibt Schlimmeres, daher war das 
jetzt auch meine letzte Aussage zu dem Thema, gibt Aspekte die sind 
wichtiger.

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Ich brauche ziemlich selten Spaltenvektoren. Wenn ich mehr als 2 
brauchen würde, in dem Programm, würde ich einfach
>>> def colvec(*args): return np.array([*args]).reshape(1, -1)
... 
>>> colvec(1, 2, 3)
array([[1, 2, 3]])
schreiben. Das ist hervorragend lesbar ... die halbe Zeile rechtfertigt 
keine andere Sprache ;)
Die @s sind nicht super hübsch, das stimmt. Gibt aber echt schlimmeres.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Jan K. schrieb:
> Martin S. schrieb:
>> Und Simulink flog auch schon mehrmals in die Ecke und wurde einfach
>> durch ein Python-Modell ersetzt (dank HLS-Erweiterungen und Transfer per
>> MyHDL laesst sich das elegant in synthetisierbare Hardware giessen).
>> Es ist immer das gleiche, entweder hat man schnell ein Ergebnis mit der
>> Kaufware und es tut, oder man debuggt ewig und ist mit einer eigenen
>> Toolbox schliesslich effizienter.
>
> Das interessiert mich sehr, magst du da mal etwas ausführen?

Mal eben einen HLS-Thread hier ausgegraben, da ist bisschen was 
angerissen:
Beitrag "High Level Synthese aus C Code Spielerei oder ernste Anwendungen?"

Im Prinzip schreibt man sich seinen Algorithmus einmal und 'dekoriert' 
ihn mit einer Generatorklasse, die je nach Aufruf und Kontext 
unterschiedliche Sachen damit macht:

- Ganz normal als Python-Script ausfuehren
- Datentypen uebergeben, die ein Simulationsmodell fuettern, Fehler 
mitfuehren, optimale Bitbreiten berechnen, etc.
- Synthesefaehige Konstrukte erzeugen
- Code fuer einen Vektor-DSP (fixe Multiplikatoren) generieren

Damit kann man dann dieselbe Modellierung mit unterschiedlichen 
Stilausfuehrungen (a la style sheet) verwenden und gegeneinander testen.
Klassische Entwicklung: Fixpunkt-Datentypen definieren (von 
MyHDL-Klassen ableiten), Transformation in Verilog/VHDL ausgeben, mit 
Simulator numerisch gegentesten.
Per yosys-Python-API geht auch direkte Synthese in abstrakte 
DSP-Elemente oder Vendor-Primitiven, mit deutlich weniger Schreibarbeit 
als mit den entsprechenden C++-HLS-Frameworks.
Und die Test-Umgebungen (unittest, py.test) und Jupyter-Notebooks sind 
ja vermutlich bekannt. Unter Codename 'jupyosys' ist bisschen etwas im 
Gange, siehe https://hackaday.io/project/171216-jupyosys.

von dieter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jan K. schrieb:
> Hi,A = [1; 2; 3]
> vs
> A = np.array([1, 2, 3]).reshape(3, 1)

Also das finde das als Python User ein ziemlich unsinniges Beispiel. Wer 
braucht denn solche Pseudo 2D Arrays? Ein 1d Array reicht hier völlig... 
nur weil es in Matlab kein 1d array gibt...
Falls doch mal so ein Pseudo 2D array gebraucht wird löst Python das 
ganz elegant mit newaxis.

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
Jan K. schrieb:
> A = [1; 2; 3]
> vs
> A = np.array([1, 2, 3]).reshape(3, 1)

So schreibt man das in NumPy auch nicht, sondern so:

A = np.matrix([1, 2, 3]).T

oder (insbesondere für Umsteiger von Matlab) so:

A = np.matrix('1; 2; 3')

In NumPy muss unterschieden werden zwischen n-dimensionalen Arrays und
Matrizen. Da in der linearen Algebra Vektoren Sonderfälle von Matrizen
sind, sollte man in NumPy auch sie als Matrix anlegen.

Die Erstellung von Matrizen oder Vektoren mit vorgegebenen Elementen
geschieht relativ selten, weswegen man auch die Funktion np.matrix nur
selten benötigt. Verwendet man sie dennoch häufiger (bspw. während der
Lernphase), kann man sich mit

M = np.matrix

eine Abkürzung definieren, so dass die obigen Beispiele zu

A = M([1, 2, 3]).T

und

A = M('1; 2; 3')

zusammenschrumpfen.

Jan K. schrieb:
>  S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)
>
> ist schon etwas besser, aber auch nicht schön oder?
>
> nur zu Info, in ML wäre es
>
>  S = (H*b-r)'*inv(H*V*H')*(H*b-r)

Dein Python-Beispiel erscheint nur deswegen etwas langatmig, weil du das
"beta" ausgeschrieben und viele Leerzeichen eingefügt hast. Sind H, V, r
und b vom Typ np.matrix (was in reinen LA-Anwendungen immer der Fall
sein sollte), schreibt sich die obige Anweisung ohne Leerzeichen so:

S = (H*b-r).T*(H*V*H.T).I*(H*b-r)

Damit dein Matlab-Beispiel wirklich äquivalent ist, musst du noch die
'-Operatoren durch .' ersetzen:

S = (H*b-r).'*inv(H*V*H.')*(H*b-r)

Jetzt ist der Code in Matlab sogar ein Zeichen länger als in NumPy ;-)

Ich würde dem Ausdruck aber der besseren Lesbarkeit wegen sowohl in
Python als auch in Matlab Leerzeichen um die binären Operatoren gönnen,
was am Vergleich aber nichts ändert.

Die einstelligen Matrix-Operatoren erscheinen mir in NumPy etwas
durchgängiger zu sein als in Matlab, aber das ist Geschmackssache:

Mathematik    NumPy      Matlab
                       
    A⁻¹        A.I       inv(a)
    Aᵀ         A.T         A.'
    Aᴴ         A.H         A'  

Dafür, dass die Matlab-Syntax speziell auf Lineare Algebra optimiert
wurde (Matlab war ursprünglich ja ein reines LA-Tool) und Python eine
universelle Programmiersprache ist, die auch für LA eingesetzt werden
kann, finde ich die Python/NumPy-Syntax selbst in LA-Anwendungen nicht
unelegant, auch wenn hier Matlab teilweise seine Vorzüge hat.

von Patrick B. (p51d)


Bewertung
2 lesenswert
nicht lesenswert
Mhm, es haben beide Tools ihre Berechtigung:
Ich habe mit beiden schon von Schulprojekten bis zu fertigen 
Industrie-Projekten gemacht.
Über Syntax etc. kann man streiten. Ich finde mit etwas offenem Geiste 
sind beide gut beherrschbar. Und wenn man sich darin auskennt, kann man 
auch über Syntax-Streitigkeiten hinwegsehen. Octave setze ich nur zur 
Not ein, aber im Prinzip funktioniert es ähnlich wie Matlab ohne 
Simulink. Wobei mein persönlicher Favorit zwischen den beiden Matlab 
ist.

Pro Matlab:
- Super mit kommentieren und dokumentieren (automatische PDF reports 
erstellen)
- Sehr gute Hilfestellung in der Doku
- Simulink ist mit Abstand das beste was ich im Bereich Regler-Entwurf, 
DSP, oder sogar FPGA gesehen habe mit den Analysen-Tools und "Hardware 
In the Loop"
- Code-Generatoren für Hardware
- von vielen Herstellern Plugins für Hardware

Con Matlab:
- Teuer, wobei die Preise in den letzten Jahren je nach Toolbox massiv 
gesunken sind

Pro Python:
- In der KI-Welt absolute Nummer 1 (sehr breite Unterstützung von 
Neuronalen Netzen, Tensorflow, Constraint Solvers wie OR-Tool von 
Google, "einfacher" Zugang zu Hardware-Beschleuniger oder Rechenzentren 
wie Googles Colab.).
- Weit verbreitet.
- Durch die grosse Verwendung in der KI-Welt gibt es sehr gute 
Daten-Analyse Bibliotheken (z.B. Pandas)
- Man kann praktisch alles wie in Matlab machen. Als "Rechner-Tool" 
gehen beide gleich gut.

Con Python:
- Wenn man von "kompilierten" Hochsprachen kommt, ist das Verhalten von 
Python manchmal etwas gewöhnungsbedürftig. Aber da kommt man schnell 
rein
- KI Projekte lassen sich nur auf Umwegen in eine entsprechende Hardware 
exportieren (oftmals C oder C++). Einen VHDL/Verilog Generator gibt es 
vielleicht, habe ich aber bis jetzt noch nicht verwendet.


Eigentlich kannst du bei den beiden Tools (meiner Meinung nach) nicht 
falsch liegen. Es kommt ganz darauf an, wo du deine Ziele siehst.

: Bearbeitet durch User
von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
> - Wenn man von "kompilierten" Hochsprachen kommt, ist das Verhalten von
> Python manchmal etwas gewöhnungsbedürftig. Aber da kommt man schnell
> rein

Der groesste Knackpunkt ist wohl, dass nicht immer 100% augenscheinlich 
ist, ob die Zuweisung jetzt eine Referenz auf X oder eine Kopie/Instanz 
von X ist und manche externe C-Module das noch inkonsistenter handhaben.

> - KI Projekte lassen sich nur auf Umwegen in eine entsprechende Hardware
> exportieren (oftmals C oder C++). Einen VHDL/Verilog Generator gibt es
> vielleicht, habe ich aber bis jetzt noch nicht verwendet.

Gibt es einiges an 'basic' Frameworks (vorneweg MyHDL und nmigen) zur 
Auswahl, aber betr. KI duerften sich die 'fertigen' Super-Frameworks im 
stealth-mode befinden, wer nicht ins gemachte Nest einsteigen kann, 
strickt typischerweise selber.
Was gut geht sind einfache Pipelines die irgendwas rechnen, wie dicke 
Matrizen oder Transformationen wie FFT, DCT, Wavelet, etc.

Bei Simulink ist mir regelmaessig aufgefallen, dass eine Unmenge an Code 
generiert wird, der nicht benutzt wird. War allerdings auf einem DSP. 
Aber: von der Coverage her u.U. problematisch.
Fuer mich ist bei den ganzen Generatoren immer no-go, wenn sich die 
ausgespuckte HDL fuer den Transfer schlecht oder gar nicht simulieren 
laesst (weil verstuemmelt oder verschluesselt).
Wuerde mich aber mal interessieren, ob sich das gebessert hat, meine 
letzte Verbrennung an der Herdplatte ist >10 jahre her.

von John Doe (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> In NumPy muss unterschieden werden zwischen n-dimensionalen Arrays und
> Matrizen. Da in der linearen Algebra Vektoren Sonderfälle von Matrizen
> sind, sollte man in NumPy auch sie als Matrix anlegen.


Nein. In der linearen Algebra ist ein Vektor ein Element eines 
Vektorraums. Eine Matrix im Allgemeinen nicht. Eine Matrix kann aber ein 
Vektor sein.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Hans W. schrieb:
> Sven B. schrieb:
>> Python ist halt eine richtige Programmiersprache. Das heißt, hier
>> arbeiten seit 30 Jahren erfahrene Leute allein und ausschließlich daran,
>> eine ordentliche Sprache zu bauen
>
> Meiner Erfahrung nach bricht bei Python öfter mit seinen Interfaces.

Die letzten größeren Änderungen gab es beim Wechsel von Version 2 auf 
Version 3.

> Beispielsweise geht gerade die GUI vom Joulescope (das ist ein
> Poweranalyzer) nicht mit Python 3.8, weil wieder irgendwelche
> Sprachdetails geändert wurden.

Das lag nicht an Python, sondern an einer externen Bibliothek namens 
PySide, die Python-Bindings für das bekannte UI-Framework Qt 
bereitstellt. Mit diesem simplen Patch [1] wurde das Problem behoben; 
wie man sieht, geht es dort lediglich darum, daß für Python-Versionen 
vor 3.8 die PySide-Version 5.13.2 und für Versionen ab Python 3.8 
mindestens die PySide-Version 5.14.2.1 erforderlich ist. Das ist also 
nichts, das es in anderen Umgebungen nicht auch oft genug gibt... sich 
aber mit virtualenv bzw. venv für Python besonders elegant lösen läßt.

> Das passiert meiner Erfahrung leider viel öfter bei Python/NodeJS/...
> als in "alteingesessenen" Sprachen/Packages.

Bitte entschuldige, Python gibt es seit mehr als 28 Jahren und ist daher 
sicher kein "Newcomer" mehr...

[1] 
https://github.com/jetperch/pyjoulescope_ui/commit/13566a2bc36a8e7b46a9b6c575183c6e3628383b

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Jan K. schrieb:
>> Tu mir mal bitte den Gefallen und lass diese Tabelle auf dich wirken:
>> https://cheatsheets.quantecon.org/
>
> Hmm, also ich muss sagen, für mich liest sich die Matlab-Variante nicht
> wesentlich einfacher. Sperrig sind bei Python vor allem die
> Namespace-Präfixe, aber wenn du die nicht willst, ändere einfach den
> Import entsprechend oder lege Aliase an (arr = np.array oder so). Einige
> Dinge sind in der Python-Variante auch einfach suboptimal
> aufgeschrieben.

Ja, und: das meiste, was ich in dem Cheatsheet sehe, basiert direkt auf 
numpy. Aber es gibt natürlich modernere Frameworks, die auf numpy 
aufsetzen, namentlich scipy, Pandas und das kompatible Modin, sowie 
Blaze...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.