Hat Julia Hoffnung, in der statistischen Community zu bleiben?

Ich habe kürzlich einen Beitrag von R-Bloggern gelesen, der mit diesem Blogbeitrag von John Myles White über eine neue Sprache namens Julia verlinkt ist . Julia nutzt einen Just-in-Time-Compiler, der unglaublich schnelle Laufzeiten liefert und die gleiche Größenordnung der Geschwindigkeit wie C / C ++ aufweist (die gleiche Reihenfolge , nicht gleich schnell). Darüber hinaus werden die orthodoxen Schleifenmechanismen verwendet, mit denen diejenigen von uns, die mit dem Programmieren in traditionellen Sprachen begonnen haben, vertraut sind, anstatt die Anweisungen und Vektoroperationen von R anzuwenden.

R wird auf keinen Fall verschwinden, auch mit solch tollen Timings von Julia. Es hat umfangreiche Unterstützung in der Industrie und zahlreiche wunderbare Pakete, um fast alles zu tun.

Meine Interessen sind bayesianischer Natur, wo Vektorisierung oft nicht möglich ist. Sicherlich müssen serielle Aufgaben unter Verwendung von Schleifen ausgeführt werden und erfordern bei jeder Iteration viel Rechenaufwand. R kann bei diesen seriellen Schleifentasks sehr langsam sein, und C / ++ ist kein Spaziergang im Park zum Schreiben. Julia scheint eine großartige Alternative zum Schreiben in C / ++ zu sein, steckt aber noch in den Kinderschuhen und es fehlen viele Funktionen, die ich an R liebe. Es wäre nur dann sinnvoll, Julia als rechnergestützte Statistik-Workbench zu lernen, wenn sie genügend Unterstützung erhält von der Statistik-Community und die Leute beginnen, nützliche Pakete dafür zu schreiben.

Meine Fragen folgen:

1. Welche Features muss Julia haben, um die Faszination zu haben, die R de facto zur Sprache der Statistik gemacht hat?

2. Was sind die Vor- und Nachteile des Lernens von Julia für rechenintensive Aufgaben im Vergleich zum Erlernen einer einfachen Sprache wie C / ++?

Ich denke, der Schlüssel wird sein, ob Bibliotheken für Julia entwickelt werden oder nicht. Es ist schön und gut, Spielzeugbeispiele zu sehen (auch wenn es sich um komplizierte Spielzeuge handelt), die zeigen, dass Julia bei Aufgaben, bei denen R schlecht ist, R aus dem Wasser bläst.

Aber schlecht gemachte Schleifen und handcodierte Algorithmen sind nicht der Grund, warum viele der Leute, die R verwenden, R verwenden. Sie verwenden es, weil für fast jede statistische Aufgabe unter der Sonne jemand R-Code dafür geschrieben hat. R ist sowohl eine Programmiersprache als auch ein Statistikpaket - derzeit ist Julia nur die erstere.

Ich denke, es ist möglich, dorthin zu gelangen, aber es gibt viel mehr etablierte Sprachen (Python), die immer noch Schwierigkeiten haben, brauchbare statistische Toolkits zu sein.

Ich stimme vielen anderen Kommentaren zu. "Hoffnung"? Sicher. Ich denke, Julia hat viel von dem gelernt, was R und Python / NumPy / Pandas und andere Systeme im Laufe der Jahre richtig und falsch gemacht haben. Wenn ich schlauer wäre als ich und eine neue Programmiersprache schreiben wollte, die in Zukunft das Substrat für eine statistische Entwicklungsumgebung sein wird, würde sie Julia sehr ähneln.

Allerdings wird es noch 5 Jahre dauern, bis diese Frage im Nachhinein beantwortet werden kann. Ab sofort fehlen Julia die folgenden kritischen Aspekte eines statistischen Programmiersystems, die mit R für alltägliche Benutzer konkurrieren könnten:

(Liste im Laufe der Zeit aktualisiert ...)

