¿Tiene Julia alguna esperanza de quedarse en la comunidad estadística?

161

Recientemente leí una publicación de R-Bloggers, que se vinculaba a esta publicación de blog de John Myles White sobre un nuevo lenguaje llamado Julia . Julia se aprovecha de un compilador justo a tiempo que le da tiempos de ejecución rápidos y malvados y lo pone en el mismo orden de magnitud de velocidad que C / C ++ (el mismo orden , no igualmente rápido). Además, utiliza los mecanismos de bucle ortodoxos con los que estamos familiarizados aquellos de nosotros que comenzamos a programar en lenguajes tradicionales, en lugar de las declaraciones de aplicar R y las operaciones vectoriales.

R no va a desaparecer de ninguna manera, incluso con tiempos tan increíbles de Julia. Tiene un amplio soporte en la industria y numerosos paquetes maravillosos para hacer casi cualquier cosa.

Mis intereses son de naturaleza bayesiana, donde la vectorización a menudo no es posible. Ciertamente, las tareas en serie se deben realizar utilizando bucles e implican un gran cálculo en cada iteración. R puede ser muy lento en estas tareas de bucle en serie, y C / ++ no es un paseo por el parque para escribir. Julia parece una gran alternativa a escribir en C / ++, pero está en su infancia y carece de la funcionalidad que me encanta de R. Solo tendría sentido aprender a Julia como un banco de trabajo de estadísticas computacionales si obtiene suficiente soporte de la comunidad estadística y la gente comienza a escribir paquetes útiles para ello.

Mis preguntas siguen:

  1. ¿Qué características necesita tener Julia para tener el encanto que hizo de R el lenguaje de facto de las estadísticas?

  2. ¿Cuáles son las ventajas y desventajas de aprender a Julia a hacer tareas computacionalmente pesadas, en lugar de aprender un lenguaje de bajo nivel como C / ++?

Christopher Aden
fuente
77
¿Cómo es Julia mejor que Incanter ( incanter.org ) y otros proyectos similares?
Wayne
24
Re construcciones de procedimiento (por ejemplo, bucle): eso suena como un paso gigante hacia atrás. Estamos en la cúspide de un cambio de plataformas de CPU simples y pequeñas a plataformas masivamente paralelas. A medida que esta evolución ocurra durante la próxima década, el estilo funcional de codificación fácil y automáticamente paralelizable cosechará enormes ventajas sobre el código de procedimiento. Muchas otras consideraciones intervienen en la elección de una plataforma estadística, por supuesto, pero vale la pena tenerla en cuenta como estrategia a largo plazo.
whuber
12
Christopher, un buen enfoque es formular preguntas de una manera diseñada para solicitar razones y evidencia. Por ejemplo, en lugar de "¿Tiene Julia el atractivo necesario ...", intente algo como "Qué elementos de Julia podrían darle la oportunidad de ganar tracción y por qué"; en lugar de "¿Vale la pena aprender?", pregunte "¿Por qué Julia podría valer la pena aprender ahora? ¿Cuáles son sus ventajas potenciales?" Se podría perfeccionar esa pregunta especificando qué tipo de usos de Julia que puede interesar, tales como el desarrollo de software, la solución de problemas de una sola vez, bioestadística, minería de datos, etc.
whuber
1
@Whuber: aprecio las sugerencias y las he implementado. ¡Gracias!
Christopher Aden
2
@ trolle3000 No creo que nadie afirme que la paralelización es tan automática. Sin embargo, cuando (si) ha escrito una versión funcional de un programa, ya ha realizado gran parte del esfuerzo necesario para paralelizarlo, razón por la cual aplicaciones como Mathematica pueden automatizar la paralelización, a menudo de manera bastante efectiva. Si, en cambio, ha codificado un algoritmo de manera procesal, generalmente será mucho más difícil paralelizarlo.
whuber

Respuestas:

96

Creo que la clave será si las bibliotecas comienzan a desarrollarse o no para Julia. Está muy bien ver ejemplos de juguetes (incluso si son juguetes complicados) que muestran que Julia saca a R del agua en las tareas en las que R es malo.

Pero los bucles mal hechos y los algoritmos codificados a mano no son la razón por la cual muchas de las personas que conozco que usan R usan R. Lo usan porque para casi cualquier tarea estadística bajo el sol, alguien ha escrito el código R para ello. R es tanto un lenguaje de programación como un paquete de estadísticas; en la actualidad, Julia es solo el primero.

Creo que es posible llegar allí, pero hay lenguajes mucho más establecidos (Python) que aún luchan por ser kits de herramientas estadísticas utilizables.

