Data.table: Vignettes

fread vaut le moins la peine d'être mentionné.
Les points ci-dessus sont principalement liés à la transformation des données, fread est plus une extraction de données, il peut donc être ignoré dans une telle vignette, mais IMO, il vaut la peine de mentionner ces capacités data.table .

edit : lequel allez-vous utiliser : Rnw ou Rmd ?

D'accord et mis à jour.

Je suis curieux de savoir ce qui rend un rhume plus rapide que disons tapply . Une partie de la réponse est gforce, mais qu'en est-il des fonctions écrites par l'utilisateur ? Je n'ai rien trouvé à ce sujet. Il y a un article sympa sur le panda : http://wesmckinney.com/blog/?p=489
On pourrait même le comparer avec sapply . Par exemple, supposons que je pars d'une liste de vecteurs. Cela vaut-il jamais la peine d'ajouter tous les vecteurs dans une colonne dans un data.table et d'utiliser by au lieu de sapply ?

@matthieugomez question intéressante ! Ce serait bien de couvrir ça aussi. Laissez-les venir :-).

Je serais intéressé d'en savoir plus sur IDateTime et certains de ses cas d'utilisation.

@gsee mis à jour.

Étant nouveau sur R et data.table (depuis mars), je dirais qu'il doit y avoir une introduction de base axée sur les résultats par opposition à l'actuelle axée sur les fonctions. En d'autres termes, c'est une chose de lire ce que fait chaque paramètre dans data.table, mais ils ont souvent peu de sens sans avoir un cas d'utilisation en tête. Bien qu'il existe des exemples de sortie, de nombreuses personnes doivent aller dans l'autre sens. C'est-à-dire qu'ils savent de quelle sortie ils ont besoin, mais ils ne savent pas quelle fonction/paramètre/réglage est le plus approprié à utiliser. Il serait utile d'avoir une approche de recette simple pour les démarrer.

Comment créer des sous-ensembles de mes données ?
Comment effectuer une opération sur des sous-ensembles de mes données pour créer un ensemble de données nouveau ou mis à jour ?
Comment ajouter une nouvelle colonne ?
Comment supprimer une colonne ?
Comment créer une seule variable ?
Comment créer plusieurs variables ?
Comment effectuer différentes opérations sur différents sous-ensembles de mes données ? (.PAR)
Comment utiliser data.table dans une fonction et transmettre les noms et colonnes data.table sur lesquels opérer ?
Comment faire plusieurs opérations séquentielles sur la même data.table ?
Puis-je sélectionner un sous-ensemble de données et effectuer une opération dessus en même temps ?
Quand dois-je faire attention à la création/mise à jour de variables par référence ?
Comment sélectionner une observation par groupe (première, dernière) ?
Comment définir une clé et en quoi est-ce différent de la définition d'un index ?
Dans quelles conditions ma clé est-elle supprimée lorsque je fais une opération sur ma data.table ?
Puis-je simplement utiliser la syntaxe "fusion" habituelle ou dois-je utiliser la syntaxe data.table (Y[X]) ?
Comment réduire une liste de listes en un seul big data.table ? Et si les colonnes sont dans un ordre différent ?

Il y a probablement une tonne d'autres éléments sur SO qui pourraient être modifiés en une simple compilation de questions et réponses.

@markdanese Merci pour vos suggestions. C'est super d'avoir, mais probablement comme un wiki séparé, car ils sont très particuliers sur certaines tâches. L'objectif de la vignette est de présenter la syntaxe data.table illustrant à quel point elle peut être flexible et puissante, afin que vous puissiez effectuer ces tâches vous-même.

J'écris les vignettes maintenant (aussi vite que je peux), et le format est plus ou moins de cette façon (Q&A) et j'explique la réponse avec un exemple. Une fois que j'aurai peaufiné la première vignette, j'ai l'intention de la poster ici pour avoir des retours.. Ce serait bien de savoir ce que vous en pensez aussi.

Merci encore.

