Julia tem alguma esperança de permanecer na comunidade estatística?

Recentemente, li um post da R-Bloggers, vinculado a este post do John Myles White sobre um novo idioma chamado Julia . Julia tira proveito de um compilador just-in-time que oferece maus tempos de execução rápidos e o coloca na mesma ordem de magnitude de velocidade que o C / C ++ (a mesma ordem , não igualmente rápida). Além disso, ele usa os mecanismos de loop ortodoxo com os quais nós, que começamos a programar em linguagens tradicionais, estão familiarizados, em vez das instruções de aplicação de R e operações de vetor.

R não está indo embora de maneira alguma, mesmo com esses horários impressionantes de Julia. Possui amplo suporte na indústria e vários pacotes maravilhosos para fazer praticamente qualquer coisa.

Meus interesses são de natureza bayesiana, onde a vetorização geralmente não é possível. Certamente tarefas em série devem ser executadas usando loops e envolvem computação pesada a cada iteração. O R pode ser muito lento nessas tarefas de loop serial, e o C / ++ não é um passeio no parque para escrever. Julia parece ser uma ótima alternativa para escrever em C / ++, mas está em sua infância e carece de muitas das funcionalidades que eu amo sobre R. Só faria sentido aprender Julia como uma bancada de estatística computacional se ela receber suporte suficiente da comunidade de estatísticas e as pessoas começam a escrever pacotes úteis para isso.

Minhas perguntas seguem:

1. Que recursos Julia precisa ter para ter o fascínio que fez de R a linguagem de fato das estatísticas?

2. Quais são as vantagens e desvantagens de aprender Julia a executar tarefas pesadas em termos de computação, em vez de aprender uma linguagem de baixo nível como C / ++?

Eu acho que a chave será se as bibliotecas começam ou não a ser desenvolvidas para Julia. É bom ver exemplos de brinquedos (mesmo que sejam complicados) mostrando que Julia sopra R fora da água nas tarefas em que R é ruim.

Mas loops mal-feitos e algoritmos codificados à mão não são o motivo pelo qual muitas pessoas que conheço que usam R usam R. Eles o usam porque, para quase qualquer tarefa estatística sob o sol, alguém escreveu código R para ele. R é uma linguagem de programação e um pacote de estatísticas - atualmente, Julia é apenas a primeira.

Eu acho que é possível chegar lá, mas existem muito mais linguagens estabelecidas (Python) que ainda lutam por serem kits de ferramentas estatísticas utilizáveis.

Eu concordo com muitos outros comentários. "Esperança"? Certo. Acho que Julia aprendeu muito com o que R e Python / NumPy / Pandas e outros sistemas fizeram certo e errado ao longo dos anos. Se eu fosse mais esperto do que sou e desejasse escrever uma nova linguagem de programação que seria o substrato para um ambiente de desenvolvimento estatístico no futuro, seria muito parecido com Julia.

Dito isto, serão necessários cinco anos para que esta pergunta possa ser respondida em retrospectiva. No momento, Julia não possui os seguintes aspectos críticos de um sistema de programação estatística que poderia competir com o R para usuários do dia-a-dia:

(lista atualizada ao longo do tempo ...)

• tipos de fatores pedidos opcionalmente
• maioria dos testes estatísticos e modelos estatísticos
• suporte à programação alfabetizada / análise reproduzível
• Plotagem da classe R ou mesmo da classe Matlab

Para competir com R, Julia e pacotes de estatísticas complementares precisam ser limpos o suficiente e completos o suficiente para que não programadores inteligentes, dizem estudantes de ciências sociais, possam usá-lo razoavelmente. Há muito trabalho para chegar lá. Talvez isso aconteça, talvez fracasse, talvez algo mais (R 3.0?) A substitua.

Atualizar:

Julia agora suporta DataFrames com dados / NAs ausentes, módulos / namespaces, formulatipos e model.matrixinfra - estrutura, plotagem (sorta), suporte a banco de dados (mas ainda não aos DataFrames ainda) e passando argumentos por palavras-chave. Agora também há um IDE (Julia Studio), suporte do Windows, alguns testes estatísticos e algum suporte de data / hora.