• optional geordnete Faktortypen
• die meisten statistischen Tests und statistischen Modelle
• Unterstützung für gebildete Programmierung / reproduzierbare Analyse
• Plotten der R-Klasse oder sogar der Matlab-Klasse

Um mit R zu konkurrieren, müssen Julia und Add-On-Statistikpakete sauber und vollständig genug sein, damit intelligente Nicht-Programmierer, wie Studenten der Sozialwissenschaften, sie vernünftigerweise nutzen können. Es gibt eine Menge Arbeit, um dorthin zu gelangen. Vielleicht wird es passieren, vielleicht wird es zischen, vielleicht wird etwas anderes (R 3.0?) Es ersetzen.

Aktualisieren:

Julia unterstützt jetzt DataFrames mit fehlenden Daten / NAs, Modulen / Namespaces, formulaTypen und model.matrixInfrastruktur, Plotten (sorta), Datenbankunterstützung (aber noch nicht für DataFrames) und Übergabe von Argumenten nach Schlüsselwörtern. Es gibt jetzt auch eine IDE (Julia Studio), Windows-Unterstützung, einige statistische Tests und einige Datum / Uhrzeit-Unterstützung.

Für mich ist es sehr wichtig, dass eine Datenanalysesprache über eine Abfrage- / relationale Algebra-Funktionalität mit angemessenen Standardeinstellungen und interaktivem Design verfügt. Idealerweise sollte dies eine integrierte Sprache sein. IMO, keine FOSS-Sprache, die ich benutzt habe, macht das effektiv, nicht einmal R.

Die interaktive Arbeit mit data.frame ist sehr umständlich. Beispielsweise wird beim Aufrufen die gesamte Datenstruktur gedruckt, die Syntax $ ist nur schwer programmgesteuert zu verarbeiten, Abfragen erfordern redundante Selbstreferenzen (dh DF[DF$x < 10]Verknüpfungen und Aggregationen) sind umständlich. Data.table behebt die meisten dieser Probleme. Da es jedoch nicht Teil der Kernimplementierung ist, werden die Funktionen des meisten R-Codes nicht verwendet.

Pandas in Python leiden unter den gleichen Fehlern.

Diese Griffe scheinen zwar nicht sehr knifflig zu sein, aber diese Fehler häufen sich und sind am Ende insgesamt erheblich, da sie viel Zeit kosten.

Ich glaube, wenn Julia als Datenanalyseumgebung erfolgreich sein soll, muss man sich bemühen, SQL-Typoperatoren (ohne das Gepäck der SQL-Syntax) für einen benutzerfreundlichen Tabellendatentyp zu implementieren.

Ich kann unterzeichnen, was Dirk und EpiGrad gesagt haben. Dennoch gibt es noch eine weitere Sache, die R zu einer einzigartigen Sprache in seiner Nische macht - das datenorientierte Typensystem.

Rs wurden speziell für den Umgang mit Daten entwickelt. Aus diesem Grund ist es vektorzentriert und enthält Dinge wie data.frames, Faktoren, NAs und Attribute.
Julias Typen sind andererseits numerisch-leistungsorientiert, daher haben wir Skalare, klar definierte Speichermodi, Gewerkschaften und Strukturen.

Das mag harmlos aussehen, aber jeder, der jemals versucht hat, Statistiken mit MATLAB zu erstellen, weiß, dass es wirklich weh tut.

Also, zumindest für mich, kann Julia nichts anbieten, was ich nicht mit ein paar Zeilen C beheben kann und tötet eine Menge wirklich nützlicher Ausdruckskraft.

Ich kann sehen, wie Julia Matlab ersetzt, was für die Menschheit eine enorme Leistung wäre.

Um R zu ersetzen, müssen Sie alle Dinge berücksichtigen, die Neil G, Harlan und andere erwähnt haben, sowie einen wichtigen Faktor, von dem ich glaube, dass er nicht angesprochen wurde: die einfache Installation der Anwendung und ihrer Bibliotheken.

