Data.table: Vinhetas

fread é o mínimo que vale a pena mencionar.
Os pontos acima estão relacionados principalmente à transformação de dados, fread é mais uma extração de dados, então pode ser omitido em tal vinheta, mas IMO vale a pena mencionar tais data.table capacidades.

editar: qual você vai usar: Rnw ou Rmd?

Acordado e atualizado.

Estou curioso para saber o que torna um resfriado mais rápido do que, digamos, tapply . Uma parte da resposta é gforce, mas e as funções escritas pelo usuário? Não consegui encontrar nada sobre isso. Há uma boa postagem sobre o panda: http://wesmckinney.com/blog/?p=489
Pode-se até compará-lo com sapply . Por exemplo, suponha que eu comece com uma lista de vetores. Vale a pena acrescentar todos os vetores em uma coluna em um data.table e usar by vez de sapply ?

@matthieugomez pergunta interessante! Seria bom cobrir isso também. Continue vindo :-).

Eu estaria interessado em aprender sobre IDateTime e alguns dos casos de uso para ele.

@gsee atualizado.

Sendo novo em R e data.table (desde março), eu diria que deve haver uma introdução básica orientada para resultados, em oposição à atual orientada para funções. Em outras palavras, uma coisa é ler o que cada parâmetro em data.table faz, mas eles geralmente fazem pouco sentido sem ter um caso de uso em mente. Embora existam exemplos de resultados, muitas pessoas precisam ir na outra direção. Ou seja, eles sabem de qual saída precisam, mas não sabem qual função / parâmetro / configuração é mais apropriado para usar. Seria útil ter uma abordagem de receita simples para começar.

Como posso criar subconjuntos de meus dados?
Como faço uma operação em subconjuntos de meus dados para criar um conjunto de dados novo ou atualizado?
Como faço para adicionar uma nova coluna?
Como excluo uma coluna?
Como faço para criar uma única variável?
Como faço para criar várias variáveis?
Como faço diferentes operações em diferentes subconjuntos de meus dados? (.POR)
Como faço para usar data.table em uma função e passar nomes e colunas data.table nas quais operar?
Como faço várias operações sequenciais no mesmo data.table?
Posso selecionar um subconjunto de dados e fazer uma operação nele ao mesmo tempo?
Quando preciso ter cuidado ao criar / atualizar variáveis ​​por referência?
Como seleciono uma observação por grupo (primeiro, último)?
Como faço para definir uma chave e como ela é diferente de definir um índice?
Sob quais condições minha chave é excluída quando eu faço uma operação em meu data.table?
Posso usar a sintaxe regular de "mesclagem" ou preciso usar a sintaxe data.table (Y [X])?
Como faço para recolher uma lista de listas em um big data.table? E se as colunas estiverem em ordem diferente?

Provavelmente, há uma tonelada de outros itens no SO que podem ser editados em uma simples compilação de perguntas e respostas.

@markdanese Obrigado por suas sugestões. Todos são ótimos, mas provavelmente como um wiki separado, já que são muito específicos sobre certas tarefas. O objetivo da vinheta é apresentar a sintaxe data.table, ilustrando o quão flexível e poderosa ela pode ser, para que você seja capaz de fazer essas tarefas sozinho.

Estou escrevendo as vinhetas agora (o mais rápido que posso), e o formato é mais ou menos assim (Q&A) e explicando a resposta com um exemplo. Depois de polir a primeira vinheta, pretendo postá-la aqui para obter algum feedback. Seria ótimo saber o que você pensa também.

Obrigado novamente.

Uma extensão adicional da ideia da página wiki: Os links FAQ e Fragmentos de Código (Avançado) listados em http://www.ats.ucla.edu/stat/r/ podem ser um recurso útil para comparar tarefas tradicionais em R com dados .forma mesa. Eu fiz algo assim em uma postagem do blog (http://vijaylulla.com/wp/2014/11/12/grouping-in-r-using-data-table/) para mostrar ao meu colega. Desculpe pela autopromoção sem vergonha.

Terminei a vinheta _Introdução aos dados.table_ (veja o link no topo). Seria ótimo saber o que você pensa.

Obrigado a @jangorecki e @brodieG pelos ótimos feedbacks e, claro, a @mattdowle :-).