Extension supplémentaire de l'idée de la page wiki : les liens FAQ et Fragments de code (avancés) répertoriés sur http://www.ats.ucla.edu/stat/r/ pourraient être une ressource utile pour comparer les tâches traditionnelles dans R avec les données .table façon. J'ai fait quelque chose comme ça dans un article de blog (http://vijaylulla.com/wp/2014/11/12/grouping-in-r-using-data-table/) pour le montrer à mon collègue. Désolé pour l'auto-promotion éhontée.

J'ai terminé la vignette _Introduction to data.table_ (voir lien en haut). Ce serait super de savoir ce que vous en pensez.

Merci à @jangorecki et @brodieG pour leurs excellents retours, et bien sûr @mattdowle :-).

C'est vraiment super. J'aurais aimé qu'il existe il y a un an lorsque j'ai commencé à utiliser data.table. Quelques petites choses ci-dessous pour votre considération:
Vous voudrez peut-être mentionner que vous pouvez trier (via order ) dans i dans votre résumé à la fin. Vous pouvez également vouloir le mentionner au début. Vous pouvez également mentionner qu'il existe des jointures plus sophistiquées qui peuvent être effectuées dans i impliquant des clés qui ne sont pas couvertes. Cela vous permet de mentionner les fonctions principales de i afin que le lecteur puisse rechercher des fonctions plus avancées s'il en a besoin. Et vous pouvez créer un lien hypertexte vers eux plus tard.

Dans la section .SD, vous écrivez "ce groupe", mais il serait peut-être plus clair de dire "ce groupe défini à l'aide de by ". Cela se fait aussi un peu plus tard.

Je l'ai peut-être manqué, mais il serait bon d'être un peu plus clair sur le fait que .SD avec by limite essentiellement les données aux colonnes .SD, puis crée un ensemble de data.tables pour chaque combinaison unique des variables dans le by . Il traite ensuite ces data.tables dans l'ordre des variables by utilisant la ou les fonctions de j . Vous pourriez même mentionner qu'il existe des symboles spéciaux qui permettent aux utilisateurs d'accéder à certains des index générés dans le cadre de ce traitement, mais que ceux-ci dépassent le cadre de la vignette d'introduction.

Encore une fois, ce ne sont que des suggestions. Votre travail acharné (et celui de Matt) est grandement apprécié.

Le samedi 17 janvier 2015 à 18h22, Mark Danese [email protected]
a écrit:

C'est vraiment super. J'aurais aimé qu'il existe il y a un an quand j'ai commencé à l'utiliser
table.de.données. Quelques petites choses ci-dessous pour votre considération:

Merci.

Vous voudrez peut-être mentionner que vous pouvez trier (par ordre) dans i dans votre
résumé à la fin. Vous pouvez également vouloir le mentionner au début.

Oh claquement ! Grand point. Je devrais ajouter "commande(..)" au tout début, et
ajoutera également au résumé.

Vous pouvez également mentionner qu'il existe des jointures plus sophistiquées qui peuvent être
fait en i impliquant des clés qui ne sont pas couvertes. Cela vous permet de mentionner
les principales fonctions de i afin que le lecteur puisse rechercher des
fonctions s'ils en ont besoin.

D'accord, fera l'affaire.

Et vous pouvez créer un lien hypertexte vers eux plus tard.

Cela, je ne suis pas sûr.. car ceux-ci sont destinés à être poussés vers le CRAN, et ainsi
sur le WIKI..

Dans la section .SD, vous écrivez "ce groupe", mais il est peut-être plus clair de
dites "ce groupe défini à l'aide de par". Cela se fait aussi un peu plus tard car
bien.

Je pensais l'avoir édité dans "le groupe actuel", mais apparemment pas .. "par
le groupe actuel, défini en utilisant dans by " - comment ça sonne ?

Je l'ai peut-être manqué, mais ce serait bien d'être un peu plus clair
que .SD avec par limite essentiellement les données aux colonnes .SD, puis
crée un ensemble de data.tables pour chaque combinaison unique des variables
dans le par. Il traite ensuite ces data.tables dans l'ordre du by
variables utilisant la ou les fonctions de j.