Im Moment können Sie eine Binärdatei von R für Mac, Windows oder Linux herunterladen. Es funktioniert sofort mit einer großen Auswahl an statistischen Methoden. Wenn Sie ein Paket herunterladen möchten, ist dies ein einfacher Befehl oder ein Mausklick. Es funktioniert einfach

Ich habe Julia heruntergeladen und es ist nicht einfach. Selbst wenn Sie die Binärdatei herunterladen, muss gfortran installiert sein, um die richtigen Bibliotheken zu erhalten. Ich habe die Quelle heruntergeladen und versucht, makeund es ist fehlgeschlagen, ohne wirklich nützliche Nachricht. Ich habe einen Bachelor- und einen Master-Abschluss in Informatik, also könnte ich mich umsehen und es zum Laufen bringen, wenn ich dazu neige. (Bin ich nicht.) Wird Joe Statistician das tun?

R hat nicht nur eine riesige Auswahl an Paketen, sondern auch ein ziemlich ausgeklügeltes System, mit dem Binärdateien der Anwendung und fast alle Pakete automatisch erstellt werden. Wenn Sie aus irgendeinem Grund ein Paket aus dem Quellcode kompilieren müssen, ist dies nicht wirklich schwieriger (vorausgesetzt, Sie haben einen geeigneten Compiler usw. auf Ihrem System installiert). Sie können diese Infrastruktur nicht ignorieren, alles über Github erledigen und eine breite Akzeptanz erwarten.

EDIT: Ich wollte mit Julia rumalbern - es sieht aufregend aus. Zwei Probleme:

1) Als ich versuchte, zusätzliche Pakete zu installieren (vergiss, wie sie in Julia heißen), schlug dies mit undurchsichtigen Fehlern fehl. Offensichtlich hat mein Mac kein Make-like-Tool, das sie erwartet haben. Nicht nur, dass es fehlschlägt, sondern auch, dass Dinge herumliegen, die ich manuell löschen muss, oder dass andere Installationen fehlschlagen.

2) Sie erzwingen einen bestimmten Abstand in einer Codezeile. Ich habe die Details nicht vor mir, aber es hat mit Makros zu tun und es fehlt ein Leerzeichen zwischen dem Makro und der Klammer, die die Argumente öffnet. Diese Art von Einschränkung stört mich wirklich, da ich meine Code-Formatierung über viele Jahre und Sprachen hinweg entwickelt habe und tatsächlich ein Leerzeichen zwischen einem Funktions- / Makronamen und der öffnenden Klammer setze. Einige Einschränkungen der Code-Formatierung, die ich verstehe, aber Leerzeichen innerhalb einer Zeile?

Die Julia-Sprache ist ziemlich neu; Die Zeit im Scheinwerferlicht kann in Wochen gemessen werden (obwohl die Entwicklungszeit natürlich in Jahren gemessen werden kann). Nun, diese Wochen im Rampenlicht waren sehr aufregende Wochen - siehe zum Beispiel den jüngsten Vortrag in Stanford, in dem "es gerade erst angefangen hat" -, aber was Sie im Hinblick auf eine breitere Infrastruktur und Paketunterstützung verlangen, wird viel länger dauern materialisieren.

Also würde ich weiterhin R verwenden und auf die sich entwickelnden Alternativen achten. Letztes Jahr gingen viele Leute über Clojure hinweg; Dieses Jahr ist Julia die amtierende Neuheit. Mal sehen, ob es klebt.

Bruce Tate hier, Autor von Sieben Sprachen in sieben Wochen. Hier sind ein paar Gedanken. Ich arbeite an Julia für das Folgebuch. Das Folgende ist nur meine Meinung nach ein paar Wochen Spielzeit.

Es gibt zwei grundlegende Kräfte. Erstens haben alle Sprachen eine Lebensdauer. R wird eines Tages ersetzt. Wir wissen nicht wann. Neue Sprachen haben es sehr schwer, sich weiterzuentwickeln. Wenn sich eine neue Sprache entwickelt, löst sie normalerweise einen überwältigenden Schmerzpunkt.