Isso é realmente ótimo. Queria que existisse há um ano quando comecei a usar data.table. Algumas pequenas coisas abaixo para sua consideração:
Você pode querer mencionar que você pode classificar (via order ) em i em seu resumo no final. Você também pode querer mencionar isso no início. Você também pode mencionar que existem junções mais sofisticadas que podem ser feitas em i envolvendo chaves que não são cobertas. Isso permite que você mencione as funções principais de i para que o leitor possa procurar funções mais avançadas se precisar delas. E você pode criar um hiperlink para eles mais tarde.

Na seção .SD você escreve "aquele grupo", mas pode ser mais claro dizer "aquele grupo definido usando by ". Isso também é feito um pouco mais tarde.

Posso ter perdido, mas seria bom deixar um pouco mais claro que .SD com by essencialmente limita os dados às colunas .SD e, em seguida, cria um conjunto de data.tables para cada combinação única das variáveis ​​em by . Em seguida, ele processa essas tabelas de dados na ordem das variáveis by usando a (s) função (ões) de j . Você poderia até mencionar que existem símbolos especiais que permitem aos usuários acessar alguns dos índices gerados como parte desse processamento, mas que estão além do escopo da vinheta de introdução.

Novamente, essas são apenas sugestões. Seu trabalho árduo (e de Matt) é muito apreciado.

No sábado, 17 de janeiro de 2015 às 18:22, Mark Danese [email protected]
escreveu:

Isso é realmente ótimo. Gostaria que existisse há um ano, quando comecei a usar
Tabela de dados. Algumas pequenas coisas abaixo para sua consideração:

Obrigada.

Você pode querer mencionar que você pode classificar (via pedido) em i em seu
resumo no final. Você também pode querer mencionar isso no início.

Oh, não! Ótimo ponto. Devo adicionar "pedido (..)" no início, e
será adicionado ao resumo também.

Você também pode mencionar que existem junções mais sofisticadas que podem ser
feito em i envolvendo chaves que não são cobertas. Isso permite que você mencione
as principais funções de i para que o leitor possa procurar por mais
funções, se necessário.

Certo, vou fazer.

E você pode criar um hiperlink para eles mais tarde.

Isso, eu não tenho certeza .. já que eles devem ser enviados para CRAN, e também
no WIKI ..

Na seção .SD, você escreve "aquele grupo", mas pode ser mais claro para
diga "aquele grupo definido por". Isso também é feito um pouco mais tarde, como
Nós vamos.

Achei que tinha editado para "o grupo atual", mas aparentemente não .. "por
o grupo atual, definido usando em by "- o que você acha?

Posso ter perdido, mas seria bom ser um pouco mais claro
que .SD limita essencialmente os dados às colunas .SD e, em seguida,
cria um conjunto de data.tables para cada combinação única das variáveis
no por. Em seguida, ele processa essas tabelas de dados na ordem de
variáveis ​​usando a (s) função (ões) de j.

Eu acho que você perdeu. Está logo abaixo da citação em bloco, onde .SD é
explicado (na seção 2e). E isso explica exatamente o que você mencionou aqui ...

Você pode até mencionar que existem símbolos especiais que permitem aos usuários
acessar alguns dos índices gerados como parte desse processamento, mas que
estes estão além do escopo da vinheta de introdução.

Certo .. essa é a razão para não introduzir outros símbolos especiais.

Novamente, essas são apenas sugestões. Seu trabalho árduo (e de Matt) é muito
estimado.

Ótimas sugestões. Escreverei de volta assim que carregar as outras vinhetas.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment -70375167
.

Isso, eu não tenho certeza .. já que eles devem ser enviados para CRAN, e também
no WIKI ..

AFAIK quando você enviar o pacote para CRAN que inclui Rmd no diretório vignettes , eles serão construídos automaticamente para verificar se a vinheta de construção foi bem-sucedida, mas o código-fonte no CRAN conterá vinhetas (html) já criadas por você, não aquele do CRAN construir / verificar.
O CRAN é um bom lugar para vinhetas, pois para muitos usuários é o primeiro lugar para procurar documentos / tutoriais, então acho que vale a pena tê-los no CRAN.

E você pode criar um hiperlink para eles mais tarde.

Isso, não tenho certeza .. já que eles devem ser enviados para o CRAN e também para o WIKI ..

