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.
>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.
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.
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
;-)
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.
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
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.
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..
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
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.
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?
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.
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 :)
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.
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/
1
S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r)
2
vs
3
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
1
S = (H*b-r)'*inv(H*V*H')*(H*b-r)
2
oder besser
3
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.
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.
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.
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.
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:
1
A = np.matrix([1, 2, 3]).T
oder (insbesondere für Umsteiger von Matlab) so:
1
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
1
M = np.matrix
eine Abkürzung definieren, so dass die obigen Beispiele zu
1
A = M([1, 2, 3]).T
und
1
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:
1
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:
1
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:
1
Mathematik NumPy Matlab
2
3
A⁻¹ A.I inv(a)
4
Aᵀ A.T A.'
5
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.
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.
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.
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.
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
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...
Patrick B. schrieb:> Einen VHDL/Verilog Generator gibt es> vielleicht, habe ich aber bis jetzt noch nicht verwendet.
Ich schon und der leidet an der gleichen Krankheit wie der MATLAB-HDL
Coder: Es fehlen die Input-Möglichkeiten für 2D/3D-Strukturen, Vorgaben
für pipelines und etliches mehr, damit das tool einem einige Arbeiten
beim Erstellen solcher Strukturen abnehmen könnte. Letztlich generiert
es auch nur eine Standardhardware, die dann mit Ablauf gefüttert wird,
um zu agieren.
Ich habe mal spasseshalber einige Wellenformengeneratoren formuliert und
bauen lassen und kriege auch für einfache Strukturen, die in VHDL aus
ein paar Registern bestehen, massive Konstrukte ausgeworfen, die viel
Silizium fressen und sich mangels eine optimierten Ansatzes auch nicht
mit Synthestricks wie physical resynthesis optmieren lassen.
Diese Tools nehmen einem letztlich das Denken nicht ab.
Thread beobachten
Seitenaufteilung abschalten