Para mim, uma coisa muito importante para uma linguagem de análise de dados é ter uma funcionalidade de álgebra de consulta / relacional com padrões razoáveis ​​e design orientado à interatividade, e, idealmente, isso deve ser incorporado à linguagem. IMO, nenhuma linguagem FOSS que eu usei faz isso de forma eficaz, nem mesmo R.

O data.frame é muito desajeitado para trabalhar interativamente - por exemplo, imprime toda a estrutura de dados na chamada, é difícil trabalhar programaticamente com a sintaxe $ , a consulta requer uma auto-referência redundante (por exemplo, DF[DF$x < 10]), junções e agregação são estranhas. O Data.table resolve a maioria desses aborrecimentos, mas como não faz parte da implementação principal, a maioria dos códigos R não utiliza suas instalações.

Os pandas em python sofrem dos mesmos defeitos.

Essas queixas podem parecer exigentes, mas essas falhas se acumulam e, no final, são significativas em agregado, pois acabam custando muito tempo.

Acredito que, para que Julia seja bem-sucedida como um ambiente de análise de dados, é necessário dedicar esforços à implementação de operadores do tipo SQL (sem a bagagem da sintaxe SQL) em um tipo de dados de tabela amigável.

Eu posso assinar com o que Dirk e EpiGrad disseram; No entanto, há mais uma coisa que faz do R um idioma único em seu nicho - sistema de tipos orientados a dados.

Os R's foram projetados especialmente para manipular dados, é por isso que são centrados em vetores e possuem coisas como data.frames, fatores, NAs e atributos.
Os tipos de Julia são, por outro lado, orientados para o desempenho numérico, portanto, temos escalares, modos de armazenamento bem definidos, uniões e estruturas.

Isso pode parecer benigno, mas todo mundo que já tentou fazer estatísticas com o MATLAB sabe que realmente dói.

Então, pelo menos para mim, Julia não pode oferecer nada que eu não possa consertar com um pedaço C de poucas linhas e mata muita expressividade realmente útil.

Vejo Julia substituindo o Matlab, o que seria um grande serviço para a humanidade.

Para substituir o R, você precisa considerar todas as coisas que Neil G, Harlan e outros mencionaram, além de um grande fator que não acredito ter sido abordado: fácil instalação do aplicativo e de suas bibliotecas.

No momento, você pode baixar um binário do R para Mac, Windows ou Linux. Ele funciona imediatamente com uma grande variedade de métodos estatísticos. Se você deseja baixar um pacote, é um simples comando ou clique do mouse. Isso simplesmente funciona.

Fui baixar Julia e não é simples. Mesmo que você baixe o binário, é necessário ter o gfortran instalado para obter as bibliotecas apropriadas. Eu baixei a fonte e tentei makee falhou sem nenhuma mensagem realmente útil. Tenho graduação e pós-graduação em ciência da computação, para que eu pudesse bisbilhotar e fazê-lo funcionar se quisesse. (Não estou.) Joe Statistician fará isso?

O R não apenas possui uma grande variedade de pacotes, mas também um sistema bastante sofisticado que faz binários do aplicativo e quase todos os pacotes automaticamente. Se, por algum motivo, você precisar compilar um pacote da fonte, isso não será mais difícil (desde que você tenha um compilador apropriado, etc, instalado no seu sistema). Você não pode ignorar essa infraestrutura, fazer tudo via github e esperar ampla adoção.

Edição: Eu queria brincar com Julia - parece emocionante. Dois problemas:

1) Quando tentei instalar pacotes adicionais (esqueça o que eles chamam em Julia), ele falhou com erros obscuros. Evidentemente, meu Mac não tem uma ferramenta semelhante à que eles esperavam. Não apenas falha, mas deixa coisas por aí que eu tenho que excluir manualmente ou outras instalações falharão.

2) Eles forçam um certo espaçamento em uma linha de código. Não tenho os detalhes à minha frente, mas tem a ver com macros e não ter um espaço entre a macro e os parênteses abrindo seus argumentos. Esse tipo de restrição realmente me incomoda, já que desenvolvi minha formatação de código ao longo de muitos anos e linguagens e, na verdade, coloco um espaço entre um nome de função / macro e o parêntese de abertura. Algumas restrições de formatação de código eu entendo, mas espaço em branco dentro de uma linha?

