Julia ha qualche speranza di restare nella comunità statistica?


161

Di recente ho letto un post di R-Blogger, collegato a questo post di John Myles White su una nuova lingua chiamata Julia . Julia si avvale di un compilatore just-in-time che gli fornisce tempi di esecuzione rapidi malvagi e lo pone sullo stesso ordine di grandezza della velocità di C / C ++ (lo stesso ordine , non altrettanto veloce). Inoltre, utilizza i meccanismi di looping ortodossi che hanno familiarità con quelli di noi che hanno iniziato a programmare su linguaggi tradizionali, anziché le istruzioni di R e le operazioni vettoriali.

R non se ne va affatto, anche con tempi così fantastici da Julia. Ha un ampio supporto nel settore e numerosi pacchetti meravigliosi per fare praticamente qualsiasi cosa.

I miei interessi sono di natura bayesiana, dove spesso vettorializzare non è possibile. Certamente le attività seriali devono essere eseguite usando loop e comportano un calcolo pesante ad ogni iterazione. R può essere molto lento in queste attività di loop seriale e C / ++ non è una passeggiata nel parco per scrivere. Julia sembra un'ottima alternativa alla scrittura in C / ++, ma è nella sua infanzia e manca di molte funzionalità che amo di R. Avrebbe senso imparare Julia come banco di lavoro di statistica computazionale se ottiene abbastanza supporto dalla comunità delle statistiche e le persone iniziano a scrivere pacchetti utili per questo.

Le mie domande seguono:

  1. Quali caratteristiche deve avere Julia per avere il fascino che ha reso R il linguaggio di fatto delle statistiche?

  2. Quali sono i vantaggi e gli svantaggi di imparare Julia a svolgere compiti pesanti dal punto di vista computazionale, rispetto all'apprendimento di un linguaggio di basso livello come C / ++?


7
In che modo Julia è migliore di Incanter ( incanter.org ) e di altri progetti simili?
Wayne,

24
Costrutti procedurali (es. Loop): sembra un gigantesco passo indietro. Siamo alla cuspide di un passaggio da piattaforme a CPU singola e piccola a piattaforme fortemente parallele. Poiché questa evoluzione avverrà nel prossimo decennio, lo stile funzionale di codifica facilmente e automaticamente parallelizzabile trarrà enormi vantaggi rispetto al codice procedurale. Molte altre considerazioni intervengono nella scelta di una piattaforma statistica, ovviamente, ma vale la pena di tenerne conto come strategia a lungo termine.
whuber

12
Christopher, un buon approccio è quello di inquadrare le domande in un modo progettato per sollecitare ragioni e prove. Ad esempio, invece di "Julia ha il fascino necessario ...", prova qualcosa del tipo "Quali elementi di Julia potrebbero dargli la possibilità di guadagnare trazione e perché"; invece di "Vale la pena imparare", chiedi "Perché potrebbe valere la pena imparare Julia adesso? Quali sono i suoi potenziali vantaggi?" Puoi ulteriormente affinare questa domanda specificando quali tipi di usi di Julia potresti essere interessato, come lo sviluppo di software, la risoluzione di problemi una tantum, la biostatistica, il data mining, ecc.
whuber

1
@Whuber: apprezzo i suggerimenti e li ho implementati. Grazie!
Christopher Aden,

2
@ trolle3000 Non credo che nessuno stia sostenendo che la parallelizzazione sia così automatica. Tuttavia, quando (se) hai scritto una versione funzionale di un programma, hai già intrapreso gran parte dello sforzo necessario per parallelizzarlo, motivo per cui applicazioni come Mathematica possono automatizzare la parallelizzazione, spesso in modo abbastanza efficace. Se invece hai codificato un algoritmo in modo procedurale, di solito sarà molto più difficile parallelizzarlo.
whuber

Risposte:


96

Penso che la chiave sarà se le librerie inizieranno o meno a essere sviluppate per Julia. Va bene vedere esempi di giocattoli (anche se sono giocattoli complicati) che mostrano che Julia soffia R fuori dall'acqua nei compiti in cui R è pessimo.

Ma i cicli mal eseguiti e gli algoritmi codificati a mano non sono il motivo per cui molte delle persone che conosco che usano R usano R. Lo usano perché per quasi tutte le attività statistiche sotto il sole, qualcuno ha scritto il codice R per questo. R è sia un linguaggio di programmazione che un pacchetto statistico - attualmente Julia è solo la prima.

Penso che sia possibile arrivarci, ma ci sono linguaggi molto più affermati (Python) che ancora lottano per essere strumenti statistici utilizzabili.


Hai effettivamente esaminato il codice di riferimento (o i parametri di riferimento) per sapere che i metodi R sono scritti male? Sto cercando di trovarlo da solo per vedere come venivano usate le varie lingue ...
Josh Hemann

10
@JoshHemann Ho guardato abbastanza per sapere che su tutta la linea R è "slow-ish". Non necessariamente perde ogni volta, e occasionalmente fa esplodere Python fuori dall'acqua, ma in tutti quei casi il nastro "chi vince" sembra andare a cui il programmatore Python o R ha effettivamente scritto la maggior parte delle sue cose in C .
fomite