Je pense que vous l'avez manqué. C'est juste en dessous de la citation de bloc où .SD est
expliqué (dans la section 2e). Et cela explique exactement ce que vous mentionnez ici...

Vous pourriez même mentionner qu'il existe des symboles spéciaux qui permettent aux utilisateurs de
accéder à certains des index générés dans le cadre de ce traitement, mais que
ceux-ci dépassent le cadre de la vignette d'introduction.

C'est la raison de ne pas introduire d'autres symboles spéciaux.

Encore une fois, ce ne sont que des suggestions. Votre travail acharné (et celui de Matt) est grandement
apprécié.

Excellentes suggestions. Je vous répondrai une fois que j'aurai téléchargé les autres vignettes.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment -70375167
.

Cela, je ne suis pas sûr.. car ceux-ci sont destinés à être poussés vers le CRAN, et ainsi
sur le WIKI..

AFAIK lorsque vous envoyez un package à CRAN qui inclut Rmd dans le répertoire vignettes , ils seront automatiquement construits pour vérifier si la vignette de construction réussit, mais le code source dans CRAN contiendra des vignettes (html) déjà construites par vous, pas celui de CRAN build/check.
CRAN est un bon endroit pour les vignettes car pour de nombreux utilisateurs, c'est le premier endroit pour rechercher des documents/tutoriels, donc je pense que cela vaut la peine de les avoir dans CRAN.

Et vous pouvez créer un lien hypertexte vers eux plus tard.

Cela, je ne suis pas sûr.. car ils sont destinés à être poussés vers le CRAN, ainsi que sur le WIKI..

Les liens de dossiers uniques ne fonctionnent-ils pas sur CRAN ? Je n'ai rien mis là-haut, mais cette vignette en lie plusieurs autres dans le même dossier en utilisant des liens relatifs et fonctionne bien à partir de R (évidemment, le lien ne vient pas de R, mais si vous installez le package et exécutez les vignettes, les liens travail.

Mis à jour avec la vignette _Reference Semantics_.

merci encore d'avoir fait tout ça.

juste une autre suggestion sur quelque chose à couvrir sur une vignette - en utilisant data.table dans votre propre fonction. ne pas écrire un package, mais juste essayer d'automatiser certaines tâches courantes. il y a des trucs que je n'ai pas tout à fait compris. aussi s'il y a un post quelque part sur ce sujet, un lien serait apprécié.

Enfin, une vignette répertoriant les messages de débordement de pile « utiles » peut être utile pour les sujets que vous ne souhaitez pas inclure dans une vignette.

juste quelques pensées aléatoires.

Deux réflexions :

• Lien vers les vignettes dans le wiki
• Dans la vignette sémantique de référence, ajoutez comment utiliser := avec une expression de liste entre guillemets (ou simplement une affectation entre guillemets). Peut-être que cela mérite sa propre vignette, car le NSE (évaluation non standard) dans data.table facilite l'utilisation interactive mais nécessite que pour utiliser data.table dans votre propre fonction ou package, vous devriez maintenant quelque chose à propos de quote, eval, substitut et friends. Peut-être simplement ajouter quelque chose comme dt[, do.call(":=", eval(my_quoted_list)] à la vignette, puis créer une vignette sur NSE et ses implications ?

Merci.

1. Avez-vous vu cela ?
2. Cela sera probablement couvert dans une vignette séparée. Mais pas encore de plans.

@arunsrinivasan Non, je n'avais pas vu ça, super ! Un autre signet

Mise à jour avec _Keys et sous-ensemble_ vignette basé sur une recherche binaire rapide.

Très agréable. J'adore ces vignettes. Juste quelques commentaires rapides à considérer.

Quel est le but de reprendre les noms de lignes s'ils ne sont pas utilisés ? Ou sont-ils utilisés par les opérateurs spéciaux de j (comme .N, .I, etc.) ? Je pense qu'ils sont utilisés par data.table, mais pas comme index. J'ai toujours été confus par le but de forcer les noms de lignes numérotées.