Diese beiden Dinge hängen zusammen. Für mich beginnt ein Thema um Sprachen wie R herum Gestalt anzunehmen. Es ist nicht schnell genug und es ist schwieriger, als es sein muss. Diejenigen, die in einem bestimmten Leistungsumfang leben und in etablierten Bibliotheken bleiben können, sind in Ordnung. Diejenigen, die nicht mehr brauchen können und nach mehr suchen.

Die Sache ist, Computerarchitekturen verändern sich und um sie auszunutzen, müssen die Sprache und ihre Konstrukte auf eine bestimmte Weise konstruiert werden. Julias Einstellung zur Parallelität ist interessant. Es optimiert das Richtige für eine solche Sprache: die transparente Verteilung und die effiziente Übertragung von Daten zwischen Prozessen. Wenn ich Julia für typische Aufgaben, Maps und Transformationen und dergleichen benutze, rufe ich nur Funktionen auf. Ich muss mich nicht um die Klempnerarbeiten kümmern.

Für mich ist die Tatsache, dass Julia auf einem Prozessor schneller ist, interessant, aber für R nicht übermäßig schädlich. Was mich interessiert, ist, dass technische Computerprobleme nahezu ideal positioniert sind, da Prozessoren in zunehmendem Maße von der Leistung von Multicore abhängen den bestmöglichen Nutzen aus der richtigen Sprache ziehen.

Die andere Funktion, die dabei hilft, sind in der Tat Makros. Das Tempo der Sprache ist gerade intensiv. Mit Makros können Sie mit größeren, saubereren Bausteinen bauen. Bibliotheken anzusehen ist interessant, sagt aber nicht das ganze Bild aus. Sie müssen das Wachstum der Bibliotheken betrachten. Julias Flugbahn ist hier ziemlich genau richtig.

Clojure ist für einige interessant, weil es keine Fachsprache gibt, die das tut, was R kann. Einige suchen nach einer Allzwecksprache, um diese Lücke zu füllen. Ich bin eigentlich ein großer Fan. Aber Clojure ist ein ziemlich schwerwiegender Brain Warp. Clojure wird für Programmierer da sein, die technisches Computing benötigen. Es wird nicht für Ingenieure und Wissenschaftler sein. Es gibt einfach zu viel zu lernen.

Also für mich wird Julia oder so etwas R eines Tages auf jeden Fall ersetzen. Es ist eine Frage der Zeit.

Jedes Mal, wenn ich eine neue Sprache sehe, frage ich mich, warum eine vorhandene Sprache nicht verbessert werden kann.

Pythons große Vorteile sind

• eine Vielzahl von Modulen (nicht nur Statistiken, sondern auch Plotten von Bibliotheken, Ausgabe als PDF usw.)
• Sprachkonstrukte, die Sie auf lange Sicht benötigen (objektorientierte Konstrukte, die Sie in einem großen Projekt benötigen; Dekorateure, Verschlüsse usw., die die Entwicklung vereinfachen)
• viele Tutorials und eine große Support-Community
• Zugriff auf MapReduce, wenn Sie eine Menge Daten zu verarbeiten haben und es Ihnen nichts ausmacht, ein paar Cent für die Ausführung in einem Cluster zu zahlen.

Um R, Julia usw. zu überholen, könnte Python verwenden

• Entwicklung einer Just-in-Time-Kompilierung für eingeschränktes Python, um mehr Geschwindigkeit auf einem einzelnen Computer zu erzielen (Mapreduce ist jedoch immer noch besser, wenn Sie die Latenz aushalten können)
• eine reichhaltigere statistische Bibliothek

Julia wird R nicht sehr bald übernehmen. Check out Microsoft R öffnen.

https://mran.revolutionanalytics.com/open/

Dies ist eine erweiterte Version von R, die automatisch alle Kerne Ihres Computers verwendet. Es ist dasselbe R, dieselbe Sprache, dieselben Pakete. Wenn Sie es installieren, wird es von RStudio auch in der Konsole verwendet. Die Geschwindigkeit von MRO ist sogar schneller als Julia. Ich mache viel Heavy-Duty-Computing und benutze Julia seit über einem Jahr. Ich habe kürzlich zu R gewechselt, weil R eine bessere Unterstützung hat und RStudio ein großartiger Editor ist. Julia ist noch in einem frühen Stadium und holt möglicherweise Python oder R nicht sehr bald ein.