Os links de pastas individuais não funcionam no CRAN? Na verdade, não coloquei nada lá, mas esta vinheta vincula vários outros na mesma pasta usando links relativos e funciona bem a partir de R (obviamente o link não é de R, mas se você instalar o pacote e executar as vinhetas, os links trabalhar.

Atualizado com a vinheta _Reference Semantics_.

obrigado novamente por fazer tudo isso.

apenas mais uma sugestão sobre algo para cobrir em uma vinheta - usando data.table dentro de sua própria função. não escrevendo um pacote, mas apenas tentando automatizar algumas tarefas comuns. existem alguns truques que ainda não descobri. também se houver uma postagem em algum lugar sobre este tópico, um link seria apreciado.

finalmente, uma vinheta listando postagens "úteis" de estouro de pilha pode ser útil para tópicos que você não deseja incluir em uma vinheta.

apenas alguns pensamentos aleatórios.

Dois pensamentos:

• Link para as vinhetas no wiki
• Na vinheta semântica de referência, adicione como usar: = com uma expressão de lista entre aspas (ou apenas uma atribuição entre aspas). Talvez isso mereça sua própria vinheta, já que o NSE (avaliação não padrão) em data.table facilita o uso interativo, mas requer que, para usar data.table em sua própria função ou pacote, você agora tenha algo sobre quote, eval, substitute e friends. Talvez apenas adicione algo como dt [, do.call (": =", eval (my_quoted_list)] à vinheta e, em seguida, crie uma vinheta sobre NSE e suas implicações?

Obrigado.

1. Você já viu isso ?
2. Isso provavelmente será abordado em uma vinheta separada. Mas ainda não há planos.

@arunsrinivasan Não, eu não tinha visto isso, ótimo! Outro marcador

Atualizado com _Keys e vinheta baseada em pesquisa binária rápida.

Muito agradável. Eu amo essas vinhetas. Apenas alguns comentários rápidos para consideração.

Qual é a finalidade de assumir o controle dos nomes de linha se eles não forem usados? Ou eles são usados ​​pelos operadores especiais em j (como .N, .I, etc.)? Eu acho que eles são usados ​​por data.table, mas não apenas como índices. Sempre me confundi com o propósito de forçar os nomes das linhas numeradas.

Por que usar unique na primeira chave ao acessar apenas a segunda? Do contrário, você obterá muitas linhas repetidas na saída, certo? Talvez seja óbvio, mas pode ser útil dizer / mostrar o que acontece se você não o fizer.

Todas as chaves precisam ser cotadas? Mesmo os numéricos (inteiros)? Você pode usar um numérico como chave? Alguma coisa a ter em atenção?

E se a sua coluna principal contiver NA? Você pode procurar por aqueles e substituí-los (como fez em seu exemplo, em que substituiu 24 por 0?

Pode ajudar a explicar que keyby se aplica a _output_ data.table ( ans em seu exemplo) e não a data.table de entrada ( flights em seu exemplo).

Você pode passar um vetor para a chave? Em outras palavras, você pode criar airport <- c("LGA", "JFK", "EWR") e usar airport diretamente em i em seu exemplo próximo ao final? Isso pode ajudar a configurar a ideia de passar um data.table diferente para uma mesclagem.

Erro de digitação em "correspondente" ("correspondong"). Uma das marcas de volta está faltando na seção de varredura de vetor onde você escreve "Os índices de linha correspondentes a origem ==" LGA "e teste ==“ TPA ”` são obtidos usando um subconjunto baseado em chave. "

@markdanese sobre o

Por que usar único na primeira chave ao acessar apenas a segunda?

flights[.(unique(origin), "MIA")]

Não tenho certeza se você está pedindo uma explicação melhor ou não está ciente do uso mais complexo da chave de várias colunas.
Você não pode simplesmente usar a pesquisa binária em dest quando sua chave é c(origin, dest) , você deve ter c(dest, origin) para usar a pesquisa binária em dest . Usando .(unique(origin), "MIA") usa pesquisa binária, fornecendo todos os valores disponíveis para a primeira coluna na chave e, em seguida, valores seletivos para a segunda coluna.
Fiz uma extensão para usar apenas colunas seletivas da chave. olhar para o exemplo simples também pode ajudá-lo a entender. Minha extensão não está pronta para ser PR para data.table master, pois o uso de memória não é tão bom quanto poderia se desenvolvido usando funções internas data.table / combinadas com a chave secundária data.table.

Você pode usar um numérico como chave?

Você pode usar um número como chave, ele é mencionado na seção Keys and their properties .

Alguma coisa a ter em atenção?

Não tenho certeza, mas setNumericRounding afeta a tecla numérica, pode valer a pena mencionar na vinheta.

E se a sua coluna principal contiver NA? Você pode procurar por eles e substituir

Sim, o is.na() é otimizado para usar a pesquisa binária. Experimente data.table(a=c(1,NA_real_),b=c("a","b"),key="a")[.(NA_real_), .SD ,verbose=TRUE]

Também para @arunsrinivasan , o erro de digitação em:

encontre os valores correspondentes em

Obrigado Jan - isso é realmente útil. Apresentei essas perguntas como coisas que poderiam ser brevemente mencionadas na vinheta para ajudar os novos usuários a entender o que está acontecendo. Foram coisas que vieram à mente (como um usuário relativamente novo) enquanto lia a documentação. Eu realmente não posso contribuir com o código, então espero contribuir ajudando com a documentação.

Na sexta-feira, 23 de janeiro de 2015 às 20:48, Mark Danese [email protected]
escreveu:

Muito agradável. Eu amo essas vinhetas. Apenas alguns comentários rápidos para
consideração.

Qual é a finalidade de assumir o controle dos nomes de linha se eles não forem usados? Ou são
eles são usados ​​pelos operadores especiais em j (como .N, .I, etc.)? Eu acho que eles
são usados ​​por data.table, mas não apenas como índices. Eu sempre fui
confuso com o propósito de forçar os nomes das linhas numeradas.

A seção 1a, logo acima de Chaves e suas propriedades, tem a resposta para isso.
Data.tables _inherit_ from data.frames.

Por que usar único na primeira chave ao acessar apenas a segunda? Se você
não, você obtém muitas linhas repetidas na saída, certo? Talvez óbvio,
mas pode ser útil dizer / mostrar o que acontece se você não o fizer.

Novamente, isso é explicado exatamente em "o que está acontecendo aqui?". eu
até mesmo referir-se à seção anterior, onde estabeleço as bases para
explicando este.

Todas as chaves precisam ser cotadas? Mesmo os numéricos (inteiros)? Você pode usar um
numérico como uma chave? Alguma coisa a ter em atenção?

Há um exemplo com colunas inteiras em 2d. Eu pensei que era
suficiente?

E se a sua coluna principal contiver NA? Você pode procurar por eles e substituir
eles (como você fez em seu exemplo, em que substituiu 24 por 0?

Bom ponto. Essa é uma diferença com a varredura vetorial. Vou tentar adicionar isso.

Pode ajudar a explicar que keyby se aplica a _output_ data.table (
ans em seu exemplo) e não o data.table de entrada (voos em seu
exemplo).

'keyby' já foi discutido na primeira vinheta. Mas vou ver se isso
pode ser adicionado.

Você pode passar um vetor para a chave? Em outras palavras, você pode criar um aeroporto
<- c ("LGA", "JFK", "EWR") e use um portal direto diretamente em seu exemplo próximo
o fundo? Isso pode ajudar a criar a ideia de passar por um diferente
data.table para uma fusão.

Conteúdo para a próxima seção. É assim que fazemos a transição para junções.

Erro de digitação em "correspondente" ("correspondong"). Um dos retrocessos é
faltando na seção de varredura vetorial, onde você escreve "Os índices de linha
correspondente à origem == "LGA" e teste == “TPA” `são obtidos usando a chave
subconjunto baseado. "

Obrigado.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment -71253738
.

Ótimo trabalho nessas vinhetas!
Meus comentários podem estar atrasados ​​ou já foram cobertos:

• Eu gostaria de ver uma variedade de maneiras / exemplos de uso de linhas e colunas dinâmicas.
• Comparação mais extensa sobre mesclagem e junções.
• Maneiras diferentes / mais ricas de usar set . Além disso, seria bom ver uma explicação de por que o seguinte dá um erro (veja aqui ):

for (j in  valCols)
   set(dt_,  
    i = which(is.na(dt_[[j]])),
    j = j, 
    value= as.numeric(originTable[[j]]))

Adicionada vinheta Reshape ao Wiki .

Excelente funcionalidade e vinheta! Obrigado Arun

Na terça-feira, 23 de junho de 2015, 21:02, Arun [email protected] escreveu:

Adicionada vinheta Reshape
https://rawgit.com/wiki/Rdatatable/data.table/vignettes/datatable-reshape.html
para o Wiki https://github.com/Rdatatable/data.table/wiki/Getting-started.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment -114678716
.

homem por patterns seria bom. Ótima vinheta

O reshape2 não precisa ser carregado para usar esses comandos? Nesse caso, isso deve ser mencionado. Eu realmente gosto do foco em "largo para longo" e "longo para largo". Eu absolutamente odeio a sintaxe de reshape2 (por exemplo, acho que "make_wide" é muito mais claro do que "dcast"). Por esse motivo, eu não escreveria os cabeçalhos de seção como "derretendo data.tables" e "casting data.tables". Isso só faz sentido para pessoas que estão familiarizadas com o pacote reshape2. Posso começar com cabeçalhos que são mais universais como acima ("longo para largo").

Pelo que vale a pena, não consigo fazer com que a primeira linha da vinheta seja executada usando uma nova sessão R com apenas data.table carregada. Não tenho ideia do porquê (talvez o modo deva ser "w" e não "wb"), mas
DT = fread("https://raw.githubusercontent.com/wiki/Rdatatable/data.table/data/melt_default.csv")
retorna
Error in download.file(input, tt, mode = "wb") : unsupported URL scheme

Como sempre, obrigado por fazer isso. É muito útil.

@markdanese, obrigado pelo excelente feedback.

1. reshape2 não será exigido de data.table v1.9.6 . Isso também foi atualizado na vinheta.
2. Adicionados 'de longo para longo' e 'de longo para amplo' aos títulos e outros lugares para evitar confusão para as pessoas que são novas neste tópico.
3. https em fread é implementada na versão devel. Portanto, você ainda não poderá executar esse código com v1.9.4 . Atualize ou espere um pouco :-).

Obrigado pelo seu incentivo.

@jangorecki patterns() não será exportado. O uso será expandido para [.data.table para ser usado para selecionar colunas, := , .SDcols etc.

@arunsrinivasan ainda o manual para patterns pode ajudar, da mesma forma que existe um para := . Só porque muitas pessoas (eu acho) usam ?fun para entender o código que lêem.

Na vinheta _join_ pode valer a pena adicionar exemplos de SQL correspondentes de junções data.table para que seja mais fácil de pegar para os caras do banco de dados.
Exemplos de instruções SQL correspondentes podem ser encontrados, por exemplo, em SO Como juntar (mesclar) quadros de dados (interno, externo, esquerdo, direito)? .

Também seria legal ter algumas vinhetas de "Refugiados" -

• data.table para Stata usuários
• data.table para SQL usuários
• data.table para Matlab usuários
• data.table para Python / pandas usuários
• mesmo data.table para dplyr usuários

etc. Como um guia de início rápido, mas orientado para emigrados.

Adicionada vinheta Secondary indices and auto indexing . Isso deve permitir uma transição suave de subconjuntos para junções para a próxima vinheta que irei trabalhar.

@arunsrinivasan não é mais apropriado não usar _secondary_ em relação a _indices_? foi usado para _keys_ onde era importante. Agora parece redundante, uma vez que mudamos para nomenclatura _index_.

@jangorecki Acho que "secundário" é útil por sua relação com as chaves (primárias), talvez:

Classificação secundária

É uma descrição melhor?

mas a palavra _index_ já foi usada, parece melhor do que _segmentação secundária_ :)

Então, você simplesmente o chamaria de "indexação automática"? IMO "classificação secundária e indexação automática" parece mais informativo

_auto_ pode ser de alguma forma enganoso, pois os índices devem funcionar para a criação _auto_ de índices e também para o uso de índices criados manualmente - # 1422 aborda a limitação atual nesse assunto.

Entendo. Ainda estou perdendo sua alternativa preferida - apenas "Índices"?

não é perfeito, mas é preferível a _índices secundários_

Eu gosto muito dessa última vinheta. Meu único pensamento foi que talvez seja útil mencionar quais tipos de operações fazem com que o índice seja eliminado. Pelo meu teste, parece quase tudo que altera o número de linhas ou qualquer operação envolvendo a coluna indexada.

Achei que os exemplos de "ligado" foram realmente úteis.

@markdanese é um bom ponto, acrescentarei.

Obrigado pelas vinhetas atualizadas com o lançamento da v1.9.8.
A "Semântica de referência" refere-se à função copy() e seus novos recursos para fazer cópias superficiais (especialmente dentro de funções, algo em que estou realmente interessado):

"No entanto, poderíamos melhorar essa funcionalidade ainda mais com a cópia superficial em vez da cópia profunda. Na verdade, gostaríamos muito de fornecer essa funcionalidade para a v1.9.8 .

Mas a vinheta do design está faltando e o link aponta para um problema antigo. O manual de referência não fornece mais informações sobre copy() que a fornecida na vinheta. O resto das vinhetas não fornecem nenhuma informação sobre copy .

Esta vinheta estará disponível em breve?

+1 para vinheta interna. Eu (e acho que alguns outros) estou bastante interessado em contribuir um pouco no lado C das coisas, mas estou um pouco intimidado pelas (no estado em que se encontram) 35k linhas de código C ... é uma curva de aprendizado para 'ir it alone '- uma introdução aos internos poderia fazer maravilhas!

Para a vinheta Joins:

https://github.com/Rdatatable/data.table/issues/2396

Desejo entrar na conversa e perguntar se as contribuições para a vinheta são aceitas de contribuidores sem código (como eu). Estou particularmente interessado em contribuir para a vinheta joins, pois tive alguns problemas com ela inicialmente e fui orientado para soluções a partir das respostas de Arun no Stackoverflow, e gostaria de alguma orientação sobre como fazer isso, se permitido.

@arunsrinivasan Vejo que você tem IDateTime vignette . Talvez pudesse ser incluído na vinheta mais geral sugerida por @jangorecki : vinhetas: séries do tempo - observações ordenadas ?

Além disso, estou preparando um primeiro esboço sobre alguns dos tópicos sugeridos por jan . Talvez partes dela também sejam relevantes para uma vinheta de junção? Fico feliz em compartilhar se alguém achar útil.

@zeomal, tal contribuição seria altamente valiosa e muito apreciada!

@MichaelChirico , obrigado. @ Henrik-P, seu briefing sobre junções normais será abrangente - ou seja, seu foco será mais nas séries temporais? Se não, posso começar a trabalhar nisso - ainda não usei junções rotativas, portanto, não tenho conhecimento disso. :)

@zeomal Espero poder carregar o primeiro rascunho em breve, para que você possa dar uma olhada nele. Em meu rascunho, forneço um exemplo simples de uma junção "normal" em uma única variável, tempo, onde existem linhas não correspondentes. Eu uso nomatch = NA . (talvez também seja um exemplo rápido com nomatch = NULL )

Minha ideia era que essa junção simples poderia fornecer um contexto e um sentimento para o problema, que tratarei mais detalhadamente nas seções seguintes sobre junções rotativas e não-equi et al.

Muito obrigado pela sua disponibilidade em contribuir! .

Tenho uma pergunta sobre a adesão por referência, enquanto preparo as vinhetas. O X[Y, new_col := old_col] executa algo semelhante a uma junção à esquerda tradicional em X . No entanto, se houver várias correspondências para as chaves de Y em X , apenas o último (ou primeiro?) Valor correspondente da chave é retido. Isso está explicitamente documentado em algum lugar? Eu havia tentado pesquisar isso quando o encontrei, mas tive que recorrer ao meu entendimento de atualização por referência para o motivo. Para um exemplo reproduzível,

> X = data.table(a = c(1, 2, 3), m = c("a", "b", "c"))
> Y = data.table(b = c(1, 1, 4), n = c("x", "y", "z"))
> X[Y, new_col := i.n, on = "a == b"]
   a m new_col
1: 1 a       y
2: 2 b    <NA>
3: 3 c    <NA>

# an ideal left join - expected behaviour per a new user, given below
# not possible because updating row by reference isn't implemented
   a m new_col
1: 1 a       x
1: 1 a       y
2: 2 b    <NA>
3: 3 c    <NA>

Este é o comportamento esperado, mas não é exatamente simples para um novo usuário. mult também não afeta o resultado. Alguma sugestão sobre como documentar isso? Adicionar merge como uma solução alternativa para uma junção à esquerda adequada?

@zeomal , poste sua futura pergunta sobre a vinheta de adesão na edição # 2181. Parece um lugar melhor. Está documentado em set .

@zeomal Se você deseja verificar o quão breve é ​​meu tratamento em junções normais (equi), eu só quero que você saiba que postei um PR em uma vinheta da série temporal .