Pourquoi utiliser unique dans la première clé lorsque vous n'accédez qu'à la seconde ? Si vous ne le faites pas, vous obtenez beaucoup de lignes répétées dans la sortie, n'est-ce pas ? Peut-être évident, mais il pourrait être utile de dire/montrer ce qui se passe si vous ne le faites pas.

Toutes les clés doivent-elles être citées ? Même numériques (entiers) ? Pouvez-vous utiliser un numérique comme clé ? Des choses à surveiller?

Que se passe-t-il si votre colonne clé contient NA ? Pouvez-vous les rechercher et les remplacer (comme vous l'avez fait dans votre exemple où vous avez remplacé 24 par 0 ?

Cela peut aider à expliquer que keyby s'applique à la _output_ data.table ( ans dans votre exemple) et non à la data.table d'entrée ( flights dans votre exemple).

Pouvez-vous passer un vecteur à la clé ? En d'autres termes, pouvez-vous créer airport <- c("LGA", "JFK", "EWR") et utiliser airport directement dans i dans votre exemple près du bas ? Cela peut aider à mettre en place l'idée de transmettre une data.table différente pour une fusion.

Typo sur "correspondant" ("correspondong"). L'une des coches arrière est manquante dans la section de balayage vectoriel où vous écrivez "Les indices de ligne correspondant à origin == "LGA" etdest == "TPA"" sont obtenus à l'aide d'un sous-ensemble basé sur une clé."

@markdanese concernant le

Pourquoi utiliser unique dans la première clé lorsque l'on n'accède qu'à la seconde ?

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

Je ne sais pas si vous demandez beaucoup de suggérer une meilleure explication ou si vous n'êtes pas au courant de l'utilisation plus complexe de la clé à plusieurs colonnes.
Vous ne pouvez pas simplement utiliser la recherche binaire sur dest lorsque votre clé est c(origin, dest) , vous devriez avoir c(dest, origin) pour utiliser la recherche binaire sur dest . L'utilisation de .(unique(origin), "MIA") utilise la recherche binaire, en fournissant toutes les valeurs disponibles pour la première colonne dans la clé, puis les valeurs sélectives dans la deuxième colonne.
J'ai créé une extension pour n'utiliser que des colonnes sélectives de key. regarder l' exemple simple peut également vous aider à comprendre. Mon extension n'est pas prête à être PR au maître data.table car l'utilisation de la mémoire n'évolue pas aussi bien qu'elle le pourrait si elle était développée à l'aide des fonctions internes data.table / combinées avec la clé secondaire data.table.

Pouvez-vous utiliser un numérique comme clé ?

Vous pouvez utiliser le numérique comme clé, il est mentionné dans la section Keys and their properties .

Des choses à surveiller?

Je ne sais pas mais setNumericRounding affecte la touche numérique, cela vaut peut-être la peine de le mentionner dans la vignette.

Que se passe-t-il si votre colonne clé contient NA ? Pouvez-vous les rechercher et remplacer

Oui, le is.na() est optimisé pour utiliser la recherche binaire. Essayez data.table(a=c(1,NA_real_),b=c("a","b"),key="a")[.(NA_real_), .SD ,verbose=TRUE]

Aussi à @arunsrinivasan , la faute de frappe dans :

trouver les valeurs correspondantes dans

Merci Jan - c'est vraiment utile. J'ai proposé ces questions comme des éléments qui pourraient être brièvement mentionnés dans la vignette pour aider les nouveaux utilisateurs à comprendre ce qui se passe. Ce sont des choses qui me sont venues à l'esprit (en tant qu'utilisateur relativement nouveau) en lisant la documentation. Je ne peux pas vraiment contribuer au code, j'espère donc contribuer en aidant à la documentation.

Le vendredi 23 janvier 2015 à 20h48, Mark Danese [email protected]
a écrit:

Très agréable. J'adore ces vignettes. Juste quelques commentaires rapides pour
considération.