A linguagem da Julia é bem nova; é hora do ponto em que a luz pode ser medida em semanas (mesmo que seu tempo de desenvolvimento possa ser medido em anos). Agora, aquelas semanas em destaque foram semanas muito emocionantes - veja, por exemplo, a recente conversa em Stanford, onde "havia acabado de começar" -, mas o que você pede em termos de infraestrutura mais ampla e suporte a pacotes levará muito mais tempo para materializar.

Então, eu continuaria usando R e ficaria atento às alternativas em desenvolvimento. No ano passado, muitas pessoas ficaram loucas por Clojure; este ano, Julia é o novo sabor reinante. Vamos ver se fica.

Bruce Tate aqui, autor de Sete Idiomas em Sete Semanas. Aqui estão alguns pensamentos. Estou trabalhando em Julia para o livro de acompanhamento. A seguir, é apenas a minha opinião após algumas semanas de jogo.

Existem duas forças fundamentais em jogo. Primeiro, todos os idiomas têm uma vida útil. R será substituído algum dia. Nós não sabemos quando. Novos idiomas têm um tempo extremamente difícil de evoluir. Quando um novo idioma evolui, geralmente resolve algum ponto de dor avassalador.

Essas duas coisas estão relacionadas. Para mim, estamos começando a ver um tema tomando forma em torno de idiomas como R. Não é rápido o suficiente e é mais difícil do que precisa ser. Aqueles que podem viver dentro de um determinado envelope de desempenho e permanecer nas bibliotecas estabelecidas estão bem. Aqueles que não podem precisar de mais e estão começando a procurar mais.

O problema é que as arquiteturas de computadores estão mudando e, para tirar proveito delas, a linguagem e suas construções precisam ser construídas de uma certa maneira. A opinião de Julia sobre a concorrência é interessante. Otimiza a coisa certa para essa linguagem: distribuição transparente e movimento eficiente de dados entre processos. Quando uso Julia para tarefas típicas, mapas e transformações, estou apenas chamando funções. Não preciso me preocupar com o encanamento.

Para mim, o fato de Julia ser mais rápida em um processador é interessante, mas não é demais para R. O que é interessante para mim é que, como os processadores dependem cada vez mais de multicore para desempenho, os problemas técnicos de computação estão praticamente na posição ideal aproveitar a melhor vantagem possível, dada a linguagem correta.

O outro recurso que ajudará a acontecer é de fato macros. O ritmo do idioma é intenso agora. As macros permitem que você construa com blocos de construção maiores e mais limpos. Olhar para bibliotecas é interessante, mas não conta a imagem toda. Você precisa observar o crescimento das bibliotecas. A trajetória de Julia está bem aqui.

O Clojure é interessante para alguns, porque não existe uma linguagem técnica que faça o que R pode, então alguns procuram uma linguagem de propósito geral para preencher esse vazio. Na verdade, sou uma grande fã. Mas Clojure é uma distorção cerebral bastante séria. O Clojure estará lá para programadores que precisam fazer computação técnica. Não será para engenheiros e cientistas. Há muito a aprender.

Então, para mim, Julia, ou algo assim, substituirá R algum dia. É uma questão de tempo.

Toda vez que vejo um novo idioma, pergunto-me por que um idioma existente não pode ser aprimorado.

As grandes vantagens do Python são

• um rico conjunto de módulos (não apenas estatísticas, mas plotagem de bibliotecas, saída para pdf etc.)
• construções de linguagem que você acaba necessitando a longo prazo (construções orientadas a objetos necessárias em um grande projeto; decoradores, fechamentos etc. que simplificam o desenvolvimento)
• muitos tutoriais e uma grande comunidade de suporte
• acesso ao mapreduce, se você tiver muitos dados para processar e não se importar em pagar alguns centavos para executá-los em um cluster.

Para ultrapassar R, Julia, etc., o Python poderia usar

• desenvolvimento de compilação just-in-time para Python restrito para fornecer mais velocidade em uma única máquina (mas mapreduce ainda é melhor se você aguentar a latência)
• uma biblioteca estatística mais rica