Fomite
fuente
¿Realmente has mirado el código de referencia (o las referencias) para saber que los métodos R están mal escritos? Estoy tratando de encontrarlo para ver cómo se usaron los diferentes idiomas ...
Josh Hemann
10
@JoshHemann He mirado lo suficiente como para saber que, en general, R es "lento". No necesariamente pierde todo el tiempo, y ocasionalmente saca a Python del agua, pero en todos esos casos la cinta de "quién gana" parece ir a donde Python o el programador de R realmente escribieron la mayoría de sus cosas en C .
Fomite
55
El código de referencia es terrible . 2000 aumentos de velocidad son posibles para sus ejemplos de R. Consulte stackoverflow.com/questions/9968578/… , especialmente los comentarios.
Ari B. Friedman
12
Tienes razón, @gsk. Por ejemplo, pisum(en github.com/JuliaLang/julia/blob/master/test/perf/perf.R ) toma 7.76 segundos, mientras que una simple reescritura usando idiomatic R ( replicate(500, sum((1 / (10000:1))^2))[500]) toma 0.137 segundos, más de una aceleración de cincuenta veces.
whuber
2
Una razón por la cual R despegó fue su compatibilidad con S-PLUS. La gente podía usar mucho código antiguo. El viejo código muy usado tiene menos errores. Con cosas nuevas como Julia, que no son compatibles con el código antiguo, necesita una situación de "aplicación asesina": algo que justifique todos los problemas de mudarse a una nueva plataforma. Es similar al nuevo lenguaje Go de Google: buen intento, pero ¿por qué debería aprenderlo?
Aksakal
56

Estoy de acuerdo con muchos de los otros comentarios. "Esperanza"? Seguro. Creo que Julia ha aprendido mucho de lo que R y Python / NumPy / Pandas y otros sistemas han hecho bien y mal a lo largo de los años. Si fuera más inteligente de lo que soy y quisiera escribir un nuevo lenguaje de programación que sería el sustrato para un entorno de desarrollo estadístico en el futuro, se parecería mucho a Julia.

Dicho esto, pasarán 5 años antes de que esta pregunta pueda ser respondida en retrospectiva. A partir de ahora, Julia carece de los siguientes aspectos críticos de un sistema de programación estadística que podría competir con R para los usuarios cotidianos:

(lista actualizada con el tiempo ...)

  • tipos de factores ordenados opcionalmente
  • la mayoría de las pruebas estadísticas y modelos estadísticos
  • programación analfabeta / soporte de análisis reproducible
  • Trazado de clase R, o incluso de clase Matlab

Para competir con R, Julia y los paquetes de estadísticas adicionales deberán estar lo suficientemente limpios y completos como para que los no programadores inteligentes, digamos estudiantes de posgrado en ciencias sociales, puedan usarlo razonablemente. Hay mucho trabajo para llegar allí. Tal vez suceda, tal vez fracase, tal vez algo más (¿R 3.0?) Lo sustituirá.

Actualizar:

Julia ahora admite DataFrames con datos / NA faltantes, módulos / espacios de nombres, formulatipos e model.matrixinfraestructura, trazado (más o menos), soporte de bases de datos (pero todavía no para DataFrames) y pasar argumentos por palabras clave. Ahora también hay un IDE (Julia Studio), soporte de Windows, algunas pruebas estadísticas y algo de soporte de fecha / hora.

Harlan
fuente
literate programming/reproduce-able analysis support-> ver IJulia .
Piotr Migdal
1
Agregue el núcleo iJulia para el ecosistema de portátiles iPython / Jupyter.
thecity2
2
Julia Studio está siendo eliminada, y Juno ahora es el IDE
Antony
3
2.5 años después de que esta respuesta se publicara por primera vez, ahora se implementan dos tercios de los elementos de la lista de "elementos imprescindibles". Creo que esa es la mejor evidencia que puedes encontrar de que Julia tiene una promesa real.
senderle
Deben haber pasado 5 años. ¿Ya llegamos, @Harlan?
StasK
35

Para mí, una cosa muy importante para un lenguaje de análisis de datos es tener funcionalidad de álgebra de consulta / relacional con valores predeterminados razonables y diseño orientado de forma interactiva, e idealmente debería ser un lenguaje incorporado. En mi opinión, ningún lenguaje FOSS que he usado hace esto de manera efectiva, ni siquiera R.

data.frame es muy complicado para trabajar de forma interactiva; por ejemplo, imprime toda la estructura de datos en la invocación, la sintaxis $ es difícil de trabajar programáticamente, la consulta requiere auto referencia redundante (es decir, DF[DF$x < 10]), las uniones y la agregación son incómodas. Data.table resuelve la mayoría de estas molestias, pero como no es parte de la implementación principal, la mayoría del código R no hace uso de sus instalaciones.

Los pandas en python sufren las mismas fallas.

Estas quejas pueden parecer quisquillosas, pero estas fallas se acumulan y al final son significativas en conjunto, ya que terminan costando mucho tiempo.

Creo que si Julia tiene éxito como entorno de análisis de datos, se debe dedicar un esfuerzo a implementar operadores de tipo SQL (sin el equipaje de la sintaxis SQL) en un tipo de datos de tabla fácil de usar.

Yike Lu
fuente
1
+ 1 - Un punto interesante, cuidadosamente explicado. ¡Bienvenido a nuestra comunidad!
whuber
44
Para ser quisquilloso, los grandes Pandas DataFrames en realidad no imprimen todo su contenido cuando se invocan, como sucede en R. Cambian a mostrar encabezados de columna junto con un recuento de valores nulos / no nulos. Además, si bien estoy de acuerdo en que la sintaxis no es ideal, los problemas de alcance dificultan la eliminación de la autorreferencia para el filtrado de estilo de comprensión. Es más extenso, pero también es resistente a las colisiones de espacio de nombres si un DataFrame tiene columnas adicionales en tiempo de ejecución que no esperaba.
goodside
29