Quel est le but de reprendre les noms de lignes s'ils ne sont pas utilisés ? Ou sont
sont-ils utilisés par les opérateurs spéciaux de j (comme .N, .I, etc.) ? Je pense qu'ils
sont utilisés par data.table, mais pas comme index. j'ai toujours été
confus par le but de forcer les noms de lignes numérotées.

La section 1a, juste au-dessus des clés et de leurs propriétés, y répond.
Data.tables _inherit_ de data.frames.

Pourquoi utiliser unique dans la première clé lorsque l'on n'accède qu'à la seconde ? Si tu
non, vous obtenez beaucoup de lignes répétées dans la sortie, n'est-ce pas ? Peut-être évident,
mais il peut être utile de dire/montrer ce qui se passe si vous ne le faites pas.

Encore une fois, cela est expliqué exactement en dessous dans "Que se passe-t-il ici ?". je
me référer même à la section précédente où je pose les bases de
expliquant celui-ci.

Toutes les clés doivent-elles être citées ? Même numériques (entiers) ? Pouvez-vous utiliser un
numérique comme clé? Des choses à surveiller?

Il y a un exemple avec des colonnes entières sur 2d. je pensais que c'était
suffisant?

Que se passe-t-il si votre colonne clé contient NA ? Pouvez-vous les rechercher et remplacer
eux (comme vous l'avez fait dans votre exemple où vous avez remplacé 24 par 0 ?

Bon point. C'est une différence avec le scan vectoriel. Je vais essayer d'ajouter ceci.

Cela pourrait aider à expliquer que keyby s'applique à la _output_ data.table (
ans dans votre exemple) et non l'entrée data.table (vols dans votre
Exemple).

« keyby » a déjà été abordé dans la première vignette. Mais je vais voir si ça
peut être ajouté.

Pouvez-vous passer un vecteur à la clé ? En d'autres termes, pouvez-vous créer un aéroport
<- c("LGA", "JFK", "EWR") et utilisezairportdirectly ini` dans votre exemple près
le fond? Cela pourrait aider à mettre en place l'idée de passer un autre
data.table pour une fusion.

Contenu de la section suivante. C'est ainsi que nous passons aux jointures.

Typo sur "correspondant" ("correspondong"). L'une des tiques arrière est
manquant dans la section de balayage vectoriel où vous écrivez "Les indices de ligne
correspondant à l'origine == "LGA" etdest == "TPA"` sont obtenus à l'aide de la clé
sous-ensemble basé."

Merci.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment-71253738
.

Beau travail sur ces vignettes !
Mes commentaires peuvent être tardifs ou déjà couverts :

• J'aimerais voir une variété de façons / exemples d'utilisation de lignes et de colonnes dynamiques.
• Comparaison plus approfondie sur la fusion et les jointures.
• Des façons différentes / plus riches d'utiliser set . De plus, ce serait bien de voir une explication pour laquelle ce qui suit donne une erreur (voir ici ):

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

Ajout de la vignette Remodeler au Wiki .

Excellente fonctionnalité et vignette ! Merci Arun

Le mardi 23 juin 2015, 21:02 Arun [email protected] a écrit :

Vignette de remodelage ajoutée
https://rawgit.com/wiki/Rdatatable/data.table/vignettes/datatable-reshape.html
vers Wiki https://github.com/Rdatatable/data.table/wiki/Getting-started.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/Rdatatable/data.table/issues/944#issuecomment-114678716
.

l'homme pour patterns serait bien. Grande vignette

Reshape2 ne doit-il pas être chargé pour utiliser ces commandes ? Si c'est le cas, cela doit être mentionné. J'aime beaucoup l'accent mis sur "large to long" et "long to wide". Je déteste absolument la syntaxe de reshape2 (par exemple, je pense que "make_wide" est beaucoup plus clair que "dcast"). Pour cette raison, je n'écrirais pas les en-têtes de section comme "fusion de données.tables" et "fondation de données.tables". Cela n'a de sens que pour les personnes familiarisées avec le package reshape2. Je pourrais commencer par des en-têtes plus universels que ci-dessus ("long à large").