5
Il codice di riferimento è terribile . Per i loro esempi R sono possibili guadagni di velocità 2000x. Vedi stackoverflow.com/questions/9968578/… , in particolare i commenti.
Ari B. Friedman,

12
Hai ragione, @gsk. Ad esempio, pisum(su github.com/JuliaLang/julia/blob/master/test/perf/perf.R ) impiega 7,76 secondi mentre una semplice riscrittura usando l'idiomatico R ( replicate(500, sum((1 / (10000:1))^2))[500]) richiede 0,137 secondi, più di una velocità di cinquanta volte.
whuber

2
Uno dei motivi per cui R decollò fu la sua compatibilità con S-PLUS. Le persone erano in grado di usare molto vecchio codice. Il vecchio codice usato pesantemente ha meno bug. Con cose nuove come Julia, che non sono compatibili con il vecchio codice, hai bisogno di una situazione di "killer app": qualcosa che giustifica tutti i problemi di passare a una nuova piattaforma. È simile alla nuova lingua di Google Go - bel tentativo, ma perché dovrei impararlo?
Aksakal,

56

Sono d'accordo con molti altri commenti. "Speranza"? Sicuro. Penso che Julia abbia imparato molto da ciò che R e Python / NumPy / Panda e altri sistemi hanno fatto bene e male nel corso degli anni. Se fossi più intelligente di me e volessi scrivere un nuovo linguaggio di programmazione che sarebbe il substrato per un ambiente di sviluppo statistico in futuro, assomiglierebbe molto a Julia.

Detto questo, ci vorranno 5 anni prima che a questa domanda si possa eventualmente rispondere a posteriori. A partire da ora, a Julia mancano i seguenti aspetti critici di un sistema di programmazione statistica che potrebbe competere con R per gli utenti quotidiani:

(elenco aggiornato nel tempo ...)

  • tipi di fattore ordinati facoltativamente
  • la maggior parte dei test statistici e dei modelli statistici
  • supporto di analisi programmabili / riproducibili
  • Tracciato di classe R o addirittura di classe Matlab

Per competere con R, Julia e i pacchetti di statistiche add-on dovranno essere abbastanza puliti e completi abbastanza che i non programmatori intelligenti, dicono gli studenti delle scienze sociali, possano ragionevolmente usarlo. C'è un sacco di lavoro da fare per arrivarci. Forse succederà, forse si consumerà, forse qualcos'altro (R 3.0?) Lo sostituirà.

Aggiornare:

Julia ora supporta DataFrames con dati / NA mancanti, moduli / spazi dei nomi, formulatipi e model.matrixinfrastruttura, stampa (sorta), supporto per il database (ma non ancora per DataFrames) e trasmissione di argomenti tramite parole chiave. Ora esiste anche un IDE (Julia Studio), supporto per Windows, alcuni test statistici e supporto per data / ora.


literate programming/reproduce-able analysis support-> vedi IJulia .
Piotr Migdal,

1
Aggiungi il kernel iJulia per l'ecosistema di notebook iPython / Jupyter.
thecity2

2
Julia Studio è in fase di eliminazione e Juno ora è l'IDE
Antony il

3
2,5 anni dopo che questa risposta è stata pubblicata per la prima volta, i due terzi degli articoli nella lista dei "must have" sono ora implementati. Penso che sia la migliore prova che potresti trovare che Julia ha una vera promessa.
Senderle,

5 anni devono essere passati. Siamo già arrivati, @Harlan?
StasK,

35

Per me, una cosa molto importante per un linguaggio di analisi dei dati è disporre di funzionalità di algebra relazionale / relazionale con valori predefiniti ragionevoli e design orientato interattivamente, e idealmente dovrebbe essere integrato nel linguaggio. IMO, nessun linguaggio FOSS che ho usato lo fa efficacemente, nemmeno R.

data.frame è molto ingombrante con cui interagire in modo interattivo - ad esempio, stampa l'intera struttura dei dati durante l'invocazione, la sintassi $ è difficile da lavorare programmaticamente, la query richiede un auto-riferimento ridondante (cioè, DF[DF$x < 10]), i join e l'aggregazione sono scomodi. Data.table risolve la maggior parte di questi fastidi, ma poiché non fa parte dell'implementazione di base, la maggior parte del codice R non utilizza le sue funzionalità.

I panda in pitone soffrono degli stessi difetti.

Queste lamentele possono sembrare pignole, ma questi difetti si accumulano e alla fine sono significativi in ​​termini di aggregazione poiché finiscono per costare molto tempo.

Credo che se Julia deve avere successo come ambiente di analisi dei dati, è necessario impegnarsi per implementare operatori di tipo SQL (senza il bagaglio della sintassi SQL) su un tipo di dati di tabella intuitivo.


1
+ 1 - Un punto interessante, spiegato con attenzione. Benvenuto nella nostra comunità!
whuber

4
Per essere pignoli, i Pandas DataFrame di grandi dimensioni in realtà non stampano tutto il loro contenuto quando vengono invocati, come accade in R. Passano alla visualizzazione delle intestazioni di colonna insieme a un conteggio di valori null / non-null. Inoltre, mentre sono d'accordo sul fatto che la sintassi non è l'ideale, i problemi di scoping rendono difficile eliminare l'autoreferenzialità per il filtro in stile di comprensione. È più veloce, ma è anche resistente alle collisioni dello spazio dei nomi se un DataFrame ha colonne extra in fase di esecuzione che non ti aspettavi.
Goodside