Das Folgende verdient wahrscheinlich keine Antwort, aber es ist zu wichtig, als Kommentar zu der Antwort eines anderen begraben zu werden ...

Ich habe nicht viel über den Speicherverbrauch gehört, nur über die Geschwindigkeit. Die gesamte Semantik von R kann schmerzhaft sein, und dies war eine Kritik an der Sprache (was ein anderes Problem ist als die Anzahl der bereits vorhandenen großartigen Pakete). Eine gute Speicherverwaltung ist wichtig, ebenso wie Möglichkeiten zur Verarbeitung außerhalb des Kerns (z. B. Arrays oder Pytables mit Speicherzuordnung von NumPy oder das xdf-Format von Revolution Analytics)). Während der JIT-Compiler von PyPy einige bemerkenswerte Python-Benchmarks zulässt, kann der Speicherverbrauch recht hoch sein. Hat jemand schon Erfahrung mit Julia und der Speichernutzung? Klingt so, als gäbe es Speicherverluste in der Windows "alpha" -Version, die zweifellos behoben werden, und ich warte immer noch auf den Zugriff auf eine Linux-Box, um selbst mit der Sprache zu spielen.

Ich halte es aus den oben genannten Gründen für unwahrscheinlich, dass Julia jemals R ersetzen wird. Julia ist ein Matlab-Ersatz, kein R-Ersatz. Sie haben unterschiedliche Ziele. Selbst nachdem Julia eine vollständig ausgearbeitete Statistikbibliothek hat, würde niemand jemals eine Einführung in die Statistik-Klasse darin unterrichten.

Ein Bereich, in dem es unglaublich sein könnte, ist jedoch als geschwindigkeitsoptimierte Programmiersprache weniger schmerzhaft als C / C ++. Wenn es nahtlos mit R verknüpft wäre (im Stil von Rcpp), würde es beim Schreiben geschwindigkeitskritischer Codesegmente eine Menge Nutzen bringen. Leider existiert derzeit kein solcher Link:

https://stackoverflow.com/questions/9965747/linking-r-and-julia

Ich bin eine Julia Neuling und bin R kompetent. Die Gründe, warum ich Julia bisher interessant finde, sind auf Leistung und Kompatibilität ausgerichtet.

GPU-Tools. Ich möchte CUSPARSE für eine statistische Anwendung verwenden. CRAN-Ergebnisse zeigen, dass es nicht viel gibt. Julia hat Bindungen zur Verfügung, die bisher reibungslos zu funktionieren scheinen.

using CUSPARSE
N = 1000
M = 1000
hA = sprand(N, M, .01)
hA = hA' * hA
dA = CudaSparseMatrixCSR(hA)
dC = CUSPARSE.csric02(dA, 'O') #incomplete Cholesky decomp
hC = CUSPARSE.to_host(dC)

HPC-Werkzeuge. Ein Cluster kann interaktiv mit mehreren Rechenknoten verwendet werden.

nnodes = 2
ncores = 12    #ask for all cores on the nodes we control
procs = addprocs(SlurmManager(nnodes*ncores), partition="tesla", nodes=nnodes)
for worker in procs
    println(remotecall_fetch(readall, worker, `hostname`))
end

Python-Kompatibilität. Es gibt Zugang zum Python-Ökosystem. ZB war es einfach herauszufinden, wie man Gehirnbilddaten liest:

import PyCall
@pyimport nibabel

fp = "foo_BOLD.nii.gz"
res = nibabel.load(fp)
data = res[:get_data]();

C-Kompatibilität. Das Folgende generiert eine zufällige Ganzzahl unter Verwendung der C-Standardbibliothek.

ccall( (:rand, "libc"), Int32, ())

