分組數據時,ddply是推還是拉?即,它是否涉及數據框上的許多傳遞,還是僅涉及一個?ddply:推或拉?
回答
如果你看看代碼,你看到函數的一般結構:
function (.data, .variables, .fun = NULL, ..., .progress = "none",
.drop = TRUE, .parallel = FALSE)
{
.variables <- as.quoted(.variables)
pieces <- splitter_d(.data, .variables, drop = .drop)
ldply(.data = pieces, .fun = .fun, ..., .progress = .progress,
.parallel = .parallel)
}
<environment: namespace:plyr>
因此,它基本上重新排列的格式,更容易使用的變量,然後將數據分解成塊,然後在這些作品上使用ldply。這些片段由功能splitter_d生成。件實際上比列表更復雜 - 它是指向原始數據和索引列表的指針。無論何時請求列表中的一部分,它都會查找匹配的索引並提取相應的數據。這避免了多個數據副本的漂移。你可以看到如何使用getAnywhere("splitter_d")
或plyr:::splitter_d
。
ldply在每一條數據上傳遞一次。之後,它將所有內容組合到一個數據框中。其實,在幫助ldply的文件寫的是:
所有plyr功能使用相同的 拆分申請,結合策略:他們 輸入分割成更簡單的塊, 適用.fun每件,然後 將這些部分組合成一個單一的數據 結構。此功能按元素拆分列表 ,並將結果 組合成數據框。如果沒有 結果,那麼此函數將返回一個零行的數據幀和 列(data.frame())。
我自己也說不完。奇蹟,第一句話也可以在ddply的幫助頁面上找到。
Pieces實際上比列表更復雜 - 它是指向原始數據和_indices_列表的指針。無論何時請求列表中的一部分,它都會查找匹配的索引並提取相應的數據。這避免了多個數據副本的漂移。 – hadley 2010-11-16 17:24:19
@Hadley:thx糾正。我沒有真正瞭解整個源代碼。我會調整。 – 2010-11-16 17:33:06
- 1. Git的變基:力推或拉推
- 2. 無法用Bitbucket推或拉
- 3. Windows 8:混帳不能推或拉或
- 4. git:擁有2個推/拉回購同步(或1推/拉和1拉同步)
- 5. 我應該先推或拉嗎?
- 6. 不能推或拉至Github上
- 7. JMS MessageConsumer的messageListener使推或拉?
- 8. Git的廣東話推或拉文件
- 9. 選擇哪個Mercurial分支推或拉
- 10. 不能推入或拉入Git
- 11. git推(或拉)隨着本地歷史
- 12. 推/拉
- 13. 如何用Dplyr或Data.Table替換ddply
- 14. 與ddply
- 15. Ajax - 推拉?
- 16. 玻推拉窗
- 17. 使用ddply
- 18. 使用ddply
- 19. 使用ddply cumsum
- 20. 表示與ddply
- 21. 集列名ddply
- 22. git bash無法從bitbucket或github中拉或推
- 23. 遞歸Git推/拉?
- 24. Github:推拉請求
- 25. 用解析推拉
- 26. GitHub推/拉錯誤
- 27. 自舉拉和推
- 28. 推拉門動畫
- 29. 限制Git推/拉
- 30. 數據拉和推
我會說它分裂了數據,遍歷每一塊做它必須做的事情,並把它放在一起。你總是可以自己查看源代碼(嘗試'getAnywhere()',你需要它),或者等到hadley經過。 – 2010-11-16 06:30:06