29

Posso firmare sotto quello che hanno detto Dirk ed EpiGrad; eppure c'è un'altra cosa che rende R un linguaggio unico nella sua nicchia: il sistema di tipi orientato ai dati.

R è stato appositamente progettato per la gestione dei dati, ecco perché è centrato sui vettori e ha elementi come data.frames, fattori, NA e attributi.
I tipi di Julia sono d'altra parte orientati alle prestazioni numeriche, quindi abbiamo scalari, modalità di memorizzazione ben definite, sindacati e strutture.

Questo può sembrare benigno, ma chiunque abbia mai provato a fare statistiche con MATLAB sa che fa davvero male.

Quindi, almeno per me, Julia non può offrire nulla che non posso risolvere con un pezzo di C a poche righe e uccide molta espressività davvero utile.


4
(+1) Buon punto. Qualche ulteriore pensiero: la mancanza di data.framestrutture simili a Python mi ha infastidito da tempo, ma ora Pandas sembra aver risolto questo problema. La formula è tra alcune delle estensioni pianificate di statsmodels (beh, sappiamo che a volte è meglio evitare l'interfaccia della formula in R). C'è una proposta data.frame per Julia (abbastanza veloce rispetto a Python!), (...)
chl

5
Penso che @mbq abbia anche un punto su C. Se ho bisogno di velocità sullo stesso ordine di grandezza di C / C ++ ... Posso usare C / C ++ con R.
Fomite

4
@EpiGrad, sì, puoi scrivere C / C ++ e interfacciarti in modo pulito con R. Ma questo è un punto debole, non un punto di forza del linguaggio. Con Julia, gli utenti finali non dovranno mai scrivere C per ottenere velocità.
Harlan,

2
@Harlan È solo un punto debole se conosci già sia Julia che C. Asserirei il tempo trascorso in C <il tempo trascorso imparando una nuova lingua e reimplementando tutto da zero.
Fomite

9
@Harlan E per essere sinceri, quelle persone non riscriveranno le loro cose a Julia. R come pacchetto di statistiche, non un linguaggio di programmazione è il loro caso d'uso .
Fomite

26

Vedo Julia che sostituisce Matlab, che sarebbe un enorme servizio per l'umanità.

Per sostituire R, dovresti considerare tutte le cose che Neil G, Harlan e altri hanno menzionato, oltre a un grande fattore che non credo sia stato risolto: una facile installazione dell'applicazione e delle sue librerie.

Adesso puoi scaricare un binario di R per Mac, Windows o Linux. Funziona immediatamente con una vasta selezione di metodi statistici. Se vuoi scaricare un pacchetto, è un semplice comando o un clic del mouse. Funziona e basta.

Sono andato a scaricare Julia e non è semplice. Anche se scarichi il binario, devi avere gfortran installato per ottenere le librerie appropriate. Ho scaricato la fonte e ho provato a makefarlo e non è riuscito senza un messaggio davvero utile. Ho una laurea e una laurea in informatica, quindi potrei curiosare e farlo funzionare se ero così propenso. (Non lo sono.) Joe Statistician lo farà?

R non ha solo una vasta selezione di pacchetti, ha un sistema abbastanza sofisticato che rende automaticamente binari dell'applicazione e quasi tutti i pacchetti. Se, per qualche motivo, è necessario compilare un pacchetto dal sorgente, non è affatto più difficile (purché nel proprio sistema sia installato un compilatore appropriato, ecc.). Non puoi ignorare questa infrastruttura, fare tutto tramite github e aspettarti un'adozione ampia.

EDIT: Volevo scherzare con Julia - sembra eccitante. Due problemi:

1) Quando ho provato a installare pacchetti aggiuntivi (dimentica quello che vengono chiamati in Julia), non è riuscito con errori oscuri. Evidentemente il mio Mac non ha uno strumento simile a quello che si aspettavano. Non solo fallisce, ma lascia in giro cose che devo eliminare manualmente o altre installazioni falliranno.

2) Costringono una certa spaziatura in una riga di codice. Non ho i dettagli di fronte a me, ma ha a che fare con le macro e non avere uno spazio tra la macro e la parentesi che apre i suoi argomenti. Questo tipo di restrizione mi infastidisce molto, dal momento che ho sviluppato la mia formattazione del codice in molti anni e lingue e in effetti inserisco uno spazio tra una funzione / nome macro e la parentesi di apertura. Alcune restrizioni di formattazione del codice capisco, ma gli spazi all'interno di una riga?


5
Julia è ancora MOLTO molto agli inizi. Non sono uno storico, ma scommetterei che neanche nei primi mesi uscirono binari puliti di R. Il tuo punto sul sistema di distribuzione è qualcosa che non ho visto menzionato finora. Inoltre, scommetterei anche che CRAN non è spuntato contemporaneamente a R. Un "CJAN" sarebbe sicuramente bello per l'adozione su larga scala.
Christopher Aden,