Geschwindigkeit. Ich dachte, ich würde sehen, wie sich das Distributions.jl-Paket gegen Rs Rnorm verhält - von dem ich annehme, dass es optimiert ist.

julia> F = Normal(3,1)
Distributions.Normal(μ=3.0, σ=1.0)

julia> @elapsed rand(F, 1000000)
0.03422067

In R:

> system.time(rnorm(1000000, mean=3, sd=1))
   user  system elapsed 
  0.262   0.003   0.266 

Julia 1.0 hat gerade eine sehr brauchbare IDE (Juno) herausgebracht. Es war etwas spät für die Party, da Python bereits das maschinelle Lernen dominiert hat, während R weiterhin jede andere Art statistischer Analyse dominiert. Trotzdem gewinnt Julia im Bereich der Finanz- und Handelsalgorithmen bereits an Bedeutung, da schnelle Entwicklungszeiten UND deren Ausführung ein Muss sind. Meiner Meinung nach wird Julias Aufstieg in die Hauptrolle ungefähr so ​​aussehen, es sei denn, es kommt eine andere Sprache heraus, die deutlich besser ist:

(1) Es fängt an, MATLABs Mittagessen zu essen. MATLAB-Benutzer mögen die MATLAB-Syntax, hassen aber so ziemlich alles andere. Die Langsamkeit, die teuren Lizenzen, die sehr begrenzten Möglichkeiten, mit komplexen Datenstrukturen umzugehen, die keine Matrizen sind. Ich erinnere mich an ein Zitat, in dem es heißt: "Wenn Julia MATLAB ersetzt, wird dies ein großer Dienst für die Menschheit sein." MATLAB-Benutzer können Julia sehr schnell beherrschen und werden beeindruckt sein, wie einfach es ist, Qualitätscode zu schreiben, der so viel mehr kann als MATLAB (Strukturen, die schnell sind, dass Sie Arrays einfügen und schnell iterieren können?). Darüber hinaus können Forscher in Julia (ein kleines Team von Doktoranden, das ein erstklassiges Differentialgleichungspaket geschrieben hat) ernsthafte Werkzeugkästen erstellen, die mit MATLAB nicht möglich gewesen wären.

(2) Es beginnt mit der Erforschung numerischer Methoden und Simulationen. Das MIT wirft sein Gewicht hinter Julia, und die Forschungsgemeinschaft hört dem MIT zu. Numerische Simulationen und neue numerische Methoden sind schlecht definierte Probleme, für die es keine Bibliotheken gibt. Hier leuchtet Julia als Sprache; Wenn keine Bibliotheken verfügbar sind, ist es viel einfacher, schnellen Qualitätscode in Julia zu schreiben als in jeder anderen Sprache. Es wird eine numerische / Simulationssprache sein, die von Mathematikern für Mathematiker geschrieben wird (klingt ähnlich wie R noch?)

(3) Ein weiterer Durchbruch im maschinellen Lernen gibt Julia den entscheidenden Vorteil. Dies ist ein Platzhalter, der möglicherweise nicht vorkommt. TensorFlow ist großartig, aber es ist extrem schwer zu hacken. Python zeigt bereits Risse und TensorFlow übernimmt Swift (wobei Julia eine lobende Erwähnung erhält). Wenn ein weiterer Durchbruch beim maschinellen Lernen eintritt, ist es viel einfacher, ein Julia-Paket wie Flux.jl zu implementieren und zu hacken.

(4) Julia holt langsam R ein, was eine Weile dauern wird. Statistiken in MATLAB zu erstellen ist schmerzhaft, aber Juila ist MATLAB mit Distributions.jl bereits weit voraus. Tatsache ist, dass R-Workflows einfach in Julia übersetzt werden können. Der einzige wirkliche Vorteil von R ist die Tatsache, dass es so viele Pakete gibt, die von Statistikern für Statistiker geschrieben wurden. Dieser Vorgang ist jedoch auch in Julia einfach zu bewerkstelligen. Der Unterschied ist, dass Julia den ganzen Weg schnell ist und Sie keine andere Sprache für die Leistung verwenden müssen (die "ernsteren" R-Pakete sind in Sprachen wie C geschrieben). Das Problem bei R ist, dass in R geschriebene Pakete zu langsam sind, um große Datenmengen zu verarbeiten. Die einzige Alternative besteht darin, die Pakete in eine andere Sprache zu übersetzen, was die Entwicklung in R langsamer macht als in Julia.