Julia não assumirá R muito em breve. Confira o Microsoft R aberto.

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

Esta é uma versão aprimorada do R que usa automaticamente todos os núcleos do seu computador. É o mesmo R, o mesmo idioma, os mesmos pacotes. Quando você o instala, o RStudio também o usa no console. A velocidade do MRO é ainda mais rápida que a Julia. Faço muita computação pesada e utilizo Julia há mais de um ano. Mudei para o R recentemente porque o R tem um suporte melhor e o RStudio é um editor incrível. Julia ainda está em estágio inicial e, possivelmente, não está alcançando Python ou R muito em breve.

Provavelmente o seguinte não merece ser uma resposta, mas é muito importante ser enterrado como um comentário à resposta de outra pessoa ...

Eu não ouvi muito falar sobre o consumo de memória, apenas velocidade. A semântica inteira de R ser passada por valor pode ser dolorosa, e essa foi uma crítica à linguagem (que é uma questão separada de quantos ótimos pacotes já existem). Um bom gerenciamento de memória é importante, assim como existem maneiras de lidar com o processamento fora do núcleo (por exemplo, matrizes ou tabelas de tabelas mapeadas pela memória do numpy ou o formato xdf da Revolution Analytics) Enquanto o compilador JIT do PyPy permite alguns benchmarks impressionantes do Python, o consumo de memória pode ser bastante alto. Então, alguém já tem experiência com Julia e uso de memória? Parece que há vazamentos de memória na versão "alpha" do Windows que, sem dúvida, serão abordadas, e ainda estou esperando o acesso a uma caixa do Linux para jogar com o idioma.

Eu acho improvável que Julia substitua R, por muitas das razões mencionadas anteriormente. Julia é uma substituição do Matlab, não uma substituição R; eles têm objetivos diferentes. Mesmo depois de Julia ter uma biblioteca de estatísticas completa, ninguém jamais ensinaria uma aula de Introdução à Estatística nela.

No entanto, uma área em que isso pode ser incrível é como uma linguagem de programação com velocidade otimizada que é menos dolorosa que o C / C ++. Se estivesse perfeitamente vinculado ao R (no estilo do Rcpp), seria bastante utilizado na escrita de segmentos críticos de velocidade. Infelizmente, esse link não existe atualmente:

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

Eu sou uma novata Julia e sou R competente. As razões pelas quais acho interessante Julia até agora são orientadas para desempenho e compatibilidade.

Ferramentas de GPU. Eu gostaria de usar o CUSPARSE para um aplicativo estatístico. Os resultados do CRAN indicam que não há muito por aí. Julia tem ligações disponíveis que parecem funcionar sem problemas até agora.

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)

Ferramentas HPC. Pode-se usar um cluster interativamente com vários nós de computação.

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

Compatibilidade com Python. Há acesso ao ecossistema python. Por exemplo, foi fácil descobrir como ler dados de imagens cerebrais:

import PyCall
@pyimport nibabel

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

Compatibilidade C. A seguir, gera um número inteiro aleatório usando a biblioteca padrão C.

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

Rapidez. Pensei em ver como o pacote Distributions.jl se comportava no rnorm de R - que, presumo, é otimizado.

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

julia> @elapsed rand(F, 1000000)
0.03422067

Em R:

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

O Julia 1.0 acabou de sair com um IDE muito útil (Juno). Chegou um pouco tarde para a festa, já que o Python já dominou o Machine Learning, enquanto o R continua dominando todos os outros tipos de análise estatística. Dito isto, Julia já está ganhando destaque na área de algoritmos de finanças e negociação, pois o rápido tempo de desenvolvimento e a execução são obrigatórios. Na minha opinião, a menos que outro idioma seja claramente melhor, a ascensão de Julia à proeminência provavelmente será algo como isto:

(1) Começa a comer o almoço do MATLAB. Os usuários do MATLAB gostam da sintaxe do MATLAB, mas odeiam praticamente todo o resto. A lentidão, as licenças caras, as maneiras muito limitadas de lidar com estruturas de dados complexas que não são matrizes. Lembro-me de uma citação em que se diz que "Se Julia substituir o MATLAB, será um grande serviço para a humanidade". Os usuários do MATLAB podem se tornar proficientes em Julia muito rapidamente e ficarão impressionados com a facilidade de escrever código de qualidade que faz muito mais do que o MATLAB pode fazer (estruturas rápidas que você pode colocar em matrizes e iterar rapidamente?). Além disso, os pesquisadores podem criar caixas de ferramentas sérias em Julia (uma pequena equipe de estudantes de doutorado escreveu um pacote de equações diferenciais de classe mundial) que seria impossível com o MATLAB.

(2) Começa a retomar a pesquisa em métodos numéricos e simulação. O MIT está jogando seu peso atrás de Julia, e a comunidade de pesquisa ouve o MIT. Simulações numéricas e novos métodos numéricos são problemas mal definidos que não possuem bibliotecas. É aqui que Julia como língua brilha; se não houver bibliotecas disponíveis, é muito mais fácil escrever código de qualidade rápida em Julia do que em qualquer outro idioma. Será uma linguagem numérica / de simulação escrita por matemáticos para matemáticos (som semelhante ao R ainda?)

(3) Outra inovação no Machine Learning acontece que dá a Julia a vantagem. Esse é um curinga que pode não acontecer. O TensorFlow é ótimo, mas é extremamente difícil de hackear. O Python já começou a mostrar rachaduras e o TensorFlow começou a adotar o Swift (com Julia recebendo uma menção honrosa). Se ocorrer outra inovação no aprendizado de máquina, será muito mais fácil implementar e invadir um pacote Julia como o Flux.jl.

(4) Julia começa a alcançar lentamente R, o que levará um tempo. Fazer estatísticas no MATLAB é doloroso, mas o Juila já está muito à frente do MATLAB com o Distributions.jl. O fato é que os fluxos de trabalho do R podem ser facilmente traduzidos para Julia. A única vantagem real que R tem é o fato de que existem tantos pacotes escritos por estatísticos para estatísticos. Esse processo, no entanto, também é fácil de ser feito em Julia. A diferença é que Julia é rápida e você não precisa usar outro idioma para obter desempenho (os pacotes R mais "sérios" são escritos em idiomas como C). O problema com o R é que os pacotes escritos em R são muito lentos para lidar com grandes conjuntos de dados. A única alternativa é traduzir os pacotes para outro idioma, tornando o desenvolvimento no R um processo mais lento que o Julia.

Estou interessado na promessa de melhor velocidade e fácil paralelização usando diferentes arquiteturas. Por esse motivo, certamente assistirei ao desenvolvimento de Julia, mas é improvável que o use até que ele possa lidar com modelos mistos lineares generalizados, que possua um bom pacote de bootstrap genérico, uma linguagem de modelo simples para criar matrizes de design com a capacidade equivalente a ggplot2 e uma ampla variedade dos algoritmos de aprendizado de máquina.

Nenhum estatístico pode se dar ao luxo de ter uma atitude fundamentalista em relação à escolha de ferramentas. Usaremos o que nos permite fazer o trabalho com mais eficiência. Meu palpite é que continuarei com o R por alguns anos ainda, mas seria bom ser agradavelmente surpreendido.

O luxo de NA em R não vem sem penalidades de desempenho. Se Julia suporta NAs com uma penalidade de desempenho menor, torna-se interessante para um segmento da comunidade de estatísticas, mas as NAs também impõem um trabalho extra considerável ao usar código compilado com R.

Muitos dos pacotes no R dependem de rotinas escritas em linguagens herdadas (C, Fortran ou C ++). Em alguns casos, as rotinas compiladas foram desenvolvidas fora do R e posteriormente usadas como base para os pacotes da biblioteca do R. Em outros, as rotinas foram implementadas primeiro no R e, em seguida, segmentos críticos foram traduzidos para um idioma compilado quando o desempenho foi encontrado. Julia será atraente se puder ser usada para implementar rotinas equivalentes. Há uma oportunidade de projetar suporte de baixo nível para NAs de uma maneira que simplifique o manuseio de NA sobre o que temos agora ao usar R com código compilado.

