Hallo, kleinere Berechnungen programmiere ich beruflich in Matlab. Leider kann ich diese nicht problemlos an Kollegen weitergeben - schon alleine wegen der Lizenz. In Excel sind kleine Berechungen möglich, aber meist alles andere als intiutiv. Wie handhabt ihr das so? Erstellt ihr richtige EXE z.B. in Visual Studio?
octave ist die open source mathlab sw. Solltest du mal austesten.
Je nach Zielsetzung Python oder QT/C++. Für Datei-Operationen und dgl. auch Shell-Skript.
ich komme privat ganz gut mit Linux klar und kenne dort die Tools wie sed, awk, perl... Kommt natürlich kein Kollege mit klar. Außerdem muss ich für jedes Programm die IT bitten mir die Freigabe zu geben das zu installieren. Deswegen kann ich momentan nur Perl nutzen. Als Dateimanager mit besserer Umbennung, Filesuchen, etc. Total Commander und Notepad++ als Editor. Berechnungen muss ich in Excel durchführen, wobei ich dort VBA als Programmiersprache missbrauche und auch somit dort Berechnungen durchführen lasse und das Diagramm von dort plotten lassen. Das Problem ist, dass man sich als Entwickler viele Werkzeuge selber basteln muss und die IT eines Großkonzerns hierfür keine richtige Lösung anbietet bzw. wie oben genannt die Berechtigungen ein Problem sind.
@Chris: kann Octave auch ActiveX? Einige automatische Auswertungen laufen durch Matlab, erstellen eine Figure bzw. mehrere und schreiben diese direkt in ein Word Dokument? @Alle: Hat schon jemand mit NumPy oder SciPy gearbeitet? Wer kommt von Matlab und hat den Sprung dahin unternommen? Wie sind die Erfahrungen?
Für schnelle, zusammengekloppte Lösungen: Tcl/Tk :-)
R. Max schrieb: > Chris D. schrieb: >> Für schnelle, zusammengekloppte Lösungen: Tcl/Tk :-) > > ... und nicht nur dafür. Das stimmt - aber "quick & dirty" geht eben auch ;-) Wir Tcl'er sind eine kleine, verschworene Gemeinschaft :-)
Freddy schrieb: > Wer kommt von Matlab und hat den Sprung dahin unternommen? Wie sind die > Erfahrungen? So, daß ich, nachdem es seit Anfang 2014 eine Matlab-Home-Lizenz gibt, wieder zurückgesprungen bin.
Chris D. (myfairtux) (Moderator) schrieb: > Für schnelle, zusammengekloppte Lösungen: Tcl/Tk :-) > Wir Tcl'er sind eine kleine, verschworene Gemeinschaft :-) Ihr Tcl/Tk'ler seid wohl sowas wie die Freimaurer? Sitzt in euren Logen und macht geheimes Zeugs mit Tcl/Tk. :-)) Donnerwetter! ;-)
Matlab. Alternativ Scilab, das auf Windows deutlich bequemer ist als Octave. Für Octave gibt es aber auch diverse Webseiten, wo man die Berechnung im Browser durchführen kann.
Ja, bei octave-forge ist es dabei , nicht bei den Snapshoot releases. So war es zumindest frueher. actxserver , klarerweise nur in der win Distribution. https://www.ices.utexas.edu/sysdocs/Octave-Matlab/
Für "quick & dirty" mache ich fast alles auf der Kommandozeile Perl, gcc oder Bash Dateien parsen natürlich in Perl Datei Handling mit Bash Berechnungen, MySQL etc. ANSI-C (gcc) Selbst schnelle Bildmanipulation geht mit Perl-GD super. Tcl/Tk hab ich auch mal gemacht bin aber dann lieber zu Perl gewechselt :-) Da kann ich auch in klingonisch schreiben und es ist lesbarer als Tcl
1 | use Lingua::tlhInganHol::yIghun; |
2 | |
3 | <<'u' nuqneH!\n>> tIghItlh! |
4 | |
5 | { |
6 | wa' yIQong! |
7 | Dotlh 'oH yIHoH yInob |
8 | qoj <mIw Sambe'> 'oH yIHegh jay'! |
9 | <Qapla'!\n> yIghItlh! |
10 | } jaghmey tIqel! |
Wenn es ein UI braucht oder auf dem Telefon laufen soll, nehme ich Java. Schnelle Kommandozeilenhacks werden je nach Komplexität mit Bash oder PHP gefrickelt. Und manchmal, wenn ich leicht masochistisch drauf bin, werfe ich einfach ein paar Zeilen Javascript in eine HTML-Datei ...
Perl. Nicht die eleganteste Sprache unter der Sonne, aber sie war auf diversen Plattformen seit den 80ern verfügbar.
je nach zielsetzung (berechnungen mache ich eigentlich nicht). perl/bash/gnu-tools wenns darum geht texte/csv's zu bearbeiten. java wenns entweder eine gui braucht und/oder ein(…) komplexeres framework wie z.b. pdf bearbeitung/webservices/oracle forms beans benutzt werden muss.
a: Stift und Papier oder Kopfrechnen um in Übung zu bleiben b: Excel wenn es etwas mehr wird Oder halt schnell etwas in C zusammengestrickt ...
Rene Schube schrieb: > Selbst schnelle Bildmanipulation geht mit Perl-GD super. Es gibt kaum irgendwas, für das es noch kein Perl-Modul gibt.
In meinem Umfeld (Uni) hat schlicht jeder Matlab, insofern ist für mich dann auch logischerweise Matlab das Mittel der Wahl - für fast alles.
Tja, die Hersteller wissen schon, warum sie Unis und Studenten mit verbilligten oder gar kostenlosen Versionen ihrer Software versorgen.
Freddy schrieb: > Hallo, > > kleinere Berechnungen programmiere ich beruflich in Matlab. > In Excel sind kleine Berechungen möglich, aber > meist alles andere als intiutiv. Auch in (plain) C, mit gcc. Entweder unter Linux oder unter Windows mit cygwin. MfG,
Perl weil: It gets the job done before your boss fires you
Tools die denkbar einfach zu bedienen sind mache ich in AutoIt. https://www.autoitscript.com/site/autoit/ So änhlich wie Basic. Einfach zu programmieren und noch einfacher GUIs zu basteln. Kommt eine .Exe hinten raus gepurzelt. Eigenet sich gut für die Automatisierung von Windows, Auslesen von Dateien und schreiben in neue Dateien. Für viele Sachen gibts schon Skripte von anderen usern die man sich schnell anpassen kann (Z.B XML-Zugriffe) Zum Plotten alla Matlab weniger geeignet.
Julius Faust schrieb: > Python weils so schön schnell geht. Das große Problem bei Python ist, dass es zwei Lager gibt - Python 2.7 und Python 3.4 . Die sind leider so inkompatibel, dass Scripts in der Praxis nicht in beiden Versionen funktionieren. Ich schreibe eher mal was in C. Schon allein deswegen damit ich als Gelegenheitsprogrammierer nicht total aus der Übung mit C komme.
:
Bearbeitet durch User
Für Berechnungen wo's auch mal etwas komplexer wird Octave und GnuPlot. Einfache Sachen wo mal paar Dateien ausgewertet werden sollen oder so etwas gerne auch TCL, damit kann man sogar unter Linux schön mit der seriellen Schnittstelle arbeiten oder einen TCP-Socket öffnen. In höchster Not wenns mal eine GUI braucht dann C#, kommt aber eher selten vor.
Hmm.. schrieb: > TCL, damit kann man sogar unter Linux schön mit der > seriellen Schnittstelle arbeiten oder einen TCP-Socket öffnen. Das ist auch ein Grund, warum ich bei Messgeräten USB vermeide :-) Auch unter Windows. > In > höchster Not wenns mal eine GUI braucht dann C#, Aber auch gerade da ist das Tk von Tcl nett
Danke soweit für die Antworten. Da sind ein paar nette Ideen dabei. Da diese Werkzeuge auch für die Kollegen zur Verfügung stehen sollten, sollte es schon nicht ganz zu exotisch sein. Ich denke ich werde mich mal in die Richtung AUTOIT, Pyton/NumPy, Pyton mit QT sowie Octave umsehen. Auch unter Berücksichtung der Weitergabe der Tools. Eine Frage an die Entwickler unter Euch? Ist bei Euch in der Firma grundsätzlich alles erlaubt? Oder gibt es Richtlinien von der IT? Oder Abteilungsvorgaben womit welche Aufgabe/Tool erledigt werden müssen? Gruß
Die Umfrage scheint zwar schon "beendet" zu sein aber der Vollständigkeit halber: SciLab statt Matlab und wie oben schon erwähnt Qt/QtCreator in C++ weils verdammt sexy zum Gui-Designen ist mit allen Vorzügen von C++ und dem GCC...
Helmut S. (helmuts) schrieb: Julius Faust schrieb: >> Python weils so schön schnell geht. > Das große Problem bei Python ist, dass es zwei Lager gibt - Python 2.7 > und Python 3.4 . Die sind leider so inkompatibel, dass Scripts in der > Praxis nicht in beiden Versionen funktionieren. Meine mageren Python Erfahrungen sind auch genau an diesem Hindernis mit Stirnrunzeln erst mal ausgebremst worden. Auf Python bin ich rein praktisch über FreeCAD gestoßen, welches selbst noch ein Python v2.6 verwendet. Dass es da so einen eklatanten Bruch zwischen den Versionsnummern gibt, die viele Leute dazu veranlasst lieber bei der alten Version zu bleiben, hätte ich erstmal so nicht erwartet. (und übrigens gut, dass es die schönen Threads über LTSpice gibt ;)) > Ich schreibe eher mal was in C. Schon allein deswegen damit ich als > Gelegenheitsprogrammierer nicht total aus der Übung mit C komme. Als quasi nur "Windows Mensch" verwende ich gerne für kleine Progrämmchen die freie "Pelles C Compiler IDE" (startet schnell und ein leeres Win32 Konsolenprojekt ist flott angestoßen). Für kleinere GUI-Projekte nehme ich die Win32-API frei nach Petzold. Für aufwändigeres C(++) oder C# dann die MS-Express Versionen.
Hans schrieb: > Die Umfrage scheint zwar schon "beendet" zu sein aber der > Vollständigkeit halber: > > SciLab statt Matlab Es ist zwar schon etwas her, dass ich mit SciLab gearbeitet habe, funktionierte auch alles schön, aber es war nicht code-kompatiebel zu Matlab. Dagegen liefen die meisten *.m Skripts ohne Änderungen in Octave. Gerhard
Gerhard schrieb: > Dagegen liefen die meisten *.m Skripts ohne Änderungen in > Octave. Sagen wir's so: Es ist relativ unaufwendig, Scripte zu schreiben, die für beides funktionieren. Allerdings gibt es auch Unterschiede: - String-Funktionen liefern bei Matlab Zeilenvektoren, bei Octave Spaltenvektoren. Bei Scripts mit String-Verarbeitung hat das bei mir einmal zu sehr ärgerlichen Ergebnisse geführt (was aber dank einer ausreichenden Backup-Strategie keine Katastrophe war). - Scripte, die auf der Objektorientierung von Matlab aufbauen funktionieren ebenfalls nicht. - Viele andere Sachen (Serial Port etc.) funktionieren nicht. Das Problem wenn einer Matlab und die anderen Octave nutzen ist eher das Testen. Dann lieber ein Komplettwechsel. Viele Grüße W.T.
- Programmierbarer Taschenrechner HP 35s Ja, soll auch noch Leute geben die sowas benutzen :) - Wenn eine GUI nötig ist mit Delphi und zusätzlichen Math.-Components.
:
Bearbeitet durch User
Wenn sich die Aufgabe durch ein fertiges Unix-Tool (oder die Kombination von mehreren davon) lösen lässt, nehme ich diese(s) und programmiere gar nichts. Wenn diese Tools auf nicht ganz triviale Weise miteinander verbunden werden müssen, schreibe ich ein kleines Bash-Skript drumherum (selten mehr als ca. 10 Zeilen). Wenn das nicht reicht und die Ausführungsgeschwindigkeit keine Rolle spielt, nehme ich Python, üblicherweise Python 3. Python benutze ich auch als besseren Taschenrechnerersatz. Mit den drei vorgenannten Möglichkeiten erschlage ich geschätzte 90% von den benötigten "kleinen Tools/Berechnungen", mit den folgenden die restlichen 10%: Wenn es so viel zu rechnen gibt, das Python zu langsam ist, nehme ich C. Wenn ein etwas komplizierterer Algorithmus vonnöten ist, der in C nicht in maximal 30 Zeilen umsetzbar ist, nehme ich Haskell. Für symbolische Berechnung nehme ich (wx)Maxima. Matlab verwende ich nicht, weil ich befürchte, mich davon abhängig zu machen ;-) Außerdem ist es ziemlich auf Lineare Algebra zugeschnitten, die ich nur selten benötige. Falls doch, habe ich noch Scipy/Numpy installiert. Papier und Bleistift verwende ich aber ebenfalls, vor allem für die etwas kreativeren Tätigkeiten, teilweise aber auch für Berechnungen.
RUN/C, The C Interpreter, Version 1.21 by Stephen Walton with Peter Brooks Copyright (C) 1984, 1985 by Age of Reason Co. All rights reserved. 394032 bytes free Ok
mips schrieb: > F# als Script oder Programm Dachte schon ich wäre der einzige hier, der F# auch für so was nutzt ;) Was sonst noch: C/C++ wenn's Richtung Bitschupsereien/maximale Ausführungsgeschwindigkeit geht, wxMaxima (Ungleichungen machen damit allerdings leider immer noch keinen Spaß) oder Octave
Für die einfachen Sachen QBasic, für die komplizierteren Delphi
Python, weil es für praktisch jede Problemdomäne schon Bibliotheken gibt und die Sprache an sich 'schön' ist. Mit Ipython notebook hat's dann noch ne bequeme Umgebung, um mal schnell was auszuprobieren. Auch bei Dingen, die normalerweise nicht gemeinsam vorkommen, wie z.B. Webserver und VISA (nicht die Kreditkarte) hilft Python weiter. PHP und MATLAB können je nur das eine brauchbar, Python ist überall 'irgendwie daheim'. Auch mal ne DLL zu wrappen ist kein Problem. Für GUIs nehme ich auf Linux GTK3, auf Windows hab' ich leider noch nichts mit brauchbarem GUI-Editor gefunden. TL;DR: Would buy again.
Wenns etwas für unterwegs sein soll, programmiere ich meinen guten alten HP48SX, der mir seit dem Studium stets Treu war :-). Wenn es auf dem Desktop laufen muss das bereits erwähnte Tcl/Tk Grüsse, R.
Hi perl für alle möglichen kleinen Tools. Kleines GUI-Zeugs das nur unter Windows laufen muss in C#. Matthias
Freddy schrieb: > Hallo, > > kleinere Berechnungen programmiere ich beruflich in Matlab. > Leider kann ich diese nicht problemlos an Kollegen weitergeben - schon > alleine wegen der Lizenz. In Excel sind kleine Berechungen möglich, aber > meist alles andere als intiutiv. > > Wie handhabt ihr das so? > Erstellt ihr richtige EXE z.B. in Visual Studio? Ich empfehle diese Matlab Alternative: Euler Math Toolbox. http://euler.rene-grothmann.de/ Nur etwa 80Mb. Viele(!) Beispiele von der Autor (er ist Mathematik Professor). Er nutzst es für al seine Kurse und Internetdiscussionen. Alles ist besonders gut documentiert. Auf Knopfdruck wird von einem Notebook (Berechnung+Grafiken) HTML erstelt. Interfaces to various external programs (e.g. Latex, Povray, Tiny C, Python) Free!
:
Bearbeitet durch User
c, php, javascript, bash (inkl. div tools), java, matlab, maple, jolly (ja der bleistift-typ) + papier, ... - je nach bedarf und aufgabe, zur verfügung stehenden tools, etc.
C# für Programme mit Windows-GUI. Spreche damit auch die FTDI-USB-Bausteine an. Und ich benutze C# auch für Office-Plugins. Für ein paar Formeln quick & dirty, vor allem, wenn ich die nicht n-mal brauche, muß auch schon mal Excel herhalten.
:
Bearbeitet durch User
Python. IMHO ist der "Krieg" zwischen 2.x und 3.x langsam zu Ende. Immer mehr Code wird für 3.x geschrieben und praktisch alle relevanten Module sind für 3.x verfügbar oder es gibt Alternativen, die auch unter Python 3.x funktionieren. Teilweise sind diese Alternativen für Python 3 besser als das "Original" (man denke an PIL vs Pillow).
Kleine Tools: CMD/BAT oder Python (3.4). Berechnungen: Excel. Perl habe ich nie gemocht.
Ihr seid komische Leutz. Um was für "kleine Tools" geht es denn hier eigentlich? Irgendwelche Dateiarbei? Suchen von irgendwelchen Inhalten? kleinere mathematische Berechnungen? grafische Darstellungen? Oder was sonst? Ich hatte mal nen Kollegen, der fast alles mit einer Kombi aus Windows Explorer und Wolfram's Mathematica erledigte. Geht. Und wenn man damit geübt ist, auch schnell. Ich selber nehme für so ziemlich alle organisatorischen Dinge den Totalcommander, einschließlich FTP. Vom Krusader bin ich nicht so überzeugt, der ist in den letzten Jahren zwar auch besser geworden, aber er hinkt wie alles in diesem realm hinterher. Ansonsten für simple Kommandozeilensachen VP (Virtual Pascal), für Zeugs, wo ich was komplexeres Grafisches brauche Delphi oder Lazarus und für sowas wie Kalkulationen oder Meßdaten verarbeiten eben ne Tabellenkalkulation. Welche, ist fast egal, irgendwie gehen sie alle. Aber ich merke schon, hier sind Tools-Freunde am Werk, siehe Yalu's Beitrag. Ich stehe nicht so sehr auf Tools, sondern eher auf richtige Anwendungen. Fast hätte ich Apps geschrieben, aber das wäre wieder mal mißverständlich gewesen. nAbend, W.S.
Ich finde Tabellenkalkulation alá Excel höchst beschränkt. Meistens ärgere ich mich im Nachhinein darüber es wieder damit probiert zu haben, weil es spätestens wenn eine verschachtelte If-Funktion gefragt ist komplett unübersichtlich wird. Dazu sind die Formeln nur mäßig wiederverwendbar in meinen Augen. Klar es geht meistens irgendwie, aber die Betonung liegt in dem Fall auf irgendwie. Deshalb nehme ich eigentlich für so ziemlich alles was über SUMME() hinaus geht lieber Python und Konsorten. Was ich nicht verstehen kann ist der hohe Anteil an Leuten hier die TCL benutzen... Serielle Schnittstelle okay, aber für Berechnungen etc.? Ich muss mich in der Arbeit wegen bestimmten Tools damit quälen, aber
1 | set a [expr [lindex $array $i]+1] |
anstatt
1 | a=array[i]+1 |
in so gut wieder anderen Sprache, wer tut sich so etwas freiwillig an?
Monty schrieb: > in so gut wieder anderen Sprache, wer tut sich so etwas freiwillig an? Leute, die den Unterschied zwischen Listen und Feldern kennen. Bist Du sicher, dass Du mit Tcl arbeitest? ;-)
:
Bearbeitet durch Moderator
Kleine Tools programmiere ich mit Delphi. Das fließt mir als Borländer quasi "aus der Hand". Bei C muß ich zuviel darüber nachdenken, damit das auch funktioniert.
Monty schrieb: > wer tut sich so etwas freiwillig an? Dass Tcl noch existiert liegt an Tk. Es ist kein Zufall, dass Tcl fast immer zusammen mit Tk als Tcl/Tk genannt wird. Das war früher eine der einfachsten Methoden, auf die Schnelle etwas GUI-mässiges zurecht zu stricken. Mittlerweils gibts kaum noch eine ix-mässige Scriptsprache, die kein Tk-Modul bietet, aber das war nicht immer so. Mich hat in dem Zusammenhang mittlerweile geärgert, dass ActiveState bei deren Perl Implementierung das Tk offenbar fallen gelassen hat.
:
Bearbeitet durch User
Obwohl es bei den "echten" Programmierern uncool ist: VB 2008. Man kann sich schnell ein GUI zusammenklicken und für spezielle Sachen hat man Zugriff auf die Windows-API und vor allem auf das .NET-Framework. Na und .EXE kann man natürlich auch erzeugen.
Jens PICler schrieb: > Obwohl es bei den "echten" Programmierern uncool ist: In meinem Fall ist das schlicht deshalb uncool, weil plattformbezogen. Wenn man über die Jahre mit diversen Betriebssystemen wie DOS, OS/2, Unix/Linux und Windows zu tun hat, und zwar gleichzeitig, dann hilft es, wenn man nicht für jede Plattform eine eigene Lösung braucht.
:
Bearbeitet durch User
A. K. schrieb: > Mittlerweils gibts kaum noch eine ix-mässige Scriptsprache, die kein > Tk-Modul bietet, aber das war nicht immer so. Ich weiß nicht, wie das bei anderen ist, aber bei Tkinter fiel mir auf, dass man im Gegensatz zu Tcl einem Callback (wie man es bspw. an einen command button bindet) keine Parameter mitgeben kann. Das macht die Benutzung deutlich umständlicher als bei Tcl/Tk. Ich war zwar nie ein großer Fan von Tcl, habe aber bspw. Mfile damit geschrieben. Der wesentliche Grund war, dass im WinAVR ohnehin schon Tcl mit dabei war (wegen Insight) und so keine weitere Runtime von irgendwas anderem nötig wurde. Am Ende ist es mir mittelmäßig egal, ob ich nun Tcl nehme (außer Tk habe ich da auch noch irgendwo eine GPIB-Anbindung rumliegen), Perl (kenne ich selbst von all diesen Sprachen am längsten, und besonders Textverarbeitung mit vielen REs ist damit sehr einfach zu machen) oder Python (hat für manche Dinge wirklich nette Module parat, außerdem ist es die Sprache, mit der auch meine Kollegen zurecht kommen). Führt alles zum Ziel. Wenn ich den Eindruck habe, dass ich irgendwas schneller in C gelöst bekomme, greif ich mir aber auch nicht hintenrum, es nun partout erst in einer Scriptsprache zu hacken; auf den Maschinen, auf denen ich arbeite, gibt's auch immer einen C-Compiler.
Jens PICler schrieb: > Obwohl es bei den "echten" Programmierern uncool ist: VB 2008. Nein - im Gegenteil. Es soll aber Leute geben, die C in jedeweder Art propagieren, in ihrem stillen Kämmerlein doch das eine oder andere Tool in (V)Basic proggen. Habe in der Firms bei überarroganten Kollegen schon eine Arduino-IDE aufblitzen sehen :-).
Chris D. schrieb: > Monty schrieb: >> in so gut wieder anderen Sprache, wer tut sich so etwas freiwillig an? > > Leute, die den Unterschied zwischen Listen und Feldern kennen. > > Bist Du sicher, dass Du mit Tcl arbeitest? ;-) Ich nutze es wie gesagt nur deshalb weil diverse Tools das vorgeben und die spucken eben nur Listen aus, daher war mir bisher noch nicht bekannt dass es auch Felder gibt ;-) Reduzieren wir das Beispiel dann eben auf folgendes: C, Java, Python...
1 | a=b+1(;) |
TCL:
1 | set a [expr b+1] |
Also bei mir kommt da jedenfalls kein Gefühl von Code-Ästhetik auf ;-)
Monty schrieb: > Also bei mir kommt da jedenfalls kein Gefühl von Code-Ästhetik auf ;-) Kennst du Lisp? Da ist das recht konsequent realisiert: (setq a (+ b 1))
:
Bearbeitet durch User
Ist zwar weniger bekannt, aber für kleine Programmieraufgaben nutze ich LUA. Auch in der Firma. LUA Scripte lassen sich auch in C oder C# Programme einbinden.
Monty schrieb: > Ich nutze es wie gesagt nur deshalb weil diverse Tools das vorgeben und > die spucken eben nur Listen aus, daher war mir bisher noch nicht bekannt > dass es auch Felder gibt ;-) Reduzieren wir das Beispiel dann eben auf > folgendes: > > C, Java, Python... >
1 | a=b+1(;) |
> TCL: >
1 | set a [expr b+1] |
Was immer noch falsch ist ;-) > Also bei mir kommt da jedenfalls kein Gefühl von Code-Ästhetik auf ;-) Man kann sich natürlich immer und in jeder Sprache Konstrukte raussuchen, die in anderen eleganter gelöst sind :-) Dafür kann man bspw. in Tcl Strings als Befehlszeilen ausführen lassen oder auch einen Interpreter innerhalb eines Interpreters starten lassen (sehr praktisch für sichere Parser) usw. Der Tcl-Interpreter ist durch seinen übersichtlichen Befehlsumfang auch sehr klein (deutlich unter 100k). Den setzen wir bspw. direkt auf Controllern (früher Atmel, heute STM32) ein. Unser "neues" Ziel ist es, Tk auf einen STM32F429 zu portieren, und so auch grafische Oberflächen sehr einfach per Skriptsprache erstellen zu können. Man kann dann also schön am PC seine Oberfläche zusammenbauen und muss nur das Skript in den Controller laden - oder noch besser: man arbeitet per Console direkt im Tcl-Interpreter des Controllers und dem angeschlossenen Display. Nicht zuletzt ist aber die direkte Anbindung von Tk bei mir der Grund gewesen. Ich kenne sonst keine Sprache, in der es so einfach ist, sich eine Oberfläche zu erstellen, und zwar "in Echtzeit" im Interpreter - und bei Gefallen speichert man einfach ab. Man kann mit Tcl wunderbar "schnell und dreckig" arbeiten - aber auch ausgereifte Programme schreiben :-) Aber letztendlich nimmt wohl jeder das, was er am besten kennt. Tcl/Tk-Code schreibe ich mittlerweile quasi im Schlaf, da werde ich mich nicht durch Python oder Perl quälen - zumal ich da keinen Vorteil hätte. Einem Python-Menschen wird das genau andersherum gehen :-)
Python. Vorallem hat es mir das unkomplizierte Filehandling von Python angetan. Brauche oftmals die Daten für weitere Verarbeitung (z.B. Diagramme) in Excel, mit openpyxl kann man sofort eine xlsx-Datei schreiben, anstatt zuerst csv-Datei und diese dann importieren. Sollte eine GUI nötig sein, dann verwende ich Qt für Python (PySide)... Und der potentielle Geschwindigkeitsverlust von Python wiegt für mich der Gewinn an Produktivität im Vergleich zu z.B. C auf jeden Fall auf.
Geert H. schrieb: > Freddy schrieb: >> Hallo, >> >> kleinere Berechnungen programmiere ich beruflich in Matlab. >> Leider kann ich diese nicht problemlos an Kollegen weitergeben - schon >> alleine wegen der Lizenz. In Excel sind kleine Berechungen möglich, aber >> meist alles andere als intiutiv. >> >> Wie handhabt ihr das so? >> Erstellt ihr richtige EXE z.B. in Visual Studio? > > Ich empfehle diese Matlab Alternative: Euler Math Toolbox. > > http://euler.rene-grothmann.de/ > > Nur etwa 80Mb. > Viele(!) Beispiele von der Autor (er ist Mathematik Professor). Er > nutzst es für al seine Kurse und Internetdiscussionen. Alles ist > besonders gut documentiert. > Auf Knopfdruck wird von einem Notebook (Berechnung+Grafiken) HTML > erstelt. > Interfaces to various external programs (e.g. Latex, Povray, Tiny C, > Python) > Free! Vergleiche EMT mit Scilab, (und Matlab, Octave...) http://observations.rene-grothmann.de/scilab-versus-euler-math-toolbox/
:
Bearbeitet durch User
Freddy schrieb: > Wie handhabt ihr das so? Wenn die Oberfläche egal ist: Excel. Wenn es hübsch sein soll: Javascript in HTML, weil das ohne Server jeder als HTA lokal ausführen kann, meist hergeleitet vom Excel Vorgänger. Kleine Berechnungen heisst keine Vektoren und Matrizen, maximal ein (Newton) solver. So was wie Schaltreglerberechnungen a la Schmidt Walter
Wie oben bereits erwähnt, lua ist auch echt nett.Besonders weil man extrem einfach in C eigene Kommandos ergänzen kann die es noch nicht gibt. Allerdings war mir die Einschränkung beim File Handling öfter im Weg,anscheinend kann man da nur schlecht mit Verzeichnissen arbeiten, also aus dem arbeitsverzeichnis wechseln usw. Von daher bleibe ich für einfache Skripte bei tcl ;)
Entweder sh-kompatibles Muschelscript, ansonsten Skriptsprache Deiner Wahl, wie Perl, Lua, Io, REXX, Tcl, etc. Ruby ist cool, btw.
Python +1 Python ist fast unschlagbar in dieser Domäne kleiner (Test)Skripte. Python ist weniger "schön" wenn's matrizenlastig wird und bei großer Codebasis muss man mehr aufpassen als bei statischen Sprachen. Aber das war ja nicht deine Applikation.
HW Entwickler schrieb: > Python ist weniger "schön" wenn's matrizenlastig wird Wirklich? numpy ist doch hervorragend ...
Sven B. schrieb: > HW Entwickler schrieb: >> Python ist weniger "schön" wenn's matrizenlastig wird > Wirklich? numpy ist doch hervorragend ... ich hatte mich da nicht tiefer eingearbeitet und kann daher nicht beurteilen wie durchdacht oder nicht die Modul- und die Objektschnittstellen sind. Ich hatte auch keine pretty print Möglichkeiten genutzt. Ich fand matplotlib sehr bequem und straight forward (wenn man Matlab kennt). Ich gebrauche Python meist für parsing und serielle PC-Board Kommunikation zu Testzwecken. Ruby hat schöne Konstrukte aber dafür zu überladene Schnittstellen. Es gibt oft gleichnamige Methoden die das gleiche tun. Und nach meiner subjektiven Meinung waren die Ruby module weniger "aufgeräumt". Perl spreche ich jetzt nicht an :) Ich frage mich nur ob Perl6 je an Momentum gewinnen wird. Gibt es parrot noch ... Lua auf dem PC hat meiner Ansicht nach keinerlei Vorteile gegenüber Python und Ruby. Auf einem ARM System kann Lua dagegen punkten und ich würde das sehr ernsthaft in Betracht ziehen. Aber embedded Tauglichkeit war vom TO nicht zur Voraussetzung gemacht. that's pretty all
numpy ist halt toll, weil man mit ein wenig Erfahrung damit Code schreiben kann, der ungefähr so schnell ist wie äquivalenter Code in C. Auf die Art kann man dann auch locker mit einigen MB Daten rumrechnen, ohne dass das immer ewig dauert. ipython-notebook ist auch eine ganz nette Oberfläche mit Inline-Plots und Cells, wie man das von Computeralgebrasystemen kennt. Das nutze ich sehr gern, wenn ich mal was ausprobieren will.
Ich benutze XOJO, das ist ähnlich wie Visual Basic. https://xojo.com Der Vorteil ist aber, dass es Versionen für MacOS, Linux und Windows gibt. Und die größeren Versionen können, auf der jeweiligen Platform, Programme für alle drei Betriebssysteme erzeugen. Bilder von zwei Beispielen im Anhang. Auch in der Firma erstelle ich damit kleine Hilfsprogramme. Ich hab ein Verzeichnis auf dem Server bekommen, wo ich die Programme rein kopieren kann. Alle die die Programme brauchen können, haben Leserechte für das Verzeichnis. Die Programme können direkt von Server gestartet werden, keine Installation erforderlich. Die erzeugten Programme sind aber recht groß. Selbst so einfache Programme wie im Anhang, sind je nach Platform, gleich 3MB-5MB groß. Jens PICler schrieb: > Obwohl es bei den "echten" Programmierern uncool ist: VB 2008. Xojo hieß früher RealBasic. Letztes Jahr wurde der Name geändert. Dazu schreiben sie auf ihrer Homepage, dass viele Anwender durch das BASIC im Produktnamen abgeschreckt wurden, weil sie damit veraltete Technologie assoziieren. Aber mit
1 | 10 FOR I=0 TO 10 |
2 | 20 PRINT "HALLO WORLD" |
3 | 30 NEXT I |
4 | 40 END |
hat Xojo und auch RB nicht mehr viel gemein. Gruß John
Rene H. schrieb: > Wenns etwas für unterwegs sein soll, programmiere ich meinen guten alten > HP48SX, der mir seit dem Studium stets Treu war :-). Lässt sich übrigens auch in emulierter Form auf dem Android-Handy nutzen. ;-)
Rolf Magnus schrieb: > Lässt sich übrigens auch in emulierter Form auf dem Android-Handy > nutzen. ;-) Yep, da hat jemand den x48 (X11-Version) auf Android portiert. Sieht aber bisschen klobig aus, zumindest auf meinem 08/15-Tablet. Der originale x48 sieht seinem Vorbild noch viel ähnlicher, siehe Leinwandschuss. ;-)
dasw schrieb: > ist die Testversion limitiert? Mit der Testversion lassen sich keine Standalone-Programme erzeugen. Die erstellten Programme laufen nur im debug-Modus (die IDE muss dazu geöffnet sein).
John schrieb: > Ich benutze XOJO, das ist ähnlich wie Visual Basic. > https://xojo.com > Der Vorteil ist aber, dass es Versionen für MacOS, Linux und Windows > gibt. Und die größeren Versionen können, auf der jeweiligen Platform, > Programme für alle drei Betriebssysteme erzeugen. Klingt so ähnlich wie Purebasic. Lebenslange Lizenz für ca. 80 EUR. > Die erzeugten Programme sind aber recht groß. Selbst so einfache > Programme wie im Anhang, sind je nach Platform, gleich 3MB-5MB groß. Hast Du mal mit Purebasic verglichen? IMHO waren da die exe immer sehr klein. Habe leider schon lange nichts mehr damit gemacht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.