Ich interessiere mich für das Versprechen einer schnelleren und einfacheren Parallelisierung mit verschiedenen Architekturen. Aus diesem Grund werde ich sicherlich die Entwicklung von Julia beobachten, aber es ist unwahrscheinlich, dass ich es verwende, bis es mit verallgemeinerten linearen gemischten Modellen umgehen kann. Es verfügt über ein gutes generisches Bootstrap-Paket, eine einfache Modellsprache für die Erstellung von Design-Matrizen, die der Fähigkeit von ggplot2 entspricht, und eine große Bandbreite aus maschinellen Lernalgorithmen.

Kein Statistiker kann es sich leisten, bei der Auswahl der Werkzeuge eine fundamentalistische Haltung einzunehmen. Wir werden alles verwenden, um die Arbeit am effizientesten zu erledigen. Ich schätze, ich werde noch ein paar Jahre bei R bleiben, aber es wäre schön, angenehm überrascht zu sein.

Der Luxus von NA's in R geht nicht ohne Performance-Einbußen. Wenn Julia NAs mit einer geringeren Leistungseinbuße unterstützt, wird es für einen Teil der Statistik-Community interessant, aber NAs erlegen auch erhebliche zusätzliche Arbeit auf, wenn sie kompilierten Code mit R verwenden.

Viele der Pakete in R basieren auf Routinen, die in älteren Sprachen (C, Fortran oder C ++) geschrieben wurden. In einigen Fällen wurden die kompilierten Routinen außerhalb von R entwickelt und später als Basis für R-Bibliothekspakete verwendet. In anderen Fällen wurden die Routinen zuerst in R implementiert und dann wichtige Segmente in eine kompilierte Sprache übersetzt, wenn festgestellt wurde, dass die Leistung mangelhaft war. Julia wird attraktiv sein, wenn es verwendet werden kann, um äquivalente Routinen zu implementieren. Es besteht die Möglichkeit, die Unterstützung für NAs auf niedriger Ebene so zu gestalten, dass die NA-Behandlung einfacher wird als bisher, wenn R mit kompiliertem Code verwendet wird.

Die enorme Anzahl von R-Bibliotheken repräsentiert die Bemühungen vieler, vieler Benutzer. Dies war möglich, weil R Funktionen bereitstellte, die ansonsten nicht verfügbar / erschwinglich waren. Damit Julia weit verbreitet wird, braucht es eine Gruppe von Anwendern, die feststellen, dass sie das, was sie benötigen, viel besser als die Alternativen tun, die den Aufwand für die Bereitstellung grundlegender Dinge (z. B. Grafiken, Datumsklassen, NAs usw.) wert sind. ) aus vorhandenen Sprachen verfügbar.

Ich werde vorne mit dabei sein, ich habe keine Erfahrung mit R, aber ich arbeite mit vielen Leuten zusammen, die denken, dass es ein hervorragendes Werkzeug für statistische Analysen ist. Mein Hintergrund liegt im Bereich Data Warehousing, und aufgrund von Julias einfach zu verteilendem, aber mehr standardisiertem Programmiermodell könnte es ein sehr interessanter Ersatz für den Transformationsanteil traditioneller ETL-Tools sein, die im Allgemeinen sehr schlecht funktionieren und von denen die meisten keine Möglichkeit haben Einfache Erstellung einer standardisierten Transformation oder Wiederverwendung der Ergebnisse einer Transformation, die bereits für einen früheren Datensatz durchgeführt wurde. Die Unterstützung für eng definierte und typisierte Tupel ist bemerkenswert. Wenn ich einen OLAP-Cube erstellen möchte, der detailliertere Tupel (Faktentabellen) aus bereits berechneten Tupeln erstellt, gibt es in den heutigen ETL-Tools keine "Bausteine", von denen die Rede ist kann helfen, Diese Branche hat dieses Problem in der Vergangenheit auf verschiedene Weise umgangen, aber es gibt Kompromisse. Herkömmliche Programmiersprachen können helfen, indem sie zentral definierte Transformationen bereitstellen, und Julia könnte möglicherweise die in komplexeren Data-Warehouse-Systemen üblichen nicht standardmäßigen Aggregationen und Verteilungen vereinfachen.