O grande número de bibliotecas R representa os esforços de muitos usuários. Isso foi possível porque o R forneceu recursos que não estavam disponíveis / acessíveis. Para que a Julia seja amplamente usada, ela precisa de um grupo de usuários que ache o que precisam muito melhor do que as alternativas que valem o esforço necessário para fornecer coisas muito básicas (por exemplo, gráficos, classes de datas, NA etc.) ) disponível em idiomas existentes.

Estarei na frente, não tenho experiência com R, mas trabalho com muitas pessoas que acham que é uma excelente ferramenta para análise estatística. Minha formação é em data warehousing e, devido ao modelo de programação facilmente distribuído, mas mais padrão, de Julia, acho que poderia ser um substituto muito interessante para a parte de transformação das ferramentas ETL tradicionais que geralmente fazem o trabalho muito mal, a maioria não tem como criando facilmente uma transformação padronizada ou reutilizando os resultados de uma transformação já executada em um conjunto de dados anterior. Destaca-se o suporte para tuplas rigidamente definidas e digitadas, se eu quiser criar um cubo OLAP que basicamente precise criar tuplas mais detalhadas (tabelas de fatos) com base nas tuplas já calculadas, as ferramentas ETL atuais não têm 'blocos de construção' para falar disso pode ajudar, essa indústria já trabalhou com esse problema por vários meios no passado, mas existem compensações. As linguagens de programação tradicionais podem ajudar fornecendo transformações definidas centralmente, e Julia pode potencialmente simplificar as agregações e distribuições não padrão comuns em sistemas de data warehouse mais complexos.

Você também pode usar Julia e R. juntos. Há interface de Julia-to-R . Com esses pacotes, você pode brincar com Julia enquanto chama o R sempre que houver uma biblioteca necessária.

Julia tem sem dúvida todas as chances de se tornar uma estatística que os usuários avançados sonham se tornar realidade, como o SAS, por exemplo, seu poder está nos inúmeros procs escritos em C - o que Julia pode fazer é fornecer os procs com o código-fonte, com matrizes como um tipo de dados incorporado que dispensa SAS / iml. Não tenho dúvidas de que os estatísticos vão se reunir com Julia quando souberem exatamente o que esse filhote pode fazer.

Ah, sim, Julia ultrapassará R rapidamente. E os principais motivos serão "macros", 95% da linguagem é implementada em Julia e sua sintaxe parcimoniosa e sem ruído. Se você não possui experiência com linguagens do tipo lisp, talvez ainda não a entenda, mas verá rapidamente como a interface da fórmula R se tornará um mecanismo obsoleto e feio, e será substituída por micro linguagens de modelagem especializadas semelhantes ao CL macro de loop. O acesso a referências de baixo nível de um objeto também é uma grande vantagem. Eu acho que R ainda não entendeu que esconder internos do usuário realmente complica do que simplifica as coisas.

Como eu vejo agora (tendo anos de uso pesado de R atrasados ​​e acabado de ler o manual de Julia), as principais desvantagens de Julia em relação a R não são suporte à herança estrutural (isso foi intencional). O sistema de tipos de Julia é menos ambicioso que o S4; Ele também suporta múltiplos despachos e múltiplas heranças, mas com uma pegada - há apenas um nível de classes concretas. Por outro lado, raramente vejo hierarquias de classe em R mais profundas que 3 níveis.

O tempo dirá, mas será mais cedo do que a maioria dos usuários de R pensa :)

Os primeiros casos de uso de destino de Julia são problemas numéricos. Basicamente, você pode dividir esses campos de análise e ciência da computação em ciência de dados (orientada a dados) e ciência de simulação (orientada a modelo). Julia lida primeiro com os casos de uso da ciência da simulação. Eles também estão lidando com os casos de ciência de dados, mas mais lentamente. R nunca será muito útil para a ciência da simulação, mas Julia será muito útil para ambos em alguns anos.

Ele precisa aplicar qualquer função a grandes conjuntos de dados que não cabem na memória de forma transparente para o usuário.
Isso inclui pelo menos a execução de modelos de efeitos mistos, modelos de sobrevivência ou MCMC em conjuntos de dados que cabem no disco, mas não na memória. E, se possível, em conjuntos de dados distribuídos em vários computadores.