Die Programmiersprache Julia ist seit kurzem in der Version 1.0 verfügbar. https://julialang.org/ Sie soll (sehr grob gesagt) das beste aus Matlab und Python vereinen und dabei relativ performanten Code erzeugen. Mich würde interessieren, ob es hier Leute gibt, die das Verwenden und wenn ja: wofür. Ich selber stieß vor Jahren durch das Buch "Sieben Wochen, sieben Sprachen" auf Julia, fand die Sprache interessant und beobachte sie seitdem aus der Ferne. Da ich hauptsächlich Hardwareentwickler bin, programmiere ich eher selten, möchte mich aber darüber auf dem Laufenden halten, was bei den Programmiersprachen so passiert.
:
Verschoben durch User
Ich programmiere seit 30 Jahren. Dabei habe ich folgende "Weisheit" gelernt: Laufe nicht jeder Sau nach, die durchs Dorf getrieben wird. 90% aller Programmiersprachen verschwinden nach kurzer Zeit wieder und von den restlichen 10% sind 60% nicht wirklich besser, als was es vorher gab. Wobei es ja nicht nur darauf ankommt, dass die Programmiersprache taugt, sondern auch auf die Libraries die drumherum gebaut werden. Warte erst einmal mindestens 5 Jahre, dann kann man viel eher sehen, ob es Sinn macht, die neue Programmiersprache zu erlernen.
Falsches Forum. Der selbsternannte Mikrocontroller-Experte verwendet weder Matlab noch Python und sieht selbst C und C++ noch mit einer gewissen Skepsis. Echte Männer programmieren Assembler, wenn sie nicht gerade mit DIP-Schaltern die Bits im EEPROM von Hand setzen. Aber mal im Ernst: Welche Vorteile verspricht man sich mit "dem besten aus beiden Welten"? Der Vorteil von Matlab ist super-Support und viele Libraries, dazu eine hervorragende Performanz bei relativ einfacher Parallelisierung. Dafür ist es teuer. Der Vorteil von Python liegt in einer riesigen Anzahl an 3rd-Party-Libraries und keinem Kostenrisiko, auch vernünftige, wenn auch nicht überragende Geschwindigkeit, dafür keinerlei echten Support. Wie sieht das Beste aus beiden Welten aus?
Walter T. schrieb: > Aber mal im Ernst: Welche Vorteile verspricht man sich mit "dem besten > aus beiden Welten"? Ich dachte mir, dass ich das besser nicht hätte schreiben sollen. Bitte dem Link folgen und ggf. selber lesen, was Julia sein will und was nicht. Danke für Eure Antworten, denen ich entnehme: Ihr schon mal nicht.
Walter T. schrieb: > Wie sieht das Beste aus beiden Welten aus? Lass mich raten: Die Krude Syntax von Python kombiniert mit der Performance* von Matlab, sowie dem Potential, alle Libraries neu schreiben zu müssen/dürfen. *) Für Mikrocontroller sind beide eher nicht gedacht, oder?
M.A. S. schrieb: > Ich dachte mir, dass ich das besser nicht hätte schreiben sollen. Bitte > dem Link folgen und ggf. selber lesen, was Julia sein will und was > nicht. Was soll das heißen, wolltest du Schleichwerbung machen? Dann schreib es doch einfach ehrlich hin! Am geilsten finde ich das allererste Versprechen: "Julia is fast". Ist schon klar, das behaupten alle.
Stefanus F. schrieb: > Für Mikrocontroller sind beide eher nicht gedacht, oder? Deshalb stehts wohl im PC Unterforum :-) Walter T. schrieb: > Welche Vorteile verspricht man sich mit "dem besten > aus beiden Welten"? Bestimmt wird "Strukturierung durch Einrückung" benutzt Bestes Feature überhaupt! Achtung: Der Beitrag kann Spuren von Ironie oder Sarkasmus enthalten
Stefanus F. schrieb: > Was soll das heißen, wolltest du Schleichwerbung machen? Dann schreib es > doch einfach ehrlich hin! Auch, wenn ich beides nicht verwerflich fände: nein. Weder Schleich- noch Werbung. Ich gebe offen zu (und ich weiß, dass das in diesem Forum ein Risiko ist) Julia interessant zu finden. Mein Frage war nicht: wie findet Ihr Julia, wobei es mich auch nicht stör, dass Ihr Euch darüber auslaßt, erfahrungsgemäß kann man das sowieso nicht verhindern. Ich meinte meine Frage exakt genauso, wie ich sie schrieb: Verwendet jemand von Euch Julia?
Stefanus F. schrieb: > *) Für Mikrocontroller sind beide eher nicht gedacht, oder? Das weiß ich werden, noch interessiert es mich im Augenblick. Ich stellte die Frage deshalb auch in "PC-Programmierung"!
M.A. S. schrieb: > Bitte > dem Link folgen und ggf. selber lesen, was Julia sein will und was > nicht. Hm. Die Vor- und Nachteile von Matlab und Python liegen nicht in den Sprachen selbst, sondern im Ökosystem. Davon erfährt man auf der Seite nichts.
Stefanus F. schrieb: > "Julia is fast". Ist schon klar, das behaupten alle. Die wenigsten von denen, die das behaupten, werden jedoch ihren Code direkt nach LLVM füttern. ;-) Der Andere schrieb: > Bestimmt wird "Strukturierung durch Einrückung" benutzt Naja, ein kurzer Blick in deren Doku hätte dir gezeigt, dass sie ein Schlüsselwort namens „end“ haben. Ich bin selbst von numerischen Algorithmen ziemlich weit weg, insofern ist das für mich nicht wirklich interessant.
M.A. S. schrieb: > Das weiß ich werden, noch interessiert es mich im Augenblick. Ich > stellte die Frage deshalb auch in "PC-Programmierung"! Es sehe gerade unter meinem Eröffnungsthread: "17.09.2018 11:44: Verschoben durch Moderator" Vielen Dank dafür, ich hatte in der Tat vor, es im UF "PC-Programmierung" zu eröffnen, scheinbar war ich dafür aber zu blöd. Gut, dass es nun aber trotzdem dort ist und sorry an alle anderen für die daraus entstandenen Mißverständnisse.
M.A. S. schrieb: > Sie soll (sehr grob gesagt) das beste aus Matlab und Python vereinen und > dabei relativ performanten Code erzeugen. > > Mich würde interessieren, ob es hier Leute gibt, die das Verwenden und > wenn ja: wofür. Das Problem an dieser Kombinatorik zweier Sprachen ist doch für den Nutzer eindeutig: wer schon mal eine Julia hatte und absägte, wird versuchen ein zweites mal nicht den selben Fehler erneut zu machen. Wenn ihr wisst was ich meine...
M.A. S. schrieb: > Mich würde interessieren, ob es hier Leute gibt, die das Verwenden und > wenn ja: wofür. Ja, benutze ich und zwar für die Auswertung und Visualisierung von Daten. Walter T. schrieb: > Wie sieht das Beste aus beiden Welten aus? Julia hat einen sehr guten Paketmanager (im Gegensatz zu Matlab) und eine sehr aufgeräumte Syntax (im Gegensatz zu Python/Numpy). Das es kostenlos und Open-Source ist, ist für mich ein zusätzlicher Pluspunkt. Die Performance ist für mich jetzt nicht so kriegsentscheident, da meine Skripte nicht 24/7 laufen aber es gibt einige Beispiele wo Julia (und übrigens auch Python) um Größenordnungen schneller ist als Matlab, z.B. in der Stringverarbeitung.
:
Bearbeitet durch User
Walter T. schrieb: > M.A. S. schrieb: >> Bitte >> dem Link folgen und ggf. selber lesen, was Julia sein will und was >> nicht. > > Hm. Die Vor- und Nachteile von Matlab und Python liegen nicht in den > Sprachen selbst, sondern im Ökosystem. Davon erfährt man auf der Seite > nichts. Wie wäre es mal mit etwas runter scrollen zu "Ecosystem", noch ein bisschen weiterscrollen zu "Packages" und dann schlussendlich unter "Recent Blog Posts" der erste Eintrag: "How to get started with Julia 1.0's package manager"?
M.A. S. schrieb: > Ich selber stieß vor Jahren durch das Buch "Sieben Wochen, sieben > Sprachen" auf Julia, fand die Sprache interessant und beobachte sie > seitdem aus der Ferne. Damit hast Du mich eben neugierig gemacht, denn dieses Buch nehme ich mir schon lange vor, es endlich mal durchzuarbeiten. Als ich dann aber eben nochmal nachgeschaut habe, konnte ich allerdings nichts dazu finden, dass Julia eine der sieben Programmiersprachen aus "Seven languages in seven weeks" wäre. Kann es sein, dass Du da das Buch verwechselt hast?
Joachim S. schrieb: > Kann es sein, dass Du da das Buch > verwechselt hast? Ei, Heute ist nicht mein Tag in diesem Forum! Danke, dass Du mich darauf aufmerksam machst, Du hast recht. Es war: "Seven More Languages in Seven Weeks" http://shop.oreilly.com/product/9781941222157.do
M.A. S. schrieb: > Mich würde interessieren, ob es hier Leute gibt, die das Verwenden und > wenn ja: wofür. Wenn dir der Sinn nicht unmittelbar zugänglich ist, warum mehr Aufwand treiben. Fortran lebt!
Sebastian L. schrieb: > Fortran lebt!
1 | C FORTRAN LEBT! |
2 | PROGRAM MAIN |
3 | WRITE(6, 100) 72, 85, 82, 82, 65 |
4 | 100 FORMAT(1H , 5A1, 1H!) |
5 | END |
Ich verwende Julia von Zeit zu Zeit. Sie ist gut geeignet zum Rotweintrinken, Kuscheln und für fortpflanzungstypische Handlungen. Meine Frau habe ich anhand dieses Threads hier davon überzeugt, dass die deutlich jüngere Julia doch nur eine Programmiersprache ist. Neulich erzählte meine Frau etwas von programmieren mit Pascal!?
Sebastian L. schrieb: > Fortran lebt! Route 6. schrieb: > Ich verwende Julia von Zeit zu Zeit. > Sie ist gut geeignet zum Rotweintrinken, Kuscheln und für > fortpflanzungstypische Handlungen. > > Meine Frau habe ich anhand dieses Threads hier davon überzeugt, dass die > deutlich jüngere Julia doch nur eine Programmiersprache ist. > > Neulich erzählte meine Frau etwas von programmieren mit Pascal!? Ihr Witzbolde! :) Den unteren kenn' ich anders: Beim 'Programmieren' mit Julia entstand Pascal, der inzwischen 3 Jahre alt ist...
Keine Liebe auf den ersten Blick. Da bin ich wohl von octave zu verwöhnt. Schaue es mir aber bei Gelegenheit näher an. Die Visualisierungen auf der Webside schauen ganz gut aus.
:
Bearbeitet durch User
Immerhin sind die Fehlermeldungen aussagekräftig. Das kenne ich von Matlab auch anders.
Christopher J. schrieb: > Immerhin sind die Fehlermeldungen aussagekräftig. Das kenne ich von > Matlab auch anders. Bitte ein Beispiel!
M.A. S. schrieb: > Ich selber stieß vor Jahren durch das Buch "Sieben Wochen, sieben > Sprachen" auf Julia Ich bin einst im Zeltlager auf eine Stefanie gestoßen. > und beobachte sie seitdem aus der Ferne. Mein Gott, so wird das natürlich nie was! Sprich sie doch einfach mal an! > Ich gebe offen zu (und ich weiß, dass das in diesem Forum ein Risiko > ist) Julia interessant zu finden. Weißt Du denn schon, wie sie Dich findet? > Mein Frage war nicht: wie findet Ihr Julia, wobei es mich auch nicht > stör, dass Ihr Euch darüber auslaßt, erfahrungsgemäß kann man das > sowieso nicht verhindern. Eben. Also hör nicht auf irgendwelche Buschfunker aus dem Forum, sondern lass einzig und allein Dein Herz sprechen ;-) > Ich meinte meine Frage exakt genauso, wie ich sie schrieb: > Verwendet jemand von Euch Julia? Nanana, "verwenden" ist vielleicht ein etwas sexistischer Ansatz. Christopher J. schrieb: > Julia hat einen sehr guten Paketmanager Den Typ würd ich übrigens gleich raushauen - solche Dreiecksgeschichten sind auf Dauer nur stressig! Wie auch immer Du Dich entscheidest - mach es nicht nur von der Benutzeroberfläche abhängig. Da ändern sich über die Zeit garantiert die modischen Vorlieben. Ich würde stattdessen besonders darauf achten, ob Du bei Julia Deinen alten Joystick weiterverwenden kannst ;-) Walter T. schrieb: > Christopher J. schrieb: >> Immerhin sind die Fehlermeldungen aussagekräftig. Das kenne ich von >> Matlab auch anders. > > Bitte ein Beispiel! "Bring endlich mal den Müll raus!"
M.A. S. schrieb: > Die Programmiersprache Julia ist seit kurzem in der Version 1.0 > verfügbar. > > https://julialang.org/ > > Mich würde interessieren, ob es hier Leute gibt, die das Verwenden und > wenn ja: wofür. Ich hätte gerne mal Julia von C aus angesprochen https://docs.julialang.org/en/latest/manual/embedding/ nur leider tut es nicht. Scheitert bei mir in Codeblocks am Build jl_init(); "undefined reference to '__imp_jl_init' Habe nun alle mir erdenklichen Versuche unternommen und immer wieder Build failed Ich geb's auf.
Verwirrter schrieb: > Habe nun alle mir erdenklichen Versuche unternommen Auch einmal die Analyse der Symboltabelle der zugehörigen Bibliothek?
Jörg W. schrieb: > Verwirrter schrieb: > Habe nun alle mir erdenklichen Versuche unternommen > > Auch einmal die Analyse der Symboltabelle der zugehörigen Bibliothek? Ich hab halt die beiden Libs eingebunden, die in der Installatons-Exe mitgeliefert werden. Von einer libstdc++.so.6 wie angegeben ist da nichts vorhanden. Gruß
Verwirrter schrieb: > Von einer libstdc++.so.6 wie angegeben ist da nichts vorhanden. Die würde auch zu deinem Compiler gehören – allerdings wird das dir fehlende __imp_jl_init da ganz gewiss nicht enthalten sein.
Verwirrter schrieb: > Installatons-Exe Verwirrter schrieb: > libstdc++.so.6 .so ist unter Linux das was eine .dll unter Windows und eine .dylib unter Mac OS ist. Das kann also so nicht gehen, denn du scheinst Windows zu verwenden. Da steht aber auch direkt am Anfang: > Note: This section covers embedding Julia code in C on Unix-like operating > systems. For doing this on Windows, please see the section following this.
Stefanus F. schrieb: > Ich programmiere seit 30 Jahren. Dabei habe ich folgende > "Weisheit" > gelernt: Weisheit kann man nicht erlernen, sondern nur erlangen.
Hui Pong schrieb: >> Ich programmiere seit 30 Jahren. Dabei habe ich folgende "Weisheit" gelernt: > Weisheit kann man nicht erlernen, sondern nur erlangen. Und wie kommt die Weisheit dann in meinen Schädel? Sie wird wohl kaum bei Zeiten vom Himmel fallen.
Die Julia, ja die hätte ich früher gerne mal 'verwendet'. Aber leider wollte sie nicht :-(
Christopher J. schrieb: > Verwirrter schrieb: >> Installatons-Exe > > Verwirrter schrieb: >> libstdc++.so.6 > > .so ist unter Linux das was eine .dll unter Windows und eine .dylib > unter Mac OS ist. Das kann also so nicht gehen, denn du scheinst Windows > zu verwenden. > > Da steht aber auch direkt am Anfang: >> Note: This section covers embedding Julia code in C on Unix-like operating >> systems. For doing this on Windows, please see the section following this. Das ist mir schon klar. Ich habe auch keine libstdc++.so.6 die ich sowieso nicht habe versucht einzubinden, sondern die mitgelieferten libjulia.dll.a libopenlibm.dll.a Trotzdem scheitert der Linkvorgang. Keine Ahnung warum. Ich habe auch die Nase voll von Zeugs das mal wieder anscheinend primär für Linux gestrickt zu sein scheint. Ich bin halt kein 8-our-a-Day-Coder. Für mich muss das out of the box funktionieren oder so beschrieben sein, dass man ohne Hirnverrenkungen und GCC Studium das ganze zum Laufen bekommt. Sonst lass ich es einfach so lange links liegen, bis der Schrott mal so beschrieben ist, dass es mit - Include VZ hinzufügen - Libs VZ hinzufügen - vielleicht noch libs einbinden läuft. DAS Gekrampfe hier https://discourse.julialang.org/t/embedding-windows-binaries/3352 brauche ich nicht. Julia braucht Nutzer. Ich im Umkehrschluss kann auch auf anderes ausweichen.
M.A. S. schrieb: > Sie soll (sehr grob gesagt) das beste aus Matlab und Python vereinen... Und wieder so eine Eintagsfliege. Was man davon halten darf, erschließt sich aus dem Anfang der "Dokumentation": "Julia 1.0 Documentation Welcome to the documentation for Julia 1.0. Please read the release blog post for a general overview of the language and many of the changes since Julia v0.6. Note that version 0.7 was released alongside 1.0 to provide an upgrade path for packages and code that predates the 1.0 release. The only difference between 0.7 and 1.0 is the removal of deprecation warnings. For a complete list of all the changes since 0.6, see the release notes for version 0.7 Introduction Scientific computing has traditionally required the highest performance,... " .. in diesem Stil geht es seitenweise weiter, dann kommen "Beispiele" wie dieses:
1 | $ julia |
2 | |
3 | _
|
4 | _ _ _(_)_ | Documentation: https://docs.julialang.org |
5 | (_) | (_) (_) | |
6 | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. |
7 | | | | | | | |/ _` | | |
8 | | | |_| | | | (_| | | Version 1.0.0 (2018-08-08) |
9 | _/ |\__'_|_|_|\__'_| | |
10 | |__/ | |
11 | |
12 | |
13 | julia> 1 + 2 |
14 | 3
|
15 | |
16 | julia> ans |
17 | 3
|
Geht's noch? Sieht SO etwa die Dokumentation zu einer Programmiersprache aus? Also mal wieder eine Sprachdokumentation aus der PR-Abteilung. Danke, auch für diesen Versuch hab ich keine Verwendung. Leute, die ihr tolles Produkt nicht sachgerecht zu beschreiben wissen, haben auch kein tolles Produkt erfunden, sondern nur eine weitere Krücke fabriziert. W.S.
Wenn Du Dir einen Bleistift kaufst, erwartest Du wohl auch, dass man Dir ein Wörterbuch gratis dazu gibt? Aber nein, Bleistift kostest ja ein paar Cent, die Sprache und alles was dazu gehört soll ja selbstverständlich kostenlos sein. Dokumentation ist natürlich wichtig, aber bei einer noch sehr jungen Sprache sehr viel Zeit in perfekte Dokumentation stecken? Liest ja meist eh kaum jemand, und für Version 2.0 kann man dann fast alles neu schreiben. Aber augenscheinlich gibt es ja nicht nur Deppen, denn die Anzahl der begeisterten Julia-Nutzer ist ja schon recht groß. Und nein, ich gehöre (noch) nicht dazu, ich beschäftige mich allerdings mit anderen modernen Sprachen.
Verwirrter schrieb: > Sonst lass ich es einfach so lange links liegen, bis der Schrott mal so > beschrieben ist Ich denke, mal, Leute mit der Grundeinstellung will sowieso keiner haben. Die will man eigentlich nichtmal dann haben, wenn sie als $KUNDE was dafür bezahlen, wenngleich man sie in diesem Falle wohl oder übel bedienen muss.
Jörg W. schrieb: > Verwirrter schrieb: >> Sonst lass ich es einfach so lange links liegen, bis der Schrott mal so >> beschrieben ist > > Ich denke, mal, Leute mit der Grundeinstellung will sowieso keiner > haben. Die will man eigentlich nichtmal dann haben, wenn sie als $KUNDE > was dafür bezahlen, wenngleich man sie in diesem Falle wohl oder übel > bedienen muss. Danke für die Blumen. Dann darf ich dir erwidern, Leute, die meine vielen Stunden die ich nun in den Mist mal wieder umsonst investiert habe mit solch einer Verächtlichmachung kommentieren, brauche ich in meiner Umgebung nicht. Die können mir gestohlen bleiben und ihre mies kommentierte Software gleich mitnehmen. Ich hab mir die libjulia mittels der VS Tools dumpbin.exe, lib.exe und ein bisschen Handarbeit als .lib neu gestrickt und erhalte das gleiche Ergebnis und das sowohl in CB als auch in VC. Nun habe ich endgültig keine Lust mehr auf diese typische "mit Linux geht's" Scheiße. Außer Dummsprüchen über "Julia" und dem typischen Foren Aggressionsmuster gegen Leute die sich mal wieder frustriert von halbgarer SW abwenden MÜSSEN hat dieses Forum hier wie üblich nichts zu bieten.
Verwirrter schrieb: > … den Mist … Dummsprüchen … Genau solche „Dummsprüche“ meine ich. Selbsterfüllende Prophezeiung gewissermaßen. Ich habe mir Julia nicht näher angesehen und es auch nicht getestet (weil numerische Mathematik nicht mein Arbeitsfeld ist, Julia sich aber offenbar genau das als Ziel gesetzt hat). Mich nervt nur diese Mentalität, bei der schon alles auf dem silbernen Tablett geliefert werden muss, damit König „Kunde“ es dann vielleicht gegebenenfalls eventuell irgendwann in Betracht ziehen würde … wenn's nicht geht, hat man natürlich „alles“ unternommen, nur leider geht's doch nicht. Die blöden Linux-Heinis halt wieder. Hat man ja eigentlich schon vorher gewusst. Selbsterfüllende Prophezeiung?
Jörg W. schrieb: > Verwirrter schrieb: > >> … den Mist … Dummsprüchen … > > Genau solche „Dummsprüche“ meine ich. Dann schau mal in die anderen Beiträge hier! "Die Julia, ja die hätte ich früher gerne mal 'verwendet'. Aber leider wollte sie nicht :-(" Das scheint bei dir wohl nicht unter Dummsprüchen zu laufen wie? Moby habt ihr aus dem Forum gekickt wegen Störerei und dessen "Störeinfluss" war bestimmt einiges intelligenter und fachnäher als diese Störer-Sprüchlein weiter oben. > Selbsterfüllende Prophezeiung gewissermaßen. Genau. Das Forum erfüllt sich seinen Ruf immer wieder selbst. Da kann man buchstäblich drauf warten, insbesondere dann, wenn die Forenflegel bereits vollumfänglich saturiert sind. Da kann man dann auch gleich in den ersten Beiträgen nach dem TE mal versuchen den Thread ins Abseits zu führen mit sowas wie "ach, wieder ne Sau durchs Dorf getrieben" oder "hab doch bereits mein Python", so dass der TE regelrecht um seinen Thread kämpfen muss .. Und NEIN, NICHT ich habe ihn torpediert .. > Ich habe mir Julia nicht näher angesehen und es auch nicht getestet Das liebe ich besonders. Andere von oben herab abkanzeln und selber dabei nicht mal einen Mückenschiss am Thema selbst gearbeitet. Auch das ist hier ein sich stetig wiederholendes Muster. > (weil numerische Mathematik nicht mein Arbeitsfeld ist Meines auch nicht. Ich brauche es auch überhaupt nicht. Ich wollte es halt mal von C aus antesten. Versuch gescheitert. > .. Mich nervt nur diese > Mentalität, bei der schon alles auf dem silbernen Tablett geliefert > werden muss, Ich habe mehr als 10 Stunden mit diesem vermutlich lapidaren Drecksproblem vergeudet, bloß weil keiner der Herrschaften anscheinend sich mal die Mühe gemacht hat solche Fehlerquellen auszutesten. Und warum? Wahrscheinlich weils unter Linux läuft und läuft und läuft. Also alles klar auf der Andrea Doria für die Herren. SOWAS nervt MICH! > damit König „Kunde“ es dann vielleicht gegebenenfalls > eventuell irgendwann in Betracht ziehen würde … Dafür ist es doch da. Was denn sonst! Wie alle Emporkömmlinge buhlt auch Julia um möglichst breite Bekanntheit, sonst droht die vorschnelle Versenkung in den Orkus der "da war doch mal so ein Tool, wie hieß das noch gleich"-Geschichte .. > wenn's nicht geht, hat > man natürlich „alles“ unternommen, nur leider geht's doch nicht. Nein, ich habe nicht "alles" unternommen. Ich hätte noch - mir alle Visual Studio Versionen von der Platte putzen und wieder neu aufspielen können (dauert gefühlt einen Tag, vermutlich länger) - in irgendwelchen anderen Foren wild herumposten können in der Hoffnung eines Zufallstreffers (dauert ebenfalls Stunden, Ausgang ungewiss, 90% der Antworten sind nur Müll) - hier untertänigst um Hilfe winseln können, bis sich einer der Witzbolde mal selber die Mühe macht Julia von C aus eingebunden erfolgreich zu kompilieren, um mir dann "Inkompetenz", "Dummheit", "Lesefaulheit" vorzuhalten. Natürlich ohne GENAU und NACHVOLLZIEHBAR offenzulegen wie er es geschafft hat. Das würde ja den Schmäh, die Häme schmälern .. > Die > blöden Linux-Heinis halt wieder. Hat man ja eigentlich schon vorher > gewusst. Nein, hab ich nicht vorher gewusst. Ganz und gar nicht. Ich ging davon aus, dass so eine Kleinigkeit binnen einer Tasse Kaffee erfolgreich über die Bühne zu bringen ist, sonst hätte ich es gar nicht angefangen, weil ich besseres zu tun habe. Leider habe ich mich geirrt. Vermutlich geht's bei anderen komischerweise auch sofort. Das würde mich nicht wundern. Hilft aber nicht. Letztlich ist es egal, denn ich brauche Julia nicht fürs Rechnen. Da gibt es genügend andere, bequemere, weil besser mit bekannten Programmiersprachen verzahnte Tools die auch funktionieren bzw. bei denen ich sehr viel größere Chancen habe wenn ich auf Probleme stoße, dass diese bereits hinreichend beleuchtet sind, so dass man nicht derart im Dunklen tapp wie in diesem Fall hier.
Verwirrter schrieb: > Ich habe mehr als 10 Stunden mit diesem vermutlich lapidaren > Drecksproblem vergeudet, bloß weil keiner der Herrschaften anscheinend > sich mal die Mühe gemacht hat solche Fehlerquellen auszutesten. Und > warum? Wahrscheinlich weils unter Linux läuft und läuft und läuft. Also > alles klar auf der Andrea Doria für die Herren. SOWAS nervt MICH! Bitte entschuldige, aber wenn etwas für uns läuft, reicht uns das. Da kannst Du moppern soviel Du willst. ;-)
Stefanus F. schrieb: > Hui Pong schrieb: >> Weisheit kann man nicht erlernen, sondern nur erlangen. > > Und wie kommt die Weisheit dann in meinen Schädel? Sie wird wohl kaum > bei Zeiten vom Himmel fallen. Die Erkenntnis ereilt nicht jeden. Manche erlangen sie, andere nicht.
Neben den üblichen Foren-Nervereien ist mir aber immer noch der Aspekt mit dem "angesiedelt zwischen Python und Matlab" zu kurz gekommen. Ich weiß nicht, wie es euch geht, aber bei mir kommen die Sprach-Eigenschaften bei einer Entwicklung mittlerweile an der zweiten Stelle. Wichtiger ist die Infrastruktur. Hier liegen die Entscheidungen Matlab vs. Python bei einem neu aufzubauenden Werkzeug an ganz anderen Ecken: * Muß (evtl.) auf den Großrechner -> Matlab/Fortran * Muß auch an viele andere weitergegeben werden -> Python/Fortran * Muß einmalig Daten auswerten, dann evtl. in 10 Jahren wieder -> Matlab * Geht in den Automotive-Bereich und ist Teil einer Zertifizierung -> Matlab * (Baut auf Library/Toolbox auf, die nur in einem Teil erhältlich ist -> klar) * Wird ein ausführbares Kommandozeilenwerkzeug -> Python/Fortran * Die schnelle Datenvisualisierung für zwischendurch -> Matlab * Wird ein aufwendiges Programm, das ernsthafte Architekturentscheidungen verlangt -> Wahl der Sprache ist Teil dieser Entscheidung * Wird Webtool -> Python * Look-up-Table-Füller -> Matlab/Python (Das alte Fortran spielt manchmal durchaus auch mit - das beste Beispiel, daß es nicht der Sprachstandard selbst ist, der eine Programmiersprache verwendbar macht.)
Sheeva P. schrieb: > aber wenn etwas für uns läuft, reicht uns das Eben die typische "works for me" Mentalität. Aber dann rumjammern, dass euch keiner ernstnimmt.
Verwirrter schrieb: > Das scheint bei dir wohl nicht unter Dummsprüchen zu laufen wie? Doch, daher vergebe ich für sowas (was ich sonst selten mache) auch Negativbewertungen. > Ich brauche es auch überhaupt nicht. Ich wollte es halt mal von C aus antesten. 10 Stunden lang? Wenn ich mir das Konzept von Julia ansehe (und den von dir verlinkten Forenthread), dann wird mir übrigens ziemlich schnell klar, dass das, was du da willst/erwartest, sehr wahrscheinlich nicht mit dem Konzept zusammenpasst: sie haben ein Tool geschrieben, das auf LLVM aufsetzt, und nur damit kann es seine Vorteile überhaupt ausreizen. Das passt dann eben nicht zu einem x-beliebigen anderen Compiler. Nicht GCC, nicht Visual C. https://de.wikipedia.org/wiki/LLVM Walter T. schrieb: > Hier liegen die Entscheidungen Matlab vs. Python bei einem neu > aufzubauenden Werkzeug an ganz anderen Ecken Was natürlich (vor allem für kleinere Unternehmen oder gar Hobby) bei Matlab schon eine Rolle spielen kann, ist der Preis. Der ist exorbitant.
:
Bearbeitet durch Moderator
W.S. schrieb: > Was man davon halten darf, erschließt sich aus dem Anfang der > "Dokumentation": So unterschiedlich sind die Menschen: Die einen (wie Du) beurteilen ein Buch nach dem Vorwort, die anderen (wie ich) fangen gleich im Haupttext an und lesen das Vorwort gar nicht. Viel habe ich noch nicht gemacht mit Julia aber für alle meine bisherigen Versuche war die Online-Doku durchaus brauchbar.
:
Bearbeitet durch User
Jörg W. schrieb: > Was natürlich (vor allem für kleinere Unternehmen oder gar Hobby) bei > Matlab schon eine Rolle spielen kann, ist der Preis. Der ist exorbitant. "Exorbitant" war der Preis - was das Hobby angeht - mal. Früher™, bevor es die "Matlab-Home"-Lizenz gab, war die günstigste Lizenz bei 1000,- Euro (ohne Toolboxen). Jetzt gibt es zum Glück seit 2014 und eine "Matlab Home"-Lizenz. Jetzt ist der Preis für den Hobbyisten nur noch hoch, nicht mehr exorbitant. Aber klar: Die Kosten für die Arbeitsplatzlizenz spielen eine gewaltige Rolle bei Tools, die nicht nur für mich sind.
:
Bearbeitet durch User
Jörg W. schrieb: > Walter T. schrieb: >> war die günstigste Lizenz bei 1000,- Euro (ohne Toolboxen) > > Pro Jahr, oder? Sorry, ich lag falsch: Es waren 2000,- Euro (sind es immer noch) für eine Dauerlizenz + x Prozent Maintenance/Jahr (ich glaube es waren 25%/Jahr), wenn man das wünschte. Heute: https://de.mathworks.com/pricing-licensing.html Definitiv kein Schnäppchen, aber für etliche Anwendungen ist es eben das Mittel der Wahl.
Walter T. schrieb: > Christopher J. schrieb: >> Immerhin sind die Fehlermeldungen aussagekräftig. Das kenne ich von >> Matlab auch anders. > > Bitte ein Beispiel! Um direkt die Fehlermeldungen zu vergleichen:
1 | >> 2**4 |
2 | 2**4 |
3 | | |
4 | Error: Unexpected MATLAB operator. |
5 | |
6 | >> 2^4 |
7 | |
8 | ans = |
9 | |
10 | 16 |
11 | |
12 | >> |
Ich hatte aber schon wirklich fiese Fehlermeldungen. Das hängt natürlich damit zusammen, dass bei Matlab sehr viele Dinge implizit ablaufen, was an mancher Stelle natürlich ganz nett ist aber an anderer Stelle einem sehr sauer aufstoßen kann.
Christopher J. schrieb: >>> 2**4 > 2**4 > | > Error: Unexpected MATLAB operator. Das klingt für mich sehr aussagekräftig. Bei anderen nicht-existenten Operatoren ist es sogar noch aussagekräftiger:
1 | >> a+=1 |
2 | a+=1 |
3 | | |
4 | Error: The expression to the left of the equals sign is not a valid target for an assignment. |
5 | |
6 | Did you mean: |
7 | >> a = a + 1 |
oder:
1 | >> a = "lala" |
2 | a = "lala" |
3 | | |
4 | Error: The input character is not valid in MATLAB statements or expressions. |
Für mich wird hier der unbedarfte Programmierer mit weißen Samthandschuhen angefasst.
Walter T. schrieb: >> Error: Unexpected MATLAB operator. > > Das klingt für mich sehr aussagekräftig. Ist aber eben lahm im Vergleich zur oben zitierten Fehlermeldung von Julia:
1 | ERROR: syntax: use "^" instead of "**" |
Nur darum ging's ja …
Jörg W. schrieb: > Ist aber eben lahm im Vergleich zur oben zitierten Fehlermeldung von > Julia: Ah....steckt in dem Bild. Habe ich übersehen. Ja, die Fehlermeldung ist noch ein Stück besser.
Ernstl schrieb: > Sheeva P. schrieb: >> aber wenn etwas für uns läuft, reicht uns das > > Eben die typische "works for me" Mentalität. Aber dann rumjammern, dass > euch keiner ernstnimmt. Es ist nicht unsere Aufgabe, Euch das Gesäß nachzutragen, und Windows ist nicht unsere wichtigste Plattform. Wenn Ihr unsere Arbeit schon geschenkt bekommt, könnt Ihr durchaus selbst ein bisschen beitragen -- zum Beispiel durch Bugreports an das Projekt, nicht durch anonymes Gemoser in Foren wie diesem. OpenSource lebt nicht von Moserlieschen, sondern von Mitmachern. Angesehen davon sind wir zufrieden, wenn die wichtigen Leute und ernst nehmen. Ob Du dazu gehörtst, bleibt ganz Dir selbst überlassen. ;-)
Jörg W. schrieb: > Selbsterfüllende Prophezeiung gewissermaßen. Jörg, komm wieder runter. Die Sache geht nämlich anders. Ganz anders. Wenn jemand eine neue Programmiersprache erfindet, dann MUSS er selbige schön der Reihe nach dokumentieren, sonst wird daraus eben nie und nimmer etwas. Und das muß sachlich sein, von der Pike auf. Aber das, was man wohl heutzutage und im besonderen hier bei dieser Sprache zu lesen kriegt, ist eine Flut von Gelaber und Selbstlob - aber keine Sprachdokumentation. Ich hatte genau DAS schon mal bei Rust angemahnt, aber offensichtlich wollen die Erfinder und Fanboys immerzu nur schreien "wir sind die Allergrößten und unsere Erfindung ist das Super-Duper-Allergrößte seit der Erfindung des Hebelgesetzes". Und anschließend zeigen sie eine Art "Hello World", woraufhin sie annehmen, daß damit ja bereits das Wichtigste gesagt sei. MITNICHTEN. Wer seine Erfindung derart präsentiert, outet sich als ein verdrehter Chaot. Und wer dann noch schreibt (sinngemäß): "Leute, die Kritik üben oder denen unsere heißgeliebte Erfindung nicht schmeckt, brauchen wir nicht!" Ähemm... Leute die aus Mutwillen sich eine neue Programmiersprache ausdenken, brauchen keine wirklichen Benutzer, sie sind sich selbst genüge. Das ist ja soweit völlig OK, aber es ist bedeutet für den Rest der Welt nichts. Eine echte Dokumentation sieht ganz anders aus. Sie würde mit dem Anfang beginnen, etwa so: - klären, ob die Sprache case-sensitiv ist - klären, ob die Sprache formatfrei ist (Fortran und Python sind es nicht) - klären, ob es sich um eine imperative oder deskriptive Sprache handelt - klären, ob es ein Modul-Konzept gibt und wie es aussieht - den grundlegenden Programmaufbau beschreiben - bei imperativen Sprachen: den Kanon der Anweisungen beschreiben, bei deskriptiven Sprachen den Kanon der Deskriptionen beschreiben - Schlüsselworte und Grammatik beschreiben - .. und so weiter. W.S.
Amen, so sehe ich das auch. Ich habe schon zu viele selbst-gelobte Programmiersprachen kommen und gehen sehen, um darauf herein zu fallen. Insbesondere die Sprachen, die auf einen bestehenden Compiler oder Laufzeit-Bibliothek und VM aufbauen habe ich noch nie ernst nehmen können. Ich weiß schon gar nicht mehr, wie viele Java Aufsätze es inzwischen gegeben hat. Keiner davon ist weit gekommen. In der Praxis ist auch durchaus von Interesse, welche IDE sie unterstützt. Gibt es einen integrierten Debugger? Gibt es einen Profiler? Mit welchen Tools kann man das Laufzeitverhalten analysieren und Performance-Engpässe analysieren? Wer garantiert Langzeit-Support für Security Patche?
Sheeva P. schrieb: > Angesehen davon sind wir zufrieden, wenn die wichtigen Leute und ernst > nehmen. Von was Du so alles träumst...
W.S. schrieb: > Und anschließend zeigen sie eine Art > "Hello World", woraufhin sie annehmen, daß damit ja bereits das > Wichtigste gesagt sei. MITNICHTEN. Da gebe ich dir grundsätzlich recht, aaaber W.S. schrieb: > Eine echte Dokumentation sieht ganz anders aus. Sie würde mit dem Anfang > beginnen, etwa so: > - klären, ob die Sprache case-sensitiv ist > - klären, ob die Sprache formatfrei ist (Fortran und Python sind es > nicht) > - klären, ob es sich um eine imperative oder deskriptive Sprache handelt > - klären, ob es ein Modul-Konzept gibt und wie es aussieht > - den grundlegenden Programmaufbau beschreiben > - bei imperativen Sprachen: den Kanon der Anweisungen beschreiben, bei > deskriptiven Sprachen den Kanon der Deskriptionen beschreiben > - Schlüsselworte und Grammatik beschreiben > - .. und so weiter. Das sehe ich grundsätzlich anders. case-insensitive? Ernsthaft? Wir sind im Jahr 2018 und Visual Basic wird bald hoffentlich in den ewigen Jagdgründen verschwinden. Die Zielgruppe von Julia sind Ingenieure und Naturwissenschaftler, keine Informatiker. Ein Maschinenbauer interessiert sich mitnichten für irgendeine Grammatik einer Programmiersprache. Der will seine Versuchsdaten auswerten und vielleicht noch ordentlich darstellen. Für solche Leute ist in der Doku alles drin. Da wird zuerst erklärt wie man Variablen Werte zuweißt, was für Datentypen es gibt und wie man damit rechnet, also genau das was die Leute eben brauchen. Mal abgesehen davon ist Julia von der Syntax her sehr ähnlich zu Matlab. Nebenbei bemerkt: Ein gewisser Alan Edelman, Professor für angewandte Mathematik am MIT und erster kommerzieller Kunde von Mathworks, ist einer der Hauptinitiatoren hinter der Sprache. Stefanus F. schrieb: > Ich habe schon zu viele selbst-gelobte Programmiersprachen kommen und > gehen sehen, um darauf herein zu fallen. Ich habe schon zu viele Leute gesehen, die über irgendwelche Dinge urteilen, die sie noch nie genauer betrachtet haben. > Insbesondere die Sprachen, die auf einen bestehenden Compiler oder > Laufzeit-Bibliothek und VM aufbauen habe ich noch nie ernst nehmen > können. Hinter Clang/LLVM steckt Apple und die werden so schnell wohl nicht verschwinden. > Wer garantiert Langzeit-Support für Security Patche? Da bist du meiner Meinung nach auf dem völlig falschen Dampfer. Julia ist kein Ersatz für Java und will auch keiner sein. Man kann theoretisch mit Julia einen Webserver schreiben aber dafür ist die Sprache nicht gedacht. > In der Praxis ist auch durchaus von Interesse, welche IDE sie > unterstützt. Juno, ein Atom Plugin, macht Atom zu einer vollintegrierten Julia-IDE. Ansonsten tut es auch prinzipiell jeder Text-Editor. > Gibt es einen integrierten Debugger? Ja, gibt es. Bei Juno ist der mit dabei. http://junolab.org/ > Gibt es einen Profiler? Selbstverständlich. Der ist auch standardmäßig mit dabei: https://docs.julialang.org/en/v1/manual/profile/ In Juno ist der Profiler auch ordentlich integriert, zwecks Visualisierung der Ergebnisse.
Gut zu wissen. Ich wollte auch nicht behaupten, dass Julia keine IDE/Debugger/Profiler hat, sondern hervorheben, dass das für mich wichtige Entscheidungsfaktoren sind.
W.S. schrieb: >> Selbsterfüllende Prophezeiung gewissermaßen. > > Jörg, komm wieder runter. > Die Sache geht nämlich anders. Ganz anders. > > Wenn jemand eine neue Programmiersprache erfindet, dann MUSS er selbige > schön der Reihe nach dokumentieren, sonst wird daraus eben nie und > nimmer etwas. Dagegen habe ich doch gar nichts gesagt. Ist die Frage, ob die Dokumentation tauglich ist oder nicht. Vom ersten Reinlesen (also mal "Introduction" und "Getting started" übersprungen) finde ich sie durchaus praktikabel. Auch die von dir gewünschte Case sensitivity ist da erwähnt. Vielleicht installiere ich mir das einfach mal und gucke mal, ob ich damit zurecht käme – wirkliche numerische Probleme habe ich nicht, um mehr testen zu können. Wenn aber jemand mit der Einstellung „Alles Mist“ an die Sache bereits rangeht, dann ist klar, wie das Ergebnis aussieht. (Davon abgesehen, hatte ich ja oben noch angemerkt, dass das Ansinnen der Integration in MSVC meiner Meinung nach ohnehin nicht mit dem Ansatz von Julia zusammenpassen kann.)
Mal nebenher: Was raucht man eigentlich, um eine Sprache "Julia" zu nennen? Wenn ich nach deutschen Julia Tutorials suche, bekomme ich bestenfalls Schminktipps bei Youtube.
Karl schrieb: > Mal nebenher: Was raucht man eigentlich, um eine Sprache "Julia" zu > nennen? Ich habe mal ein Terminal-Programm "Anita" genannt. Mein Plan war, dass das nächste Programm "Berta" heißen sollte, das dritte irgendwas mit C und so weiter. Ich habe die dumme Idee dann aber doch nicht fortgesetzt. Anita blieb alleine.
Karl schrieb: > Mal nebenher: Was raucht man eigentlich, um eine Sprache "Julia" zu > nennen? Wenn ich nach deutschen Julia Tutorials suche, bekomme ich > bestenfalls Schminktipps bei Youtube. Finde den Namen übrigens auch unglücklich, genau aus diesem Grund. Ist bei Go aber mindestens genauso schlimm. Dennoch mag ich beide Sprachen und spätestens von Go weiß man, dass man einfach ein "lang" an den Namen hängen muss, -> Golang, Julialang, etc.
Stefanus F. schrieb: > das dritte irgendwas mit C > und so weiter. Die Idee hatten andere aber auch schon für einen Makroassembler, und ein Name mit C ist ihnen dann nicht eingefallen... ;-)
Jörg W. schrieb: > Ist die Frage, ob die Dokumentation tauglich ist oder nicht. Bin da erstmal nur ein Stückchen durch. Sowohl die Sprache als auch die Dokumentation sind recht umfangreich. Über fehlende Doku muss sich also gewiss keiner beklagen. Hat viele interessante Dinge, auch wenn ich für vieles erstmal selbst keine Anwendung habe. Nett sieht es natürlich aus, wenn man in Zeiten von Unicode / UTF-8 für eine Quadratwurzel auch direkt √ schreiben kann oder die Zahl π als solche benutzen kann. Man würde sich natürlich wünschen, mehr davon als bislang direkt auf der Tastatur zu erreichen. ;-) Interessant fand ich:
1 | julia> x=3.1415926 |
2 | 3.1415926 |
3 | |
4 | julia> zero(x) |
5 | 0.0 |
(zero() gibt eine 0 mit gleichem Datentyp wie sein Argument.) Aber:
1 | julia> x=pi |
2 | π = 3.1415926535897... |
3 | |
4 | julia> x |
5 | π = 3.1415926535897... |
6 | |
7 | julia> zero(x) |
8 | ERROR: MethodError: no method matching Irrational{:π}(::Int64) |
9 | Closest candidates are: |
10 | Irrational{:π}(::T<:Number) where T<:Number at boot.jl:725 |
11 | Irrational{:π}() where sym at irrationals.jl:18 |
12 | Irrational{:π}(::Complex) where T<:Real at complex.jl:37 |
13 | ... |
14 | Stacktrace: |
15 | [1] convert(::Type{Irrational{:π}}, ::Int64) at ./number.jl:7 |
16 | [2] oftype(::Irrational{:π}, ::Int64) at ./essentials.jl:323 |
17 | [3] zero(::Irrational{:π}) at ./number.jl:262 |
18 | [4] top-level scope at none:0 |
D.h., irrationale Zahlen besitzen einen eigenen Datentyp.
Einige Examples aus der Julia Dokumentation (Lineare Algebra] getestet vorerst mit octave: octave:1> A=[-4 -17;2 2] A = -4 -17 2 2 octave:2> inv(A) ans = 0.076923 0.653846 -0.076923 -0.153846 octave:3> det(A) ans = 26 octave:4> eig(A) ans = -1.0000 + 5.0000i -1.0000 - 5.0000i octave:5> Dann Eingabe in Julia (laut Doku] : julia> A=[-4. -17.;2. 2.] 2×2 Array{Float64,2}: -4.0 -17.0 2.0 2.0 julia> inv(A) 2×2 Array{Float64,2}: 0.0769231 0.653846 -0.0769231 -0.153846 julia> det(A) ERROR: UndefVarError: det not defined Stacktrace: [1] top-level scope at none:0 julia> eigvals(A) ERROR: UndefVarError: eigvals not defined Stacktrace: [1] top-level scope at none:0 Glaube nicht das ich mich länger damit beschäftige.
R. M. schrieb: > julia> det(A) > ERROR: UndefVarError: det not defined > Stacktrace: > [1] top-level scope at none:0 > > julia> eigvals(A) > ERROR: UndefVarError: eigvals not defined > Stacktrace: > [1] top-level scope at none:0
1 | julia> using LinearAlgebra |
2 | |
3 | julia> det(A) |
4 | 26.0 |
5 | |
6 | julia> eigvals(A) |
7 | 2-element Array{Complex{Float64},1}: |
8 | -1.0 + 5.0im |
9 | -1.0 - 5.0im |
Du hast übersehen, dass det() und eigvals() zum Modul LinearAlgebra gehören (genau dort steht dein zitiertes Beispiel nämlich in der Doku). Interessant wäre ja an dieser Stelle nun ein Geschwindigkeitsvergleich zwischen Octave und Julia für eine etwas komplexere derartige Operation. Dass es beide können, stand eigentlich nicht im Zweifel, Julias Anspruch ist ja, durch das Aufsetzen auf LLVM schnell zu sein (und Octave ist ja nicht gerade für gute Performance berühmt).
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Modul LinearAlgebra gehören (genau dort steht dein zitiertes Beispiel > nämlich in der Doku). Danke. Aber wie sieht man das aus der Doku? Da steht: In addition to (and as part of) its support for multi-dimensional arrays, Julia provides native implementations of many common and useful linear algebra operations. Basic operations, such as tr, det, and inv are all supported: Dass sich das auf eine Modul bezieht sieht man zumindest auf dem Handy nicht. Oder sind da alle Kapitelueberschrifte Modulnamen?
Dumdi D. schrieb: > Oder sind da alle Kapitelueberschrifte Modulnamen? Da sie unter „Standard Library“ stehen, sind sie das offenbar. Ich gebe dir Recht, dass man das etwas offensichtlicher darstellen könnte. Rechts oben ist ein Link „Edit on Github“, vielleicht sollte man einfach mal selbst Hand anlegen, bspw. über jede Bibliotheksmodul-Doku ein „using Blahblah“ setzen? Nachdem ich erkannt hatte, dass es sich um Bibliotheksmodule handelt, war es in der (allgemeinen) Beschreibung zu Modulen schnell zu finden, dass man sie mit „using“ laden muss. Für den Rest tat es die dankenswerterweise prima funktionierende <TAB>-Erweiterung: „using Lin<TAB>“ genügt.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Interessant wäre ja an dieser Stelle nun ein Geschwindigkeitsvergleich > zwischen Octave und Julia für eine etwas komplexere derartige Operation. > Dass es beide können, stand eigentlich nicht im Zweifel, Julias > Anspruch ist ja, durch das Aufsetzen auf LLVM schnell zu sein (und > Octave ist ja nicht gerade für gute Performance berühmt). Ich habe meine Zweifel, dass es große Unterschiede gibt bei Dingen wie Eigenwerten und Determinanten, da vermutlich eh die LAPACK/BLAS Funktionen genutzt werden. Die Frage ist eher wie es bei komplexen Formeln aussieht. Wenn etwa
1 | f(x, y, z) = x + y^2 * sin(x+1) * cos(x-1) + exp(x+z) + x * y^2 |
berechnet werden soll, wenn x, y und z jeweils Vektoren oder Matrizen mit 10k Einträgen sind. Wieviele Hilfsarrays müssen erzeugt werden und wie oft wird implizit for(i=0; i<10000; ++i) ausgeführt. Und natürlich wie schnell sind for-Schleifen in julia? Vermutlich nicht die Python-Exception-Katastrophe. Dumdi D. schrieb: > Jörg W. schrieb: >> Modul LinearAlgebra gehören (genau dort steht dein zitiertes Beispiel >> nämlich in der Doku). > > Danke. Aber wie sieht man das aus der Doku? Da steht: > ... In dem man mehr von der Doku liest? Zum Beispiel den Teil, der sich mit der Sprache beschäftigt und nicht mit der Bibliothek. Oder kurz nach dem ziemlich eindeutigen Fehler "ERROR: UndefVarError: det not defined" googlen. Erklärung und Lösung waren bei mir im ersten Link zu finden.
mh schrieb: > Erklärung und Lösung waren bei mir im ersten Link zu finden. Unter welchem Pseudonym? Unter mh war das dein einzigster Post. Oder welchen ersten Link meinst Du? Den vom OP? M.A. S. schrieb: > https://julialang.org/ Das da irgendwo alles zu finden ist bezweifle ich nicht.
Dumdi D. schrieb: > Oder welchen ersten Link meinst Du? Der, den ihm die Suchmaschine ausgespuckt hat. So schwer war das ja nun wirklich nicht zu erraten aus seinem Posting … Allerdings finde ich schon, dass eine Suchmaschine kein Ersatz dafür sein sollte, dass die Doku dies selbst etwas offensichtlicher darstellt.
Jörg W. schrieb: > Dumdi D. schrieb: >> Oder welchen ersten Link meinst Du? > > Der, den ihm die Suchmaschine ausgespuckt hat. So schwer war das ja nun > wirklich nicht zu erraten aus seinem Posting … Allerdings finde ich > schon, dass eine Suchmaschine kein Ersatz dafür sein sollte, dass die > Doku dies selbst etwas offensichtlicher darstellt. Ja das erste Suchergebnis auf google. Klar könnte die Doku das besser machen. Aber eine Doku schreiben die für jeden funktioniert ist schwer. Zum Glück kann man jederzeit helfen und wenn es nur ein "verstehe ich nicht" ist und zum Glück hat das schon jm. in diesem Fall getan https://github.com/JuliaLang/julia/pull/29188
Gefällt mir schon besser. Doku lesen bringt was :-) . Brauch aber erst wieder einen vernünftigen Monitor. Positiv ist das die Indizierung von Arrays bei Julia mit [] erfolgt und nicht wie bei octave mit (). julia> using LinearAlgebra julia> A=[-4. -17.;2. 2.] 2×2 Array{Float64,2}: -4.0 -17.0 2.0 2.0 julia> l=eigvals(A) 2-element Array{Complex{Float64},1}: -1.0 + 5.0im -1.0 - 5.0im julia> v=eigvecs(A) 2×2 Array{Complex{Float64},2}: 0.945905+0.0im 0.945905-0.0im -0.166924-0.278207im -0.166924+0.278207im julia> A*v[:,1] - l[1]*v[:,1] 2-element Array{Complex{Float64},1}: 2.220446049250313e-16 + 0.0im 2.220446049250313e-16 + 0.0im julia> (A*v[:,2] - l[2]*v[:,2]) 2-element Array{Complex{Float64},1}: 2.220446049250313e-16 + 0.0im 2.220446049250313e-16 + 0.0im
Hallo ihr da zusammen, Ich schaue nur noch selten auf solche Seiten. Der Grund sind die gefühlten 1001 (Nacht) Sprachen. Es gibt nicht nur für jedes Problem einen speziellen Rechnerbaustein (ehemals CPU), sondern sogar noch eine speziell dafür geeignete Programmiersprache. Unterschiedliche Wörter für die gleiche Funktion. Statt Punkt ist Komma dran u.s.w. In den letzten Jahren ist viel Zeit draufgegangen um Funktionierende Programme in eine "neue" Sprache zu übersetzen oder auf eine andere CPU (anderen Kontroller)zu portieren. Das Dinglisch dient zur Abgrenzung vom gemeinen Volk und soll alles wichtiger erscheinen lassen. Wie das Latein in den alten Wissenschaften ist Dinglisch die ich bin was Besseres Sprache. Eine einfache und gut arbeitende Sprache würde in ca 90% der Probleme sicher ausreichen. Schon vor ca 30 Jahren bestanden meine letzten Basic Programme trotz Zeilennummerierung nur aus Funktionen (Gosub) und deren Aufrufe. C und C++ waren auch noch da. Das beste war aber das verständliche Exel-Basic in Deutsch. Nicht alle Menschen sind Fremdsprachenbegabt. Lieber wenige Sprachen, die dann aber auch gut beherscht werden. Ach so, 6510(6502) Maschinencode habe ich damals noch zu Fuß reassembliert. Also auch hier gilt mit sicherheit: "Weniger ist mehr" Nicht nach neuen bunten Schraubenziehern greifen, die Alten sind meist die besseren, da noch mit Verstang produziert.
Bernd Michael W. schrieb: > Ich schaue nur noch selten auf solche Seiten. Warum hat dich dann der Thread-Titel angesprochen? Ich würde mal sagen, genau für Leute wie dich war er doch nun gerade gar nicht gedacht, oder?
Bernd Michael W. schrieb: > Das beste war aber das verständliche Excel-Basic in Deutsch. Spätestens, wenn dein Programm dann auf einem Rechner in Indien laufen soll, merkst du, warum das eine ganz schlechte Idee war. Aber auch die Zusammenarbeit mit anderen Entwicklern, die nicht so gut Deutsch können, wird dadurch schwer behindert. Ich arbeite seit 20 Jahren in Deutschland mit guten Entwicklern zusammen. 30% von denen sprechen nur schlecht deutsch, manche gar nicht. Insofern ist für mich klar, dass eine vernünftige Programmiersprache unbedingt englisch sein muss. Ich habe mich auch schon lange daran gewöhnt, Dokumentationen, Kommentare und Variablen auf englisch zu schreiben. Bei der scheinbar unnötigen Vielfalt der Programmiersprache begrüße ich, dass die meisten sich Syntaktisch sehr ähneln. Die Hälfte von drei ist zum Beispiel 1.5 (nicht 1,5). Runde Klammern und Whitespaces sind gleichwertig. Zeichenketten werden immer zwischen Anführungs-Striche geschrieben, ">" bedeutet "größer als", usw. Das sind Dinge, die ich inzwischen als Selbstverständlich empfinde und für das Erlernen einer neuen Programmiersprache äußerst hilfreich sind. So und jetzt Feuer frei für die "ja aber ich kenne das eine Ausnahme" Kommentare. Sollen wir mit Python anfangen?
Hallo Jörg, ich weiß zwar nicht, was ein Faden-Titel ist, aber sicher ist das einer der Gründe warum mich das Thema angesprochen hat. Hallo Stefanus, aber genau das ist es doch, Dinglisch als Einheitssprache und beim Programmieren gibt es ein Sprachenkauderwelsch. Ist das nicht das komplette Gegenteil? Und dem laufenden Programm ist es egal, in welcher Sprache es erstellt wurde. Wichtig ist, dass es dem Anwender sinnvoll nutzt und nicht nur der Selbstbeweihräucherung. Übrigens, das Deutschbasic-Programm läuft auch noch Heute, selbst unter Libreoffice. Und auch die C Programme tuen es auch noch, sind nur nicht mehr Zeitgemäß. Ob nun eine große Schlange oder eine Julia oder ... zum schluss sind alles nur Einsen und Nullen. Ich wollte niemanden ärgern, viel Spass beim schreiben. Bernd
Bernd Michael W. schrieb: > Hallo Jörg, ich weiß zwar nicht, was ein Faden-Titel ist Es steht drüber "verwendet das hier jemand?", nicht "wer benutzt das alles nicht (und warum)?". Damit ist dein Beitrag für den Thread reichlich off-topic.
Bernd Michael W. schrieb: > Das beste war aber das verständliche > Exel-Basic in Deutsch. Nicht alle Menschen sind Fremdsprachenbegabt. Generell stimme ich Deinem Post ("es gibt zuviele Programmiersprachen für jeden Kleinkram") zwar zu - aber aber deutsche Schlüsselwörter sind ein Punkt, wo ich entschieden widersprechen muss. Das beste Beispiel ist Excel, wo die Funktionen in der deutschen Version deutsche Schlüsselwörter haben. Wenn ich eine deutsche Excel-Tabelle an jemanden mit einer englischen oder französischen Excel-Version weitergebe, freut der sich regelmäßig - nicht. Jede Programmiersprache ist ohnehin mit ihrer eigenen Syntax und Semantik eine eigene Fremdsprache.
Jörg W. schrieb: > Damit ist dein Beitrag für den Thread reichlich off-topic. Die Diskussion ist offensichtlich von ursprünglichen Thema abgekommen. Ist das Schlimm? Solange wir uns hier nicht persönlich beschimpfen, habe ich damit kein Problem.
Stefanus F. schrieb: > Ist das Schlimm? Ja. Sie ist nämlich erst durch deinen Beitrag tatsächlich von Julia abgekommen.
:
Bearbeitet durch Moderator
Bernd Michael W. schrieb: > Es gibt nicht nur für jedes Problem einen speziellen > Rechnerbaustein (ehemals CPU), sondern sogar noch eine > speziell dafür geeignete Programmiersprache. Du verkennst die Größe des Problems. Die Informatik ist noch nicht ausgereift, sondern steckt mitten in ihrer Jugend (vielleicht sollte man von den Flegel- jahren sprechen...). Es gibt daher noch keinen Wissenskanon wie etwa im Maschinenbau oder in der Elektrotechnik, der ist noch im Entstehen begriffen. Die Auffassung davon, wo die Schwerpunkte zu setzen sind, wandelt sich TATSÄCHLICH -- das ist nicht nur eine Schikane von Leuten, die Dir Übles wollen. > Unterschiedliche Wörter für die gleiche Funktion. Durchaus nicht. Tcl kennt auch "for" und "while" und die geschweiften Klammern -- trotzdem ist es Lichtjahre von C entfernt. > Das Dinglisch dient zur Abgrenzung vom gemeinen Volk > und soll alles wichtiger erscheinen lassen. Wie das > Latein in den alten Wissenschaften ist Dinglisch die > ich bin was Besseres Sprache. Du bist ja wohl kein Teamplayer. Wärst Du nämlich einer, dann wüsstest Du mit dem Begriff "lingua franca" etwas anzufangen.
Bernd Michael W. schrieb: > In den letzten Jahren ist viel Zeit draufgegangen um Funktionierende > Programme in eine "neue" Sprache zu übersetzen oder auf eine andere CPU > (anderen Kontroller)zu portieren. Mag sein aber genau das ist beispielsweise eine weitere Stärke von Julia. Man versucht eben nicht unnötig das Rad neu zu erfinden. Anbindungen an bestehende Programme und Bibliotheken die etwa in C, Fortran oder Python geschrieben sind, sind sehr einfach zu realisieren: https://docs.julialang.org/en/v1/manual/calling-c-and-fortran-code/ Wer möchte, kann sich etwa aus C-Headern mittels Clang.jl ein passendes Julia-Interface generieren lassen: https://github.com/ihnorton/Clang.jl Für Python gibt es Pycall.jl. Damit ist etwa Matplotlib (eigentlich in Python geschrieben) im Plots.jl-Paket angebunden. Der User bekommt überhaupt nicht mit, dass da Python-Code unter der Haube werkelt. https://github.com/JuliaPy/PyCall.jl
https://github.com/HSU-ANT/ACME.jl Ist ein interessanter Analog Schaltungs Simulator. Der Author bietet auch ein Atom Editor Plugin ab mit dem Julia schnell bedient werden kann.
Nach einigen Stunden Installation und Konfiguration: Der erste Plot mit Julia. julia> using PyPlot julia> using Astro julia> using Dates julia> days = Dates.datetime2julian.(Dates.DateTime(2018, 1, 1, 0, 0, 0):Dates.Day(1):Dates.DateTime(2018, 12, 31, 0, 0, 0)) 365-element Array{Float64,1}: 2.4581195e6 2.4581205e6 2.4581215e6 2.4581225e6 2.4581235e6 2.4581245e6 2.4581255e6 2.4581265e6 2.4581275e6 2.4581285e6 2.4581295e6 ⋮ 2.4584735e6 2.4584745e6 2.4584755e6 2.4584765e6 2.4584775e6 2.4584785e6 2.4584795e6 2.4584805e6 2.4584815e6 2.4584825e6 2.4584835e6 julia> eq_values = map(equation_time, days) 365-element Array{Float64,1}: -3.3761459607570696 -3.8435624873221 -4.305334065893277 -4.760992937609433 -5.210067159002485 -5.652078423236698 -6.086547905357899 -6.513005709504743 -6.930998885486687 -7.340095721687052 -7.739887082223417 ⋮ 2.106184196653158 1.612119025022231 1.1175961594028023 0.6231520477120679 0.12931865631830183 -0.363365291017872 -0.8543465297925285 -1.343057065891604 -1.8289211475254896 -2.3113652895117265 -2.7898268738437944 julia> plot(eq_values) 1-element Array{PyCall.PyObject,1}: PyObject <matplotlib.lines.Line2D object at 0x9533774c> julia>
Es gibt aktuell ein paar Neuerungen zu Julia und zwar gibt es nun einen offiziellen Interpreter (optional, anstelle JIT-Kompilierung) und einen offiziellen Debugger: https://julialang.org/blog/2019/03/debuggers
Walter T. schrieb: > Wie sieht das Beste aus beiden Welten aus? Alles eine Frage der Perspektive. wiw wäre das z.B. "Keinerlei echten Support, dafür teuer." Namaste
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.