Puedo firmar bajo lo que dijeron Dirk y EpiGrad; Sin embargo, hay una cosa más que hace de R un idioma único en su nicho: el sistema de tipos orientado a datos.

R's fue especialmente diseñado para manejar datos, es por eso que está centrado en vectores y tiene cosas como data.frames, factores, NA y atributos.
Los tipos de Julia están, por otro lado, orientados al rendimiento numérico, por lo que tenemos escalares, modos de almacenamiento bien definidos, uniones y estructuras.

Esto puede parecer benigno, pero todos los que han intentado hacer estadísticas con MATLAB saben que realmente duele.

Entonces, al menos para mí, Julia no puede ofrecer nada que no pueda arreglar con un trozo C de pocas líneas y mata mucha expresividad realmente útil.

usuario88
fuente
44
(+1) Buen punto. Algunas reflexiones adicionales: la falta de data.frameinstalaciones similares en Python me ha molestado durante mucho tiempo, pero ahora Pandas parece haber resuelto este problema. Las fórmulas se encuentran entre algunas de las extensiones planificadas de modelos de estadísticas (bueno, sabemos que a veces es mejor evitar la interfaz de fórmulas en R). Hay una propuesta de data.frame para Julia (¡bastante rápida en comparación con Python!), (...)
chl
55
Creo que @mbq también tiene un punto sobre C. Si necesito velocidad en el mismo orden de magnitud que C / C ++ ... Puedo usar C / C ++ con R.
Fomite
44
@EpiGrad, sí, puedes escribir C / C ++ e interactuar limpiamente con R. Pero eso es una debilidad, no una fortaleza del lenguaje. Con Julia, los usuarios finales nunca necesitarán escribir C para obtener velocidad.
Harlan
2
@Harlan Es solo una debilidad si ya conoces tanto a Julia como a C. Afirmaría que pasé el tiempo en C <tiempo que pasé aprendiendo un nuevo idioma y reimplementando todo desde cero.
Fomite
99
@Harlan Y para ser francos, esas personas no van a reescribir sus cosas en Julia. R como paquete de estadísticas, no un lenguaje de programación es su caso de uso .
Fomite
26

Puedo ver a Julia reemplazando a Matlab, lo que sería un gran servicio para la humanidad.

Para reemplazar R, deberías considerar todas las cosas que Neil G, Harlan y otros han mencionado, además de un gran factor que no creo que se haya abordado: la fácil instalación de la aplicación y sus bibliotecas.

En este momento, puede descargar un binario de R para Mac, Windows o Linux. Funciona fuera de la caja con una gran selección de métodos estadísticos. Si desea descargar un paquete, es un simple comando o clic del mouse. Simplemente funciona

Fui a descargar Julia y no es simple. Incluso si descarga el binario, debe tener instalado gfortran para obtener las bibliotecas adecuadas. Descargué la fuente e intenté makey falló sin un mensaje realmente útil. Tengo una licenciatura y un posgrado en ciencias de la computación, por lo que podría hurgar y hacer que funcione si estaba tan dispuesto. (No lo soy) ¿Joe Statistician hará eso?

R no solo tiene una gran selección de paquetes, tiene un sistema bastante sofisticado que crea binarios de la aplicación y casi todos los paquetes, automáticamente. Si, por alguna razón, necesita compilar un paquete desde el origen, eso no es realmente más difícil (siempre que tenga un compilador apropiado, etc., instalado en su sistema). No puede ignorar esta infraestructura, hacer todo a través de github y esperar una amplia adopción.

EDITAR: quería jugar con Julia, se ve emocionante. Dos problemas:

1) Cuando intenté instalar paquetes adicionales (olvídate de cómo se llaman en Julia), falló con oscuros errores. Evidentemente, mi Mac no tiene una herramienta similar a la que esperaban. No solo falla, sino que deja cosas por ahí que tengo que eliminar manualmente o otras instalaciones fallarán.

2) Forzan cierto espacio en una línea de código. No tengo los detalles frente a mí, pero tiene que ver con macros y no tener un espacio entre la macro y el paréntesis que abre sus argumentos. Ese tipo de restricción realmente me molesta, ya que he desarrollado mi formato de código durante muchos años y lenguajes y realmente pongo un espacio entre una función / nombre de macro y el paréntesis de apertura. Entiendo algunas restricciones de formato de código, pero ¿espacios en blanco dentro de una línea?