Pour ce que cela vaut, je ne peux pas exécuter la première ligne de la vignette à l'aide d'une nouvelle session R avec uniquement data.table chargée. Je ne sais pas pourquoi (peut-être que le mode devrait être "w" et non "wb"), mais
DT = fread("https://raw.githubusercontent.com/wiki/Rdatatable/data.table/data/melt_default.csv")
Retour
Error in download.file(input, tt, mode = "wb") : unsupported URL scheme

Comme toujours, merci d'avoir fait ça. C'est vraiment utile.

@markdanese merci pour les excellents commentaires.

1. reshape2 ne sera pas requis à partir de data.table v1.9.6 . Cela a également été mis à jour dans la vignette.
2. Ajout de 'large to long' et 'long to wide' aux titres, et à d'autres endroits pour éviter toute confusion pour les personnes qui sont nouvelles sur ce sujet.
3. https dans fread est implémentée dans la version devel. Vous ne pourrez donc pas encore exécuter ce code avec v1.9.4 . Soit mettre à jour, soit attendre un peu :-).

Merci pour vos encouragements.

@jangorecki patterns() ne sera pas exporté. L'utilisation sera étendue pour [.data.table à utiliser pour sélectionner des colonnes, := , .SDcols etc.

@arunsrinivasan toujours le manuel pour patterns peut aider, de la même manière qu'il y en a un pour := . Tout simplement parce que beaucoup de gens (je pense) utilisent ?fun pour comprendre le code qu'ils lisent.

Dans la vignette _join_, il peut être utile d'ajouter des exemples SQL correspondants de jointures data.table afin qu'il puisse être plus facile à récupérer pour les gars de la base de données.
Des exemples d'instructions SQL correspondantes peuvent être trouvés par exemple dans SO Comment joindre (fusionner) des trames de données (interne, externe, gauche, droite) ? .

Ce serait aussi cool d'avoir des vignettes "Réfugiés" --

• data.table pour les utilisateurs de Stata
• data.table pour les utilisateurs de SQL
• data.table pour les utilisateurs de Matlab
• data.table pour Python / pandas utilisateurs
• même data.table pour les utilisateurs de dplyr

etc. Comme un guide de démarrage rapide, mais orienté vers les émigrés.

Ajout Secondary indices and auto indexing vignette

@arunsrinivasan n'est-il pas plus approprié de ne pas utiliser _secondaire_ en relation avec _indices_ ? il était utilisé pour les _clés_ là où c'était important. Cela semble maintenant être redondant une fois que nous passons à la dénomination _index_.

@jangorecki Je pense que "secondaire" est utile pour sa relation avec les clés (primaires), peut-être :

Tri secondaire

Une meilleure description ?

mais déjà le mot _index_ a été utilisé, c'est plus joli que le _triage secondaire_ :)

Donc, vous l'appelleriez simplement « indexation automatique » ? Le "tri secondaire et l'indexation automatique" de l'OMI sont plus informatifs

_auto_ peut être en quelque sorte trompeur, car les index devraient fonctionner pour _auto_ création d'index, et aussi pour l'utilisation d'index créés manuellement - #1422 adresse la limitation actuelle à cet égard.

Je vois. Il me manque toujours votre alternative préférée - juste des "indices" ?

pas parfait mais préféré aux _indices secondaires_

J'aime beaucoup cette dernière vignette. Ma seule pensée était qu'il pourrait être utile de mentionner quels types d'opérations entraînent la suppression de l'index. D'après mes tests, il semble à peu près tout ce qui modifie le nombre de lignes ou toute opération impliquant la colonne indexée.

J'ai pensé que les exemples de « on » étaient vraiment utiles.

@markdanese bon point, ajoutera.

Merci pour les vignettes mises à jour avec la sortie de la v1.9.8.
La "sémantique de référence" fait référence à la fonction copy() et à ses nouvelles capacités pour faire des copies superficielles (en particulier à l'intérieur des fonctions, ce qui m'intéresse vraiment) :