7
Potresti essere interessato a sapere, @Christopher, che R è davvero un clone sviluppato indipendentemente di un pacchetto (S, quindi S-Plus) che era stato un (lieve) successo commerciale ed era in fase di sviluppo dieci anni prima. Ciò ha dato un notevole vantaggio iniziale che Julia (e la maggior parte degli altri sforzi simili) non hanno mai fatto.
whuber

3
@ChristopherAden: sono d'accordo che Julia è ancora giovane. Ma non sono assolutamente d'accordo sul fatto che "un 'CJAN' sarebbe sicuramente bello per l'adozione su larga scala": è una necessità assoluta. Gli unici strumenti a cui riesco a pensare che non dispongono di un'infrastruttura simile a CRAN sono altamente specializzati, come JAGS. Ma Julia, come R, è uno scopo generale.
Wayne,

10
Il giorno in cui Open Source Language sostituirà MATLAB sarà il giorno migliore per il mondo dell'ingegneria.
Royi,

9
"Vedo Julia che sostituisce Matlab, che sarebbe un enorme servizio per l'umanità." Non potrei essere più d'accordo.
davidav,

24

La lingua Julia è piuttosto nuova; è il tempo in cui la luce spot può essere misurata in settimane (anche se il suo tempo di sviluppo può ovviamente essere misurato in anni). Ora quelle settimane sotto i riflettori sono state settimane molto eccitanti --- vedi per esempio il recente discorso a Stanford in cui "era appena iniziato" --- ma quello che chiederai in termini di più ampia infrastruttura e supporto ai pacchetti richiederà molto più tempo materializzarsi.

Quindi continuerei a usare R ed essere consapevole delle alternative di sviluppo. L'anno scorso molte persone sono andate a galla per Clojure; quest'anno Julia è il nuovo sapore regnante. Vedremo se si attacca.


16
A causa di ciò che ho visto tramite Rcpp, sono ancora più colpito da Julia --- aumenti di circa 50, 60, 70 volte per loop semplici come in MCMC e diverse centinaia di volte per esempi "degenerati" come i fibonacci sono essenzialmente gli stessi di Rcpp ottenuto! Ma so anche che con Rcpp ho ancora accesso ai pacchetti 3700 CRAN --- così come alle innumerevoli librerie C ++ --- mentre Julia in questo momento non ha quasi nulla. Detto questo, la promessa di Julia è enorme. Ma forse c'è un "allora" e un "ora". Il tempo lo dirà.
Dirk Eddelbuettel,

2
E non dimenticare Incanter, che dovrebbe diventare un ambiente statistico basato su Clojure. In che modo Julia è superiore a quella?
Wayne,

2
@Wayne, non confondiamo le acque qui. Apri una nuova domanda per questo (forse quella che richiede un confronto tra più lingue)
nought101

2
@ naught011: sto semplicemente facendo eco al punto di Dirk secondo cui Clojure era il sapore del mese, quindi in particolare Incanter, ora Julia. Non credo che Julia o Incanter (o Clojure) abbiano la possibilità di essere piattaforme statistiche generalizzate.
Wayne,

2
Non ne ho idea, ma aggiorno volentieri il lato R: ad oggi oltre 6400 pacchetti su CRAN e ora oltre 350 di quelli che usano Rcpp. Funziona ancora per me. La gente di Julia sembra attiva e felice --- e avere una scelta è una buona cosa. Non esiste una lingua per tutti i problemi: scusa, Python .
Dirk Eddelbuettel,

19

Bruce Tate qui, autore di Seven Languages ​​in Seven Weeks. Ecco alcuni pensieri. Sto lavorando su Julia per il libro di follow-up. Quella che segue è solo la mia opinione dopo alcune settimane di gioco.

Ci sono due forze fondamentali in gioco. Innanzitutto, tutte le lingue hanno una durata. R verrà sostituito un giorno. Non sappiamo quando. Le nuove lingue hanno un momento estremamente difficile in evoluzione. Quando una nuova lingua si evolve, di solito risolve un punto doloroso travolgente.

Queste due cose sono correlate. Per me, stiamo iniziando a vedere un tema che prende forma intorno a lingue come R. Non è abbastanza veloce ed è più difficile di quanto debba essere. Coloro che possono vivere all'interno di una determinata dotazione prestazionale e rimanere all'interno delle biblioteche stabilite stanno bene. Coloro che non possono aver bisogno di più e stanno iniziando a cercare di più.

Il fatto è che le architetture informatiche stanno cambiando e, per sfruttarle, il linguaggio e i suoi costrutti devono essere costruiti in un certo modo. L'interpretazione di Julia sulla concorrenza è interessante. Ottimizza la cosa giusta per un tale linguaggio: distribuzione trasparente e lo spostamento efficiente dei dati tra i processi. Quando uso Julia per compiti tipici, mappe e trasformazioni e simili, chiamo solo funzioni. Non devo preoccuparmi dell'impianto idraulico.

Per me, il fatto che Julia sia più veloce su un processore è interessante, ma non eccessivamente dannoso per R. La cosa interessante per me è che poiché i processori dipendono sempre di più dal multicore per le prestazioni, i problemi di calcolo tecnico sono quasi idealmente posizionati per trarre il massimo vantaggio possibile, data la lingua giusta.