Wayne
fuente
55
Julia todavía está MUY en pañales. No soy historiador, pero apuesto a que los binarios limpios de R tampoco salieron en los primeros meses. Su punto sobre el sistema de distribución es algo que no he visto mencionar mucho hasta ahora. Por otra parte, también apostaría a que CRAN no surgió al mismo tiempo que R. Un "CJAN" definitivamente sería bueno para la adopción a gran escala.
Christopher Aden
77
Quizás le interese saber, @Christopher, que R es realmente un clon desarrollado independientemente de un paquete (S, luego S-Plus) que había sido un éxito comercial (leve) y estaba en desarrollo diez años antes. Eso le dio una ventaja significativa que Julia (y la mayoría de los demás esfuerzos) nunca tuvo.
whuber
3
@ChristopherAden: Estoy de acuerdo en que Julia aún es joven. Pero estoy totalmente en desacuerdo con que "un 'CJAN' definitivamente sería bueno para la adopción a gran escala": es una necesidad absoluta. Las únicas herramientas que se me ocurren que no tienen una infraestructura similar a CRAN son altamente especializadas, como JAGS. Pero Julia, como R, es de uso general.
Wayne
10
El día que Open Source Language reemplazará a MATLAB será el mejor día para el mundo de la ingeniería.
Royi
99
"Puedo ver a Julia reemplazando a Matlab, lo que sería un gran servicio para la humanidad". No podría estar mas de acuerdo.
davidav
24

El lenguaje de Julia es bastante nuevo; Su tiempo en el foco puede medirse en semanas (aunque su tiempo de desarrollo puede medirse en años). Ahora, esas semanas en el punto de mira fueron semanas muy emocionantes --- vea, por ejemplo, la reciente charla en Stanford donde "acababa de comenzar" --- pero lo que pida en términos de infraestructura más amplia y soporte de paquetes llevará mucho más tiempo para materializar.

Así que seguiría usando R y sería consciente de las alternativas en desarrollo. El año pasado mucha gente se volvió loca por Clojure; este año Julia es el nuevo sabor reinante. Veremos si se pega.

Dirk Eddelbuettel
fuente
16
Debido a lo que he visto a través de Rcpp, estoy aún más impresionada por Julia: aproximadamente 50, 60, 70 veces más para un bucle simple como en MCMC, y varios cientos de veces para ejemplos "degenerados" como fibonacci son esencialmente lo mismo que Rcpp tiene! Pero también sé que con Rcpp todavía tengo acceso a los paquetes 3700 CRAN --- así como a innumerables bibliotecas C ++ --- mientras que Julia en este momento no tiene casi nada. Dicho esto, la promesa de Julia es enorme. Pero tal vez hay un "entonces" y un "ahora". El tiempo dirá.
Dirk Eddelbuettel
2
Y no olvides Incanter, que se supone que se convertirá en un entorno estadístico basado en Clojure. ¿Cómo es Julia superior a eso?
Wayne
2
@Wayne, no enturbiemos las aguas aquí. Abra una nueva pregunta para eso (tal vez una que solicite una comparación entre varios idiomas)
naught101
2
@ naught011: Simplemente estoy haciendo eco de la idea de Dirk de que Clojure era el sabor del mes, entonces específicamente Incanter, ahora Julia. No creo que Julia o Incanter (o Clojure) tengan la posibilidad de ser plataformas estadísticas generalizadas.
Wayne
2
No tengo idea, pero con gusto actualizo el lado R: a partir de hoy más de 6400 paquetes en CRAN, y ahora más de 350 de los que usan Rcpp. Aún funciona para mí. La gente de Julia parece activa y feliz, y tener una opción es algo bueno. No hay un solo idioma para todos los problemas: lo siento, Python .
Dirk Eddelbuettel
19

Bruce Tate aquí, autor de Siete idiomas en siete semanas. Aquí hay algunos pensamientos. Estoy trabajando en Julia para el libro de seguimiento. Lo siguiente es solo mi opinión después de algunas semanas de juego.

Hay dos fuerzas fundamentales en juego. Primero, todos los idiomas tienen una vida útil. R será reemplazado algún día. No sabemos cuando. Los nuevos idiomas tienen un tiempo extremadamente difícil de evolucionar. Cuando un nuevo lenguaje evoluciona, generalmente resuelve un punto de dolor abrumador.

Estas dos cosas están relacionadas. Para mí, estamos empezando a ver que un tema toma forma alrededor de idiomas como R. No es lo suficientemente rápido, y es más difícil de lo que debe ser. Aquellos que pueden vivir dentro de un determinado sobre de rendimiento y permanecer en bibliotecas establecidas están bien. Aquellos que no pueden necesitar más y están empezando a buscar más.

La cuestión es que las arquitecturas informáticas están cambiando y, para aprovecharlas, el lenguaje y sus construcciones deben construirse de cierta manera. La opinión de Julia sobre la concurrencia es interesante. Optimiza lo correcto para dicho lenguaje: distribución transparente y el movimiento eficiente de datos entre procesos. Cuando uso a Julia para tareas típicas, mapas y transformaciones y cosas similares, solo estoy llamando a funciones. No tengo que preocuparme por la fontanería.

Para mí, el hecho de que Julia sea más rápida en un procesador es interesante, pero no demasiado perjudicial para R. Lo que es interesante para mí es que a medida que los procesadores dependen cada vez más del multinúcleo para el rendimiento, los problemas informáticos técnicos están en una posición ideal. para aprovechar al máximo, dado el lenguaje correcto.

La otra característica que ayudará a que eso suceda son las macros. El ritmo del idioma es intenso en este momento. Las macros le permiten construir con bloques de construcción más grandes y limpios. Mirar las bibliotecas es interesante pero no cuenta la imagen completa. Debe observar el crecimiento de las bibliotecas. La trayectoria de Julia es bastante acertada aquí.