"Cependant, nous pourrions encore améliorer cette fonctionnalité en effectuant une copie superficielle au lieu d'une copie approfondie. En fait, nous aimerions beaucoup fournir cette fonctionnalité pour la version 1.9.8 . Nous y reviendrons dans la vignette de conception data.table."

Mais la vignette de conception est manquante et le lien pointe vers un ancien problème. Le manuel de référence ne fournit pas plus d'informations sur copy() que celui fourni dans la vignette. Le reste des vignettes ne fournit aucune information sur copy .

Cette vignette sera-t-elle bientôt disponible ?

+1 pour la vignette interne. Je (et je suppose que quelques autres) sont très intéressés à contribuer un peu du côté C des choses, mais je suis un peu intimidé par les 35 000 lignes de code C (en l'état)... tout à fait la courbe d'apprentissage pour aller elle seule' - une introduction aux internes pourrait faire des merveilles !

Pour la vignette Jointure :

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

Je voulais intervenir et demander si les contributions à la vignette sont acceptées de la part de contributeurs non-code (comme moi). Je suis particulièrement intéressé à contribuer à la vignette de jointure car j'ai eu pas mal de problèmes au départ et j'ai été guidé vers les solutions des réponses d'Arun sur Stackoverflow, et j'aimerais avoir des conseils sur la façon de le faire, si cela est autorisé.

@arunsrinivasan Je vois que vous avez un point IDateTime vignette . Peut-être pourrait-il être inclus dans la vignette plus générale suggérée par @jangorecki : vignettes : séries temporelles - observations ordonnées ?

De plus, je prépare une première ébauche sur certains des sujets suggérés par jan . Peut-être que certaines parties peuvent également être pertinentes pour une vignette de jointure ? Je suis heureux de partager si quelqu'un peut le trouver utile.

@zeomal une telle contribution serait très précieuse et très appréciée !

@MichaelChirico , merci. @Henrik-P, votre brief sur les jointures normales sera-t-il complet - c'est-à-dire que vous vous concentrerez davantage sur les séries temporelles ? Sinon, je peux commencer à travailler dessus - je n'ai pas encore utilisé les jointures tournantes, donc aucune connaissance là-dessus. :)

@zeomal J'espère que je pourrai bientôt télécharger le premier brouillon, afin que vous puissiez le consulter. Dans mon brouillon, je fournis un exemple simple d'une jointure "normale" sur une seule variable, le temps, où il y a des lignes non correspondantes. J'utilise nomatch = NA . (peut-être aussi un exemple rapide avec nomatch = NULL )

Mon idée était que cette jointure simple pourrait fournir un contexte et une idée du problème, que je traite ensuite plus en détail dans les sections suivantes sur les jointures roulantes et non équi et al.

Merci beaucoup pour votre volonté de contribuer! .

J'ai une question sur l'adhésion par référence, lors de la préparation des vignettes. Le X[Y, new_col := old_col] effectue quelque chose de similaire à une jointure gauche traditionnelle sur X . Cependant, s'il existe plusieurs correspondances avec les clés de Y dans X , seule la dernière (ou la première ?) valeur correspondante de la clé est conservée. Est-ce explicitement documenté quelque part ? J'avais essayé de rechercher cela lorsque je l'ai rencontré, mais j'ai dû recourir à ma compréhension de la mise à jour par référence pour la raison. Pour un exemple reproductible,

> 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>

C'est un comportement attendu, mais ce n'est pas tout à fait simple pour un nouvel utilisateur. mult n'a pas non plus d'impact sur la sortie. Des suggestions sur la façon dont je documente cela? Ajouter merge comme solution de contournement pour une bonne jointure à gauche ?

@zeomal s'il vous plaît poster votre future question sur rejoindre la vignette dans le numéro #2181 à la place. Il semble mieux placé. Il est documenté dans set .

@zeomal Si vous souhaitez vérifier à quel point mon traitement sur les jointures normales (équi) est bref, je veux juste vous faire savoir que j'ai posté un PR sur une vignette de série temporelle .