L'altra caratteristica che aiuterà ciò che accade sono le macro. Il ritmo della lingua è solo intenso in questo momento. Le macro ti consentono di costruire con blocchi più grandi e più puliti. Guardare le biblioteche è interessante ma non racconta l'intero quadro. Devi guardare alla crescita delle biblioteche. La traiettoria di Julia è praticamente perfetta qui.

Clojure è interessante per alcuni perché non esiste un linguaggio tecnico che faccia ciò che R può, quindi alcuni cercano un linguaggio generico per colmare quel vuoto. In realtà sono un grande fan. Ma Clojure è un ordito cerebrale piuttosto grave. Clojure sarà lì per i programmatori che devono fare calcoli tecnici. Non sarà per ingegneri e scienziati. C'è troppo da imparare.

Quindi per me, Julia o qualcosa del genere sostituirà assolutamente R un giorno. È una questione di tempo.


Non ci sono molte nuove lingue che forniscono sia tipi basati su modelli che un macro ecosistema di derivazione lisp di prima classe - lo fa Julia. Questa capacità insieme alle sue caratteristiche di concorrenza e velocità (che probabilmente miglioreranno nelle versioni future) le conferiscono una forte posizione competitiva rispetto ad altre lingue, a mio avviso. Uso raramente R ma uso spesso C ++ (con modelli) e Lisp (con macro). Julia può fare entrambe le cose, in modo pulito ed efficiente in un unico linguaggio chiaro. Sono convinto che Julia dimostrerà di essere una lingua importante in futuro.
AsymLab

15

Ogni volta che vedo una nuova lingua, mi chiedo perché non è possibile migliorare una lingua esistente.

I grandi vantaggi di Python sono

  • un ricco set di moduli (non solo statistiche, ma stampa librerie, output in pdf, ecc.)
  • costrutti linguistici di cui alla fine hai bisogno (costrutti orientati agli oggetti di cui hai bisogno in un grande progetto; decoratori, chiusure, ecc. che semplificano lo sviluppo)
  • molti tutorial e una vasta community di supporto
  • accedi a mapreduce, se hai molti dati da elaborare e non ti dispiace pagare qualche centesimo per eseguirli su un cluster.

Per superare R, Julia, ecc., Python potrebbe usare

  • sviluppo della compilazione just-in-time per Python con restrizioni per darti più velocità su un singolo computer (ma mapreduce è ancora migliore se riesci a resistere alla latenza)
  • una biblioteca statistica più ricca

3
Questo può essere vero, ma per un utente molto casual, il design del linguaggio di Python potrebbe essere un po 'più difficile da usare rispetto a qualcosa come Matlab o Julia, che ha una sintassi ancora più simile alla matematica. Puoi dire y = 3x+2a Julia e funziona!
Harlan,

6
È divertente: quando ho visto Python per la prima volta circa 10 anni fa, ho avuto esattamente la stessa reazione (perché è necessario? Perché non semplicemente migliorare ciò che è già là fuori? Perché imparare un intero nuovo set di stranezze sintattiche bizzarre, nomi di classi, metodi e procedure e tutto il resto?). :-)
whuber

2
@NeilG Non sono statistici professionisti tanto quanto i ricercatori non programmatori in particolare le scienze. Python è ottimo per i programmatori, ma se tutto ciò che vuoi fare è caricare i tuoi dati psicologici e adattarli ad alcuni modelli (rapidamente), una semplice sintassi simile alla matematica potrebbe essere preferibile all'elegante design basato su oggetti di Python.
Harlan,

3
@NeilG Tieni presente che parte del successo di R è che non è solo usato dagli statistici. È usato da persone che fanno statistiche . E gli scienziati sociali, i medici e gli studenti laureati in scienze del primo anno sono utenti assolutamente casuali.
Fomite

6
Penso che il post del blog di John D Cook (membro di CrossValidated) sia perfetto: preferirei piuttosto programmare la matematica in un linguaggio generico piuttosto che cercare di codificare i problemi matematici e di sistema in un linguaggio matematico. Se la comunità Julia può tenerlo a mente, ci sono buone probabilità che il linguaggio si attenga alla programmazione analitica in generale (le statistiche sono solo una parte di ciò). Vedi johndcook.com/blog/2012/04/02/why-scipy
Josh Hemann

9

Julia non prenderà il controllo di R molto presto. Scopri Microsoft R aperto.

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

Questa è una versione avanzata di R che utilizza automaticamente tutti i core del tuo computer. È la stessa R, stessa lingua, stessi pacchetti. Quando lo installi, RStudio lo utilizzerà anche nella console. La velocità di MRO è persino più veloce di Julia. Faccio molto lavoro pesante e ho usato Julia per più di un anno. Di recente sono passato a R perché R ha un supporto migliore e RStudio è un editor fantastico. Julia è ancora in fase iniziale e probabilmente non raggiungerà Python o R molto presto.


8

Quanto segue probabilmente non merita di essere una risposta, ma è troppo importante per essere sepolto come un commento alla risposta di qualcun altro ...