Clojure es interesante para algunos porque no hay un lenguaje técnico que haga lo que R puede hacer, por lo que algunos buscan un lenguaje de propósito general para llenar ese vacío. En realidad soy un gran fan. Pero Clojure es una deformación cerebral bastante grave. Clojure estará allí para los programadores que necesitan hacer computación técnica. No será para ingenieros y científicos. Simplemente hay mucho que aprender.

Entonces, para mí, Julia o algo así reemplazará absolutamente a R algún día. Es cuestión de tiempo.

usuario1295658
fuente
No hay muchos lenguajes nuevos que ofrezcan tanto tipos de plantillas como un macro ecosistema derivado de lisp de primera clase, Julia lo hace. Esta capacidad, junto con sus características de concurrencia y velocidad (que probablemente mejorará en futuras versiones) le da una fuerte posición competitiva frente a otros idiomas, en mi opinión. Raramente uso R, pero con frecuencia uso C ++ (con plantillas) y Lisp (con macros). Julia puede hacer ambas cosas, limpia y eficientemente en un solo lenguaje claro. Estoy convencido de que Julia demostrará ser un idioma importante en el futuro.
AsymLabs
15

Cada vez que veo un nuevo idioma, me pregunto por qué no se puede mejorar un idioma existente.

Las grandes ventajas de Python son

  • Un amplio conjunto de módulos (no solo estadísticas, sino también gráficas de bibliotecas, salida a pdf, etc.)
  • construcciones de lenguaje que terminas necesitando a largo plazo (construcciones orientadas a objetos que necesitas en un gran proyecto; decoradores, cierres, etc. que simplifican el desarrollo)
  • muchos tutoriales y una gran comunidad de soporte
  • acceso a mapreduce, si tiene muchos datos para procesar y no le importa pagar unos centavos para ejecutarlos en un clúster.

Para superar a R, Julia, etc., Python podría usar

  • desarrollo de compilación justo a tiempo para Python restringido para darle más velocidad en una sola máquina (pero mapreduce es aún mejor si puede soportar la latencia)
  • una biblioteca estadística más rica
Neil G
fuente
3
Esto puede ser cierto, pero para un usuario muy informal, el diseño del lenguaje de Python puede ser un poco más difícil de usar que algo como Matlab o Julia, que tiene una sintaxis aún más matemática. ¡Puedes decir y = 3x+2en Julia y funciona!
Harlan
66
Eso es divertido: cuando vi Python por primera vez hace más de 10 años, tuve exactamente la misma reacción (¿por qué es necesario? ¿Por qué no solo mejorar lo que ya existe? ¿Por qué aprender un conjunto completamente nuevo de peculiaridades sintácticas extrañas, nombres de clases, métodos? , y procedimientos, y todo lo demás?). :-)
whuber
2
@NeilG No son estadísticos profesionales tanto como investigadores no programadores, especialmente en ciencias. Python es ideal para programadores, pero si todo lo que quiere hacer es cargar sus datos de psicología y ajustar algunos modelos (rápidamente), una sintaxis matemática muy simple podría ser preferible al elegante diseño basado en objetos de Python.
Harlan
3
@NeilG Tenga en cuenta que parte del éxito de R es que no solo lo usan los estadísticos. Lo usan las personas que hacen estadísticas . Y los científicos sociales, los médicos y los estudiantes de posgrado en ciencias de primer año son usuarios absolutamente casuales.
Fomite
66
Creo que la publicación de blog de John D Cook (miembro de CrossValidated) es acertada: prefiero programar las matemáticas en un lenguaje de propósito general que tratar de codificar problemas matemáticos y de sistemas en un lenguaje matemático. Si la comunidad de Julia puede tener esto en cuenta, existe una buena posibilidad de que el lenguaje se mantenga para la programación analítica en general (las estadísticas son solo una parte de eso). Ver johndcook.com/blog/2012/04/02/why-scipy
Josh Hemann el
9

Julia no se hará cargo de R muy pronto. Echa un vistazo a Microsoft R abierto.

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

Esta es una versión mejorada de R que usa automáticamente todos los núcleos de su computadora. Es la misma R, el mismo lenguaje, los mismos paquetes. Cuando lo instales, RStudio también lo usará en la consola. La velocidad de MRO es incluso más rápida que Julia. Hago mucha informática pesada y he usado a Julia más de un año. Cambié a R recientemente porque R tiene un mejor soporte y RStudio es un editor increíble. Julia todavía está en una etapa temprana y posiblemente no esté alcanzando a Python o R muy pronto.

Milton Mai
fuente
8

Lo siguiente probablemente no merece ser una respuesta, pero es demasiado importante para ser enterrado como un comentario a la respuesta de otra persona ...

