J'essaie d'obtenir la même chose ce que DLPLY fait avec évidemment les valeurs de retour de data.table code>. Donc, tout comme un exemple très simple: foo code> sont effondrées à un datable.table code>. Et je ne veux pas utiliser dlply code> car il passe la division data.tables code> comme data.frames code> to foo code > Qui rend d'autres opérations de données.Table dans FOO code> inefficace. p> p>
3 Réponses :
Essayez ceci:
> split(dt, dt[["p"]]) $A p q 1: A 1 $B p q 1: B 2
Oh c'était simple :-) Je m'interrogeais simplement sur la performance, puisque Split n'utilise pas data.Tables de la syntaxe et des capacités. Mais votre réponse m'a réellement donné l'allusion à la bonne direction. Merci beaucoup pour ça!
Concernant la réponse de G. Grothendieck, j'étais curieux, j'ai été curieux à quel point Split Effectue:
lapply( unique(dt[,p]), function(x) dt[x] )
Voici un Il y a plus de datable.table code> approche orientée: datable.table code> alternatives de style à ce qui précède mais que Semble être le plus rapide - voici une comparaison avec labapply code>: p>
+1 pour utiliser .by code>, lequel de ces .var code> s je n'ai pas encore appris à utiliser.
Je n'aime pas la syntaxe mais cela répond mieux à ma question.
Il suffit de réaliser que dt [ liste (liste (...)), by = p] code> n'est pas seulement la réponse la mieux mais parfaite à ma question. La colonne de résultat v1 code> peut même contenir des objets de n'importe quel type (primitives, objets de référence S3, S4, référencyclasses, ...). Cela dit, je déteste encore la syntaxe encore plus :-)
@Beasterfield Que détestes-tu exactement sur la syntaxe? Qu'attendiez-vous à la place ou pourquoi ne répond pas à vos attentes?
Eh bien, ce n'est pas que ce n'est pas aussi facile à utiliser que dlply code> mais esthétiquement j'aime dlply (dt, "id", foo) code> meilleur que dt [ liste (Liste (FOO (.SD))), by = id] $ v1 code>.
convenu, pour cette tâche particulière dlply code> a une expression plus courte - c'est ce que vous obtenez lorsque vous vous spécialisez d'un côté et demandez à SMTH non-normalement demandé à l'autre; Mais si vous avez une suggestion sur la façon dont vous pensez que cette opération pourrait mieux s'adapter à la syntaxe data.table code> - je serais curieux de l'entendre
Si drôle, j'ai couru aujourd'hui à nouveau dans le même problème et a finalement trouvé cela super i> question et encore une réponse plus grande ;-) @eddi pour répondre à votre commentaire de près d'un an, qu'en est-il d'une syntaxe comme DT [ foo, by = id, jaslist = true] code>?
@Beasterfield Je pense qu'une sorte de personnalisation de ce qui arrive aux résultats de j code> pour chaque groupe est longuement dû. Certaines choses qui pourraient arriver sont - que se passe-t-il maintenant, votre suggestion de la laisser comme une liste, une liaison plus avancée ensemble, y compris des colonnes non correspondantes, ou une correspondance de colonnes hors commandes. J'encourage vivement à soumettre une demande de fonctionnalité à ce sujet.
@eddi je suis vraiment désolé. Je semble être trop stupide pour créer un compte rurge. J'ai bien peur de ne pas être capable de soumettre une demande de fonctionnalité ailleurs?
@Beasterfield :) OK, FR Ajouté - r-forge.r-project.org/tracker/.../a>
Plyry est un emballage séparé destiné à convertir entre différentes structures de données avec facilité. Data.Table est implémentée comme une donnée efficace / améliorée. C'est son seul but. Donc, il n'y a pas de méthode efficace interne pour le faire. Ce que vous avez montré déjà (labraque) est ce que l'on peut faire.
Pourquoi voudriez-vous diviser une donnée? Cela va à l'encontre de l'ensemble des données d'utilisation de données.Table (meilleure efficacité en évitant les copies).
@Roland je suis totalement d'accord. Peut-être que mon exemple n'était pas assez clair. Ce que je veux réellement faire consiste à effectuer sur une série de données de données. Certaines opérations qui construisent dans la fin de référence
référenclasses code> que je souhaite retourner comme une liste.