Non ho sentito molto parlare del consumo di memoria, solo della velocità. L'intera semantica di R essendo pass-by-value può essere dolorosa, e questa è stata una critica al linguaggio (che è un problema separato da quanti grandi pacchetti esistono già). Una buona gestione della memoria è importante, così come avere modi di gestire l'elaborazione out-of-core (ad esempio array o pytable mappati in memoria di numpy o il formato xdf di Revolution Analytics). Mentre il compilatore JIT di PyPy consente alcuni benchmark Python sorprendenti, il consumo di memoria può essere piuttosto elevato. Quindi, qualcuno ha ancora esperienza con Julia e l'utilizzo della memoria? Sembra che ci siano perdite di memoria nella versione "alpha" di Windows che senza dubbio verranno risolte e sto ancora aspettando l'accesso a un box Linux per giocare con la lingua da solo.


Vero, ma ci sono modi per usare il riferimento pass-by in R (Classi di riferimento, per esempio).
Ari B. Friedman,

1
E R non è realmente rigorosamente pass-by-value. Una valutazione pigra e alcune ottimizzazioni intelligenti significano che spesso i dati non vengono copiati a meno che non debbano esserlo.
Ari B. Friedman,

8

Penso che sia improbabile che Julia sostituirà mai R, per molte delle ragioni precedentemente menzionate. Julia è una sostituzione Matlab, non una sostituzione R; hanno obiettivi diversi. Anche dopo che Julia ha una biblioteca di statistiche completamente definita, nessuno ci insegnerà mai una lezione di introduzione alla statistica.

Tuttavia, un'area in cui potrebbe essere incredibile è un linguaggio di programmazione ottimizzato per la velocità che è meno doloroso di C / C ++. Se fosse perfettamente collegato a R (nello stile di Rcpp), vedrebbe un sacco di utilizzo nella scrittura di segmenti di codice critici per la velocità. Purtroppo al momento non esiste un link simile:

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


Ma ora ce n'è uno: commenti.gmane.org/gmane.comp.lang.julia.devel/15153 non l'ho ancora provato (ancora).
kjetil b halvorsen,

8

Sono un novizio di Julia e sono competente. I motivi per cui trovo Julia interessante finora sono orientati alle prestazioni e alla compatibilità.

Strumenti GPU. Vorrei usare CUSPARSE per un'applicazione statistica. I risultati di CRAN indicano che non c'è molto là fuori. Julia ha a disposizione attacchi che sembrano funzionare senza problemi finora.

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)

Strumenti HPC. È possibile utilizzare un cluster in modo interattivo con più nodi di calcolo.

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

Compatibilità con Python. C'è accesso all'ecosistema Python. Ad esempio, è stato semplice scoprire come leggere i dati di imaging del cervello:

import PyCall
@pyimport nibabel

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

Compatibilità C. Di seguito viene generato un numero intero casuale utilizzando la libreria standard C.

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

Velocità. Ho pensato di vedere come il pacchetto Distributions.jl si è comportato in modo anomalo rispetto a R's rnorm, che presumo sia ottimizzato.

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 

1
@NickCox, poiché ci sono già più di una dozzina di risposte, ho pensato che potrebbe essere interessante evidenziare un angolo alternativo. Inoltre, ho pubblicato per caso una prima bozza :)
congetture il

1
La domanda era perché Julia potesse rimanere fedele alla comunità statistica, la mia risposta è incentrata su un supporto apparentemente buono per hpc + gpu, che molte persone con un intenso lavoro di calcolo potrebbero trovare interessante.
congetture il

7

Julia 1.0 è appena uscito con un IDE molto utilizzabile (Juno). È uscito un po 'tardi alla festa poiché Python ha già dominato Machine Learning, mentre R continua a dominare ogni altro tipo di analisi statistica. Detto questo, Julia sta già diventando importante nel settore della finanza e degli algoritmi di trading poiché i tempi rapidi di sviluppo E l'esecuzione sono indispensabili. Secondo me, a meno che non appaia un'altra lingua che sia nettamente migliore, l'ascesa alla ribalta di Julia probabilmente assomiglierà a qualcosa del genere:

(1) Inizia a mangiare il pranzo di MATLAB. Agli utenti MATLAB piace la sintassi MATLAB ma odiano praticamente tutto il resto. La lentezza, le costose licenze, i modi molto limitati di gestire strutture dati complesse che non sono matrici. Ricordo una citazione in cui si dice che "Se Julia sostituirà MATLAB, sarà un enorme servizio per l'umanità". Gli utenti di MATLAB possono acquisire familiarità con Julia molto rapidamente e resteranno colpiti dalla facilità con cui è possibile scrivere un codice di qualità che fa molto di più di quello che MATLAB può fare (strutture veloci che è possibile inserire in array e scorrere rapidamente?). Non solo, i ricercatori possono creare serie di strumenti a Julia (un piccolo team di dottorandi ha scritto un pacchetto di equazioni differenziali di livello mondiale) che sarebbe stato impossibile con MATLAB.

(2) Inizia a rilevare la ricerca di metodi numerici e simulazione. Il MIT sta gettando il suo peso dietro Julia e la comunità di ricerca ascolta il MIT. Le simulazioni numeriche e i nuovi metodi numerici sono problemi mal definiti che non hanno librerie. Qui è dove brilla Julia come lingua; se non ci sono librerie disponibili, è molto più facile scrivere un codice di qualità veloce in Julia rispetto a qualsiasi altra lingua. Sarà un linguaggio numerico / di simulazione scritto dai matematici per i matematici (sembra ancora simile a R?)