Sie können Julia und R auch zusammen verwenden. Es gibt Julia-zu-R-Schnittstelle . Mit diesen Paketen können Sie mit Julia spielen, während Sie R aufrufen, wenn es eine Bibliothek hat, die benötigt wird.

Julia hat ohne Zweifel jede Chance, ein Traum von Statistik-Power-Usern zu werden. Nehmen Sie SAS. Ihre Stärke liegt in den zahlreichen in C geschriebenen Prozessen. Was Julia tun kann, ist, Ihnen die Prozesse mit dem Quellcode, mit Matrizen wie, zu geben Ein eingebauter Datentyp, der auf SAS / IML verzichtet. Ich habe keinen Zweifel, dass Statistiker zu Julia strömen werden, sobald sie wissen, was dieser Welpe kann.

Oh ja, Julia wird R ziemlich schnell überholen. Und die Hauptgründe werden "Makros" sein, 95% der Sprache ist in Julia implementiert, und ihre rauschfreie, sparsame Syntax. Wenn Sie noch keine Erfahrung mit Lisp-Sprachen haben, werden Sie es vielleicht noch nicht verstehen, aber Sie werden schnell sehen, wie die R-Formel-Schnittstelle zu einem veralteten und hässlichen Mechanismus wird und durch spezielle Modellierungsmikrosprachen ersetzt wird, die mit CL vergleichbar sind Schleifenmakro. Der Zugriff auf untergeordnete Referenzen eines Objekts ist ebenfalls ein großes Plus. Ich denke, R hat immer noch nicht verstanden, dass das Verstecken von Interna vor dem Benutzer die Dinge tatsächlich kompliziert als vereinfacht.

Wie ich jetzt sehe (nachdem ich jahrelang viel R benutzt habe und gerade das Julia-Handbuch gelesen habe), ist Julias Hauptnachteil in Bezug auf R keine Unterstützung für strukturelle Vererbung (dies war beabsichtigt). Julias Typensystem ist weniger ehrgeizig als das von S4; Es unterstützt auch Mehrfachversand und Mehrfachvererbung, aber mit einem Haken - es gibt nur eine Ebene konkreter Klassen. Andererseits sehe ich selten Klassenhierarchien in R, die tiefer als 3 Ebenen sind.

Die Zeit wird es zeigen, aber es wird früher sein als die meisten R-Benutzer denken :)

Julias erste Anwendungsfälle sind numerische Probleme. Grundsätzlich können Sie diese Bereiche der Analyse- und Computerwissenschaft in Datenwissenschaft (datengesteuert) und Simulationswissenschaft (modellgesteuert) unterteilen. Julia beschäftigt sich zuerst mit den Anwendungsfällen der Simulationswissenschaft. Sie beschäftigen sich auch mit datenwissenschaftlichen Fällen, jedoch langsamer. R wird für die Simulationswissenschaft niemals sehr nützlich sein, aber Julia wird für beide in ein paar Jahren sehr nützlich sein.

Es muss in der Lage sein, jede Funktion auf große Datenmengen anzuwenden, die für den Benutzer nicht transparent auf den Arbeitsspeicher passen.
Dazu gehört zumindest das Ausführen von Modellen mit gemischten Effekten, Überlebensmodellen oder MCMC für Datensätze, die auf die Festplatte, jedoch nicht auf den Speicher passen. Und wenn möglich auf Datensätzen, die auf mehreren Computern verteilt sind.