No he escuchado mucho sobre el consumo de memoria, solo la velocidad. El hecho de que la semántica completa de R pase por valor puede ser dolorosa, y esta ha sido una crítica del lenguaje (que es un tema separado de cuántos paquetes geniales ya existen). La buena gestión de la memoria es importante, al igual que tener formas de lidiar con el procesamiento fuera del núcleo (por ejemplo, matrices mapeadas en memoria o pytables de numpy , o el formato xdf de Revolution Analytics) Si bien el compilador JIT de PyPy permite algunos puntos de referencia llamativos de Python, el consumo de memoria puede ser bastante alto. Entonces, ¿alguien tiene experiencia con Julia y el uso de memoria todavía? Parece que hay pérdidas de memoria en la versión "alfa" de Windows que sin duda se abordarán, y todavía estoy esperando el acceso a una caja de Linux para jugar con el lenguaje yo mismo.

Josh Hemann
fuente
Es cierto, pero hay formas de utilizar el paso por referencia en R (Clases de referencia, por ejemplo).
Ari B. Friedman
1
Y R no es realmente estrictamente paso por valor. La evaluación diferida y alguna optimización inteligente significa que a menudo los datos no se copian a menos que sea necesario.
Ari B. Friedman
8

Creo que es poco probable que Julia reemplace a R, por muchas de las razones mencionadas anteriormente. Julia es un reemplazo de Matlab, no un reemplazo de R; Tienen diferentes objetivos. Incluso después de que Julia tenga una biblioteca de estadísticas completamente desarrollada, nadie enseñará una clase de Introducción a la Estadística en ella.

Sin embargo, un área en la que podría ser increíble es como un lenguaje de programación de velocidad optimizada que es menos doloroso que C / C ++. Si se vinculó sin problemas a R (en el estilo de Rcpp), sería muy útil escribir segmentos de código críticos para la velocidad. Lamentablemente, dicho enlace no existe actualmente:

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

Ari B. Friedman
fuente
Pero ahora hay uno: comments.gmane.org/gmane.comp.lang.julia.devel/15153 no lo probé (todavía).
kjetil b halvorsen
8

Soy un novato de Julia y soy R competente. Las razones por las que a Julia me parece interesante hasta ahora están orientadas al rendimiento y la compatibilidad.

Herramientas de GPU. Me gustaría usar CUSPARSE para una aplicación estadística. Los resultados de CRAN indican que no hay mucho por ahí. Julia tiene enlaces disponibles que parecen funcionar sin problemas hasta ahora.

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)

Herramientas de HPC. Se puede usar un clúster interactivamente con múltiples nodos de cómputo.

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

Compatibilidad con Python. Hay acceso al ecosistema de Python. Por ejemplo, fue sencillo descubrir cómo leer datos de imágenes cerebrales:

import PyCall
@pyimport nibabel

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

C compatibilidad. Lo siguiente genera un entero aleatorio usando la biblioteca estándar de C.

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

Velocidad. Pensé que vería cómo funcionaba el paquete Distributions.jl contra el rnorm de R, que supongo está optimizado.

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

julia> @elapsed rand(F, 1000000)
0.03422067

En R:

> system.time(rnorm(1000000, mean=3, sd=1))
   user  system elapsed 
  0.262   0.003   0.266 
8 revoluciones
fuente
1
@ NickCox, como ya hay más de una docena de respuestas, pensé que podría ser interesante resaltar un ángulo alternativo. Además, publiqué un borrador inicial accidentalmente :)
conjeturas
1
La pregunta era por qué Julia podría quedarse en la comunidad estadística, mi respuesta se centra en un soporte aparentemente bueno para hpc + gpu, que muchas personas con trabajo intensivo en computación pueden encontrar interesante.
conjeturas
7

Julia 1.0 acaba de salir con un IDE muy útil (Juno). Llegó un poco tarde a la fiesta ya que Python ya ha dominado el aprendizaje automático, mientras que R continúa dominando cualquier otro tipo de análisis estadístico. Dicho esto, Julia ya está ganando protagonismo en el área de algoritmos financieros y comerciales, ya que el tiempo de desarrollo rápido y la ejecución son imprescindibles. En mi opinión, a menos que aparezca otro idioma que sea claramente mejor, el ascenso de Julia a la prominencia probablemente se verá así:

(1) Comienza a comer el almuerzo de MATLAB. A los usuarios de MATLAB les gusta la sintaxis de MATLAB pero odian prácticamente todo lo demás. La lentitud, las costosas licencias, las formas muy limitadas de manejar estructuras de datos complejas que no son matrices. Recuerdo una cita en la que se dice que "si Julia reemplaza a MATLAB, será un gran servicio para la humanidad". Los usuarios de MATLAB pueden llegar a dominar a Julia muy rápidamente y quedarán impresionados por la facilidad con la que se escribe código de calidad que hace mucho más de lo que MATLAB puede hacer (¿Estructuras que son rápidas que puede colocar en matrices e iterar rápidamente?). No solo esto, los investigadores pueden hacer cajas de herramientas serias en Julia (un pequeño equipo de estudiantes de doctorado escribió un paquete de ecuaciones diferenciales de clase mundial) que hubiera sido imposible con MATLAB.

(2) Comienza a hacerse cargo de la investigación en métodos numéricos y simulación. El MIT está respaldando a Julia, y la comunidad de investigadores escucha al MIT. Las simulaciones numéricas y los nuevos métodos numéricos son problemas mal definidos que no tienen bibliotecas. Aquí es donde brilla Julia como idioma; Si no hay bibliotecas disponibles, es mucho más fácil escribir código de calidad rápida en Julia que en cualquier otro idioma. Será un lenguaje numérico / de simulación escrito por matemáticos para matemáticos (¿suena similar a R todavía?)