(3) Accade un altro passo avanti nell'apprendimento automatico che dà a Julia il vantaggio. Questo è un po 'un jolly che potrebbe non accadere. TensorFlow è eccezionale, ma è estremamente difficile da hackerare. Python ha già iniziato a mostrare crepe e TensorFlow ha iniziato ad adottare Swift (con Julia che ha ricevuto una menzione d'onore). Se si verifica un'altra svolta nel machine learning, sarà molto più semplice implementare e hackerare in un pacchetto Julia come Flux.jl.

(4) Julia inizia lentamente a raggiungere R, che richiederà del tempo. Fare statistiche in MATLAB è doloroso, ma Juila è già molto più avanti di MATLAB con Distributions.jl. Il fatto è che i flussi di lavoro R possono essere facilmente tradotti in Julia. L'unico vero vantaggio che R ha è il fatto che ci sono così tanti pacchetti scritti da statistici per statistici. Questo processo, tuttavia, è anche facile da fare a Julia. La differenza è che Julia è veloce e non devi usare un'altra lingua per le prestazioni (i pacchetti R più "seri" sono scritti in lingue come C). Il problema con R è che i pacchetti scritti in R sono troppo lenti per gestire grandi serie di dati. L'unica alternativa è quella di tradurre i pacchetti in un'altra lingua rendendo lo sviluppo in R un processo più lento di Julia.


2
La citazione sulla sostituzione di Matlab che ricordi è tratta da questa discussione . :)
Dougal,

5

Sono interessato dalla promessa di una migliore velocità e facilità di parallelizzazione utilizzando architetture diverse. Per questo motivo guarderò sicuramente lo sviluppo di Julia, ma è improbabile che lo utilizzerò fino a quando non sarà in grado di gestire modelli misti lineari generalizzati, ha un buon pacchetto bootstrap generico, un linguaggio di modello semplice per la costruzione di matrici di progettazione la capacità equivalente a ggplot2 e una vasta gamma dagli algoritmi di apprendimento automatico.

Nessuno statistico può permettersi di avere un atteggiamento fondamentalista nei confronti della scelta degli strumenti. Useremo qualunque cosa ci consenta di svolgere il lavoro nel modo più efficiente. Suppongo che starò ancora con R per qualche anno, ma sarebbe bello essere piacevolmente sorpresi.


