data.table対dplyr：他の人ができないことやうまくできないことはできますか？
概観 私はに比較的慣れていますがdata.table、にはあまり詳しくありませんdplyr。私はSOに現れたdplyrビネットと例をいくつか読みましたが、これまでのところ、私の結論は次のとおりです。 data.tableそしてdplyrスピードに匹敵する、多くの（すなわち> 10-100K）グループがある場合を除いて、いくつかの他の状況（下のベンチマークを参照） dplyr よりアクセスしやすい構文があります dplyr 潜在的なDB相互作用を抽象化します（またはそうします） いくつかの小さな機能の違いがあります（以下の「例/使用法」を参照） 私の心の中で2.私はそれにかなり慣れているのでdata.table、それほど重くはありませんが、両方に不慣れなユーザーにとっては、それが大きな要因になることは理解しています。どちらがより直感的であるかについての議論は避けたいと思います。これは、すでに詳しい人の観点から尋ねられた私の特定の質問とは無関係であるためdata.tableです。また、「より直感的」な方が分析が速くなることについての議論は避けたいと思います（確かにそうですが、ここでも、私が最も興味を持っていることはありません）。 質問 私が知りたいのは： パッケージに精通している人にとっては、どちらか一方のパッケージを使用してコーディングする方がはるかに簡単な分析タスクがあります（つまり、必要なキーストロークと難解性の必要なレベルの組み合わせ。 あるパッケージと別のパッケージで大幅に（つまり2倍以上）より効率的に実行される分析タスクはありますか？ 最近のSOの質問の 1つで、これについてもう少し考えるようになりました。それまでは、dplyr私がすでにできることをはるかに超えるとは思わなかったからdata.tableです。ここにdplyr解決策があります（Qの最後のデータ）： dat %.% group_by(name, job) %.% filter(job != "Boss" | year == min(year)) %.% mutate(cumu_job2 = cumsum(job2)) これは、data.tableソリューションでのハックの試みよりもはるかに優れていました。とは言っdata.tableても、優れたソリューションもかなり優れています（Jean-Robert、Arunに感謝します。ここでは、厳密に最も最適なソリューションよりも単一のステートメントを優先したことに注意してください）。 setDT(dat)[, .SD[job != "Boss" | year == min(year)][, cumjob := cumsum(job2)], by=list(id, job) ] 後者の構文は非常に難解に思えるかもしれdata.tableませんが、慣れていれば（つまり、より難解なトリックを使用しない場合）、実際にはかなり簡単です。 理想的には私が見てみたいことはいくつかの良い例がなかったですdplyrかdata.tableより簡潔であるか、パフォーマンスが大幅に優れているか方法であるです。 例 …