(3) Otro avance en Machine Learning ocurre que le da a Julia la ventaja. Este es un poco un comodín que podría no suceder. TensorFlow es genial, pero es extremadamente difícil de hackear. Python ya comenzó a mostrar grietas y TensorFlow comenzó a adoptar Swift (con Julia recibiendo una mención de honor). Si ocurre otro avance en el aprendizaje automático, será mucho más fácil implementar y piratear un paquete de Julia como Flux.jl.

(4) Julia comienza a alcanzar lentamente a R, lo que llevará un tiempo. Hacer estadísticas en MATLAB es doloroso, pero Juila ya está muy por delante de MATLAB con Distributions.jl. El hecho es que los flujos de trabajo R se pueden traducir fácilmente a Julia. La única ventaja real que tiene R es el hecho de que hay muchos paquetes escritos por estadísticos para estadísticos. Sin embargo, este proceso también es fácil de hacer en Julia. La diferencia es que Julia es rápida y no tiene que usar otro idioma para el rendimiento (los paquetes R más "serios" están escritos en lenguajes como C). El problema con R es que los paquetes escritos en R son demasiado lentos para manejar grandes conjuntos de datos. La única alternativa es traducir los paquetes a otro idioma haciendo que el desarrollo en R sea un proceso más lento que Julia.

Deducción
fuente
2
La cita sobre el reemplazo de Matlab que recuerdas es de este hilo . :)
Dougal
5

Me interesa la promesa de una mejor velocidad y una fácil paralelización utilizando diferentes arquitecturas. Por esa razón, ciertamente veré el desarrollo de Julia, pero es poco probable que lo use hasta que pueda manejar modelos mixtos lineales generalizados, tenga un buen paquete de arranque genérico, un lenguaje de modelo simple para construir matrices de diseño, la capacidad equivalente a ggplot2 y una amplia gama de algoritmos de aprendizaje automático.

Ningún estadista puede permitirse tener una actitud fundamentalista respecto a la elección de herramientas. Utilizaremos lo que nos permita realizar el trabajo de la manera más eficiente. Supongo que todavía me quedaré con R durante algunos años, pero sería agradable estar gratamente sorprendido.

Mervyn thomas
fuente
Hola Mervyn, y bienvenido a Stats.SE! Julia ha realizado algunas mejoras sustanciales desde que creé esta publicación (¡hace casi un año!). Douglas Bates transfirió parte de su código GLM (¿tal vez GLMM?) A Julia dmbates.blogspot.com/2012/04/r-programmer-looks-at-julia.html ), y la página principal de Github ha visto muchas actualizaciones en el pasado año. Mi opinión sobre Julia hasta ahora (la he usado de vez en cuando desde el año pasado) ha sido una buena herramienta para la velocidad, que uso para algunos MCMC crudos, pero aún no ha reemplazado a R en mi cadena de herramientas. ¡No puedo esperar a que R sea más rápido o que Julia esté más extendida!
Christopher Aden
Doug aún no ha portado GLMM. Si alguien quiere ayudar con eso, estoy seguro de que sería feliz ...
Ben Bolker
4

El lujo de NA en R no viene sin penalizaciones de rendimiento. Si Julia admite NA con una penalización de rendimiento menor, se vuelve interesante para un segmento de la comunidad de estadísticas, pero NA también impone un trabajo adicional considerable cuando se usa código compilado con R.

Muchos de los paquetes en R se basan en rutinas escritas en lenguajes heredados (C, Fortran o C ++). En algunos casos, las rutinas compiladas se desarrollaron fuera de R y luego se usaron como base para los paquetes de la biblioteca R. En otros, las rutinas se implementaron primero en R y luego los segmentos críticos se tradujeron a un lenguaje compilado cuando se descubrió que faltaba rendimiento. Julia será atractiva si se puede usar para implementar rutinas equivalentes Existe la oportunidad de diseñar soporte de bajo nivel para NA de una manera que simplifique el manejo de NA sobre lo que tenemos ahora cuando usamos R con código compilado.

La gran cantidad de bibliotecas R representa los esfuerzos de muchos usuarios. Esto fue posible porque R proporcionó capacidades que de otro modo no estaban disponibles / asequibles. Si Julia se va a utilizar ampliamente, necesita un grupo de usuarios que descubran que hace lo que necesitan mucho mejor que las alternativas que vale la pena el esfuerzo necesario para proporcionar cosas muy básicas (por ejemplo, gráficos, clases de fechas, NA, etc.) ) disponible en idiomas existentes.

George N. White III
fuente
4