Ciao Mervyn, e benvenuto su Stats.SE! Julia ha apportato alcuni miglioramenti sostanziali nel tempo da quando ho creato questo post (quasi un anno fa!). Douglas Bates ha trasferito parte del suo codice GLM (forse GLMM?) Su Julia dmbates.blogspot.com/2012/04/r-programmer-looks-at-julia.html ) e la pagina principale di Github ha visto molti aggiornamenti in passato anno. La mia opinione su Julia finora (l'ho usato e disattivato dallo scorso anno) è stata un ottimo strumento per la velocità, che uso per alcuni grezzi MCMC, ma non ha ancora sostituito R nella mia toolchain. Non vedo l'ora che R sia più veloce o che Julia sia più diffusa!
Christopher Aden,

Doug non ha ancora effettuato il porting dei GLMM. Se qualcuno vuole aiutarlo, sono sicuro che sarebbe felice ...
Ben Bolker,

4

Il lusso di NA in R non arriva senza penalità di prestazione. Se Julia supporta i NA con una penalità di prestazione minore, allora diventa interessante per un segmento della comunità delle statistiche, ma i NA impongono anche un lavoro extra considerevole quando si usa il codice compilato con R.

Molti dei pacchetti in R si basano su routine scritte in linguaggi legacy (C, Fortran o C ++). In alcuni casi le routine compilate sono state sviluppate all'esterno di R e successivamente utilizzate come base per i pacchetti di librerie R. In altri le routine sono state inizialmente implementate in R e poi i segmenti critici sono stati tradotti in un linguaggio compilato quando le prestazioni sono risultate carenti. Julia sarà attraente se può essere utilizzata per implementare routine equivalenti. C'è un'opportunità per progettare un supporto di basso livello per le NA in un modo che semplifichi la gestione delle NA rispetto a ciò che abbiamo ora quando usiamo R con codice compilato.

L'enorme numero di librerie R rappresenta gli sforzi di molti molti utenti. Ciò è stato possibile perché R ha fornito funzionalità che non sarebbero state altrimenti disponibili / convenienti. Se Julia deve essere ampiamente utilizzata, ha bisogno di un gruppo di utenti che ritengono che faccia ciò di cui hanno bisogno molto meglio delle alternative che valgono lo sforzo necessario per fornire cose di base (ad es. Grafica, classi di date, NA, ecc. ) disponibile dalle lingue esistenti.


4

Sarò in anticipo, non ho esperienza con R, ma lavoro con molte persone che pensano che sia uno strumento eccellente per l'analisi statistica. Il mio background è nel data warehousing e, grazie al modello di programmazione Julia facilmente distribuibile, ma più standard, penso che potrebbe essere un sostituto molto interessante per la parte trasformata degli strumenti ETL tradizionali che generalmente svolgono il lavoro molto male, la maggior parte non ha modo di creare facilmente una trasformazione standardizzata o riutilizzare i risultati di una trasformazione già eseguita su un set di dati precedente. Il supporto per tuple ben definite e tipizzate si distingue, se voglio costruire un cubo OLAP che fondamentalmente ha bisogno di costruire tuple più dettagliate (tabelle dei fatti) su tuple già calcolate, gli strumenti ETL di oggi non hanno "blocchi" per parlarne può aiutare, questa industria ha aggirato la questione in vari modi in passato, ma ci sono compromessi. I linguaggi di programmazione tradizionali possono aiutare fornendo trasformazioni definite a livello centrale e Julia potrebbe potenzialmente semplificare le aggregazioni e le distribuzioni non standard comuni nei sistemi di data warehouse più complessi.


3

Puoi anche usare Julia e R insieme. C'è l' interfaccia Julia-to-R . Con questi pacchetti puoi giocare con Julia mentre chiami R ogni volta che ha una libreria che sarebbe necessaria.


2

Julia ha senza dubbio tutte le possibilità di diventare una statistica che i sogni degli utenti diventano realtà, prendi ad esempio SAS, il potere sta nei numerosi proc scritti in C - quello che Julia può fare è darti i proc con il codice sorgente, con matrici come un tipo di dati incorporato che distribuisce con SAS / iml. Non ho dubbi che gli statistici affluiranno a Julia una volta che avranno capito cosa può fare questo cucciolo.


1
Benvenuto in Stats.SE, Jimbo. Non sono d'accordo con la tua affermazione. Penso che abbiamo visto cosa Julia è in grado di fare, ma il problema a questo punto è che non ci sono molti pacchetti specifici per dominio come ce ne sono in R. R continuerà a regnare supremo nelle statistiche open source fintanto che i ricercatori vedranno maggiori vantaggi nell'utilizzare i numerosi pacchetti nell'universo R. Questa è la mia opinione, almeno.
Christopher Aden,

2

Oh sì, Julia supererà R abbastanza rapidamente. E i motivi principali saranno le "macro", il 95% della lingua è implementato in Julia e la sua sintassi parsimoniosa e priva di rumore. Se non hai esperienza con i linguaggi di tipo lisp potresti non capirlo ancora, ma vedrai abbastanza rapidamente come l'interfaccia della formula R diventerà un meccanismo obsoleto e brutto e verrà sostituita da micro linguaggi di modellazione specializzati affini a CL macro ad anello. Anche l'accesso a riferimenti di basso livello di un oggetto è un grande vantaggio. Penso che R non abbia ancora capito che nascondere gli interni all'utente in realtà complica piuttosto che semplifica le cose.

Come la vedo ora (avendo anni di intenso uso di R alle spalle, e appena finito di leggere il manuale di Julia), i principali inconvenienti di Julia rispetto a R non supportano l'eredità strutturale (era intenzionale). Il sistema di tipi di Julia è meno ambizioso di S4; supporta anche la spedizione multipla e l'ereditarietà multipla, ma con una cattura: esiste solo un livello di classi concrete. D'altra parte vedo raramente gerarchie di classi in R più profonde di 3 livelli.

Il tempo lo dirà, ma sarà prima di quanto la maggior parte degli utenti R pensi :)


2
Hai un buon punto sulle macro: decenni dopo le persone sottovalutano ancora la potenza di Lisp. Tuttavia, come si evince dal punto 1, questa lingua è essenzialmente una sostituzione Matlab, non una sostituzione R. Penso che tu ignori anche il fatto che è la lingua più le librerie (pacchetti) che la gente usa e Julia non ha nemmeno l'1% di ciò di cui ha bisogno lì.
Wayne,

2
@Wayne, non ignoro nulla, l'OP riguardava il futuro e non quello che è adesso. Tra 5 anni, potremmo vedere molte più biblioteche per le statistiche in Julia di quante ce ne siano ora per R. E questo, solo perché Julia ha buone probabilità di essere una lingua molto migliore.
VitoshKa,

Se julia diventa davvero una sostituzione MATLAB, allora avrà enormi vantaggi nell'usare la stessa lingua per ingegneria e statistica! Le aree sovrapposte (come le serie temporali) sono enormi.
kjetil b halvorsen,

1

I primi casi d'uso target di Julia sono problemi numerici. Fondamentalmente, puoi suddividere questi campi di analisi e scienza computazionale in scienza dei dati (data driven) e scienza della simulazione (model driven). Julia si occupa prima dei casi d'uso della scienza della simulazione. Si stanno anche occupando dei casi di data science, ma più lentamente. R non sarà mai molto utile per la scienza della simulazione, ma Julia sarà molto utile per entrambi in un paio d'anni.


0

Deve essere in grado di applicare qualsiasi funzione a set di dati di grandi dimensioni che non rientrano nella memoria in modo trasparente per l'utente.
Ciò include almeno l'esecuzione di modelli di effetti misti, modelli di sopravvivenza o MCMC su set di dati che si adattano al disco ma non alla memoria. E se possibile su set di dati distribuiti su più computer.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.