Seré directo, no tengo experiencia con R, pero trabajo con muchas personas que piensan que es una excelente herramienta para el análisis estadístico. Mi experiencia es en el almacenamiento de datos, y debido al modelo de programación fácilmente distribuido pero más estándar de Julia, creo que podría ser un sustituto muy interesante para la parte de transformación de las herramientas ETL tradicionales que generalmente hacen el trabajo muy mal, la mayoría no tiene forma de crear fácilmente una transformación estandarizada o reutilizar los resultados de una transformación ya realizada en un conjunto de datos anterior. Se destaca el soporte para tuplas tipeadas y definidas, si quiero construir un cubo OLAP que básicamente necesita construir tuplas más detalladas (tablas de hechos) a partir de tuplas ya calculadas, las herramientas ETL de hoy no tienen 'bloques de construcción' para hablar de eso. poder ayudar, Esta industria ha trabajado en torno a este problema a través de diversos medios en el pasado, pero hay compensaciones. Los lenguajes de programación tradicionales pueden ayudar al proporcionar transformaciones definidas centralmente, y Julia podría simplificar las agregaciones y distribuciones no estándar comunes en los sistemas de almacenamiento de datos más complejos.

Preston
fuente
3

También puedes usar Julia y R juntas. Hay interfaz de Julia-a-R . Con estos paquetes puedes jugar con Julia mientras llamas a R cuando tenga una biblioteca que sea necesaria.

vasili111
fuente
2

Julia tiene, sin duda, todas las posibilidades de convertirse en un sueño de los usuarios avanzados de las estadísticas hecho realidad, tome SAS por ejemplo, su poder radica en los numerosos procesos escritos en C: lo que Julia puede hacer es proporcionarle los procesos con el código fuente, con matrices como un dispensador de tipo de datos incorporado con SAS / iml. No tengo dudas de que los estadísticos acudirán en masa a Julia una vez que se den cuenta de lo que este cachorro puede hacer.

Jimbo He
fuente
1
Bienvenido a Stats.SE, Jimbo. No estoy de acuerdo con tu afirmación. Creo que hemos visto lo que Julia es capaz de hacer, pero el problema en este punto es que no hay tantos paquetes específicos de dominio para él como en R. R continuará reinando en las estadísticas de código abierto. siempre y cuando los investigadores vean más beneficios al usar los numerosos paquetes en el universo R. Esa es mi opinión, al menos.
Christopher Aden
2

Ah, sí, Julia superará a R bastante rápido. Y las razones principales serán "macros", el 95% del lenguaje se implementa en Julia, y su sintaxis parsimoniosa y sin ruido. Si no tiene experiencia con el tipo de lenguajes lisp, es posible que aún no lo entienda, pero verá muy rápidamente cómo la interfaz de fórmula R se convertirá en un mecanismo obsoleto y feo, y será reemplazado por micro lenguajes de modelado especializados similares a CL macro de bucle El acceso a referencias de bajo nivel de un objeto también es una gran ventaja. Creo que R aún no entendía que ocultar aspectos internos del usuario realmente complica y simplifica las cosas.

Como lo veo ahora (teniendo años de uso intensivo de R detrás, y acaba de terminar de leer el manual de Julia), los principales inconvenientes de Julia con respecto a R no son soporte para la herencia estructural (esto fue intencional). El sistema de tipos de Julia es menos ambicioso que S4; también admite despacho múltiple y herencia múltiple, pero con una captura: solo hay un nivel de clases concretas. Por otro lado, rara vez veo jerarquías de clases en R más profundas que 3 niveles.

El tiempo lo dirá, pero será antes de lo que la mayoría de los usuarios de R piensan :)

VitoshKa
fuente
2
Haces un buen punto sobre las macros: décadas después, la gente todavía subestima lo poderoso que es realmente Lisp. Sin embargo, como implica en el punto 1, este lenguaje es esencialmente un reemplazo de Matlab, no un reemplazo de R. Creo que también ignoras el hecho de que es el lenguaje más las bibliotecas (paquetes) lo que la gente usa y Julia ni siquiera tiene el 1% de lo que necesita allí.
Wayne
2
@Wayne, no ignoro nada, el OP fue sobre el futuro y no sobre lo que es ahora. En 5 años, podríamos ver muchas más bibliotecas de estadísticas en Julia de las que hay ahora para R. Y esto, solo porque Julia tiene una buena oportunidad de ser un idioma mucho mejor.
VitoshKa
Si Julia realmente se convierte en un reemplazo de MATLAB, ¡tendrá enormes beneficios usar el mismo lenguaje para ingeniería y estadísticas! Las áreas superpuestas (como las series de tiempo) son enormes.
kjetil b halvorsen
1

Los primeros casos de uso objetivo de Julia son problemas numéricos. Básicamente, puede dividir estos campos de análisis y ciencia computacional en ciencia de datos (basada en datos) y ciencia de simulación (basada en modelos). Julia se ocupa primero de los casos de uso de la ciencia de la simulación. También se ocupan de los casos de la ciencia de datos, pero más lentamente. R nunca será muy útil para la ciencia de la simulación, pero Julia será muy útil para ambos en un par de años.

Jamie Lawson
fuente
0

Debe poder aplicar cualquier función a grandes conjuntos de datos que no se ajusten a la memoria de forma transparente para el usuario.
Eso incluye al menos ejecutar modelos de efectos mixtos, modelos de supervivencia o MCMC en conjuntos de datos que se ajustan en el disco pero no en la memoria. Y si es posible en conjuntos de datos distribuidos en varias computadoras.

skan
fuente