前些天有感而发:

cosx 快成了 Base R vs. TidyVerse 的擂台了。

昨天突发奇想:

建议以后对 cosx 所有的提问都给出 Base R 版和 Tidyverse 版 。做做大脑体操。简称 B 版和 T 版。我自告奋勇整理成书。书名我都想好了:BT 擂台赛。

今天建了个 bookdown 项目:

欢迎有志之士加入一起完成。

    Cloud2016 谢谢!已合并。坟嘛,慢慢挖。项目名称,我倾向于让 BT 两个字母挨着,因为很 BT。cookbook 这个名字很好。就先叫 btcookbook 吧!

    有的操作 base R 实现不出来,因为 tidyverse 实际上实现了一个 db 层的封装,很多算子实际是透传到 db 里面的。这种比较感觉不太公平

      HarryZhu-7harryprince 嗯,有的操作用 tidyverse 也实现不出来。可能“擂台赛”这个词有些误导,然而其实并不是要他们分输赢,而是通过比较来强化我们对他们的理解和消化,所以,公平不公平,无所谓啦。

        tidyverse 主要是 dplyr 实现一系列操作, dbplyr (Database (DBI) backend for dplyr) 和 dtplyr (Data table backend for dplyr) 包等只是转化数据操作,适应不同的后端,实际是翻译工作,真正的封装是 DBI ,实现 R 与数据库的连接,实现一系列的交互操作。没有 tidyverse, Base R 通过 DBI 也可以与数据库交互, 方式是传递 SQL 语句,dplyr 与数据库交互,本质也是传递 SQL 语句,但它做了大量 SQL 操作的翻译工作,所以用户写 dplyr 定义的操作即可,从而摆脱了直面 SQL 的麻烦,但是也不要指望它能完全替代 SQL,因为它也存在一些局限 <https://dbi.r-dbi.org/articles/dbi-proposal#sec:limitations> 。

        dapengde 数据整理要不要考虑加一个 data.table 版? 比如:

        library(data.table)
        dt <- as.data.table(mtcars)
        dt[1 : .N %in% 2:5 & cyl < 6, cyl := 2]
        head(dt)

        我觉得 data.table 值得拥有更多的曝光度。只是这样一来,书名就难取了:)

          Liechi 这个例子里我本来是加上了 data.table 的,就是觉得无论放在 B 栏还是 T 栏均不妥,就割爱给删了。data.table 仅涉及数据处理吧?这样就无法贯穿 BT 全书,因为我觉得重头戏可能是 graphics vs ggplot2,还有字符串操作什么的。你要是有兴趣,可以添加个附录,给出数据处理部分每道题的 data.table 方案。一起做起来!

            dapengde 如果不新开一个分栏的话,我建议放 data.table 放在 B 栏,因为:

            data.table inherits from data.frame. ... It is inspired by A[B] syntax in R where A is a matrix and B is a 2-column matrix.

            这样就不必担心“无法贯穿 BT 全书”这个问题了。加到附录太委屈这个皮薄馅大的包了。

              Liechi dapengde 不要担心 data.table 属不属于 Base R? 它绝对属于 Base R 阵营,因为人家的描述文件写的很清楚, Title: Extension of data.frame

                我倒是觉得 local 模式如果 base R 和 tidyverse 性能没差异,大家怎么写都无所谓。
                比较有建设性的是,在 cluster 模式如何处理 PB 级别数据。比如 base R 和 tidyverse 对比如何实现 word2vec之类的。
                比如数据分析以前很少有人处理过 nginx日志,通过 tidyverse 就提供了批量处理nginx日志的一个通道。

                因为透过 db 层的封装, tidyverse 成为了强大的分布式处理工具,比如通过 geospark, RPostGIS 处理各种空间数据。
                如果把 sf 归类到 base R ,在做大数据处理的时候差异还是蛮明显的。

                其他的一些 db,比如 neo4j, elasticsearch, mongodb 等等也会有一些奇葩功能是 base R 不会考虑的,所以我说这么比较有些不公平。

                  dapengde 我看了HarryZhu-7harryprince 的两条回复之后,我觉得讨论 BT 首先要定义好什么是 Base R(B) 什么是 Tidyverse(T)?只有把这个定义好了才有后续的比较。我不想引发一些不必要的争论,我认为<https://github.com/tidyverse/> 和 <https://github.com/r-dbi> 是不同层面的两个东西,前者是 tidyverse 后者是和 tidyverse 无关的 R与数据库的接口集合。至于接口之上,用户层面写 SQL 语句(Base R 风格)还是写 tidyverse 风格的数据操作都无所谓,分布式,集群这些,甚至实时、高并发这些都不是 R 社区做的,是你说的Hadoop Spark PostGIS Redis Nginx 等数据处理、缓存、代理引擎做的, geospark, RPostGIS 都是其上的接口,这些接口需要解决如何与 Spark PostGIS 等的引擎交互,因为你想啊,传个 SQL 语句用的着 Nignx 代理 Redis 缓存 Hadoop 存储 Spark 处理吗?是用户请求和 SQL 语句的执行才需要。

                  我对 ClickHouse 略有了解,它提供了 JDBCODBC 两种驱动,所以如果是传递 SQL, 那么简单的就只需要根据 DBI 包,将其抽象封装的接口实例化即可,这样就实现了 clickhouse-r,如果需要 tidyverse 风的数据操作,就需要进一步翻译 SQL 为 dplyr 式的操作,这个翻译的过程需要写 C++/C 代码(走 ODBC 驱动)或者 Java 代码(走 JDBC 驱动)。

                  应该把 geospark sparklyr 看成一个前端,定义 dplyr 风格的操作,如果是直接基于 dplyr 就像你说的容易内存泄漏,这是显然的,因为一般人根本不知道它内部是什么? 我也不知道,所以我很菜,当年在渣浪用的是 DBI 连接 ClickHouse 分布式集群,传递 SQL,报错了比较好调。

                  这是我以前整理的一堆临时笔记,仅供参考 <https://bookdown.org/xiangyun/RGraphics/dm-import-export.html#import-data-from-database>

                    Cloud2016 啊哈哈,这本”BT擂台赛“原本没打算涉及这么深入的探讨。本来只是想搜集整理一下这里的提问和解答,帮助学习和使用而已,没想到扯到了站队问题。”只有把这个定义好了才有后续的比较“,这个态度严格上来说是对的,然而从实用角度来讲,不是”BT擂台赛“这本书的目的。如果在这一步纠缠不清,那么可能没法往下做了。你看人家 Thanos,一心一意想着打个响指灭掉一半生命,就把事儿给办了,没想着先定义一下什么是生命,人变成灰了可是身上的衣服怎么也灰了,同时体内的细菌病毒寄生虫算怎么回事儿……

                    不过,既然牵出这个话题,聊一聊也挺有意思的。

                    网上有不少关于 Base R vs. Tidyverse 的讨论(如这里这里这里这里),我看他们就直接讨论下去了,没见到先定义的,可见,二者应该是有约定俗成的范围的。你猛一看觉得是 Base R 那就是 Base R。就擂台赛来说,如果需要界定一下的话,我觉得可以这样简单界定:

                    • B 方案:不需要require()library()foo::bar()就能实现的方案。
                    • T 方案:需要且仅需要require('tidyverse')而不需要加载其他包就能实现的方案。

                    这样可能更具有操作性。这也是我为啥没让 data.table 卷入的原因。

                    我理解的 Base R,就是 R 默认安装包(参考这里):

                    • base
                    • compiler
                    • datasets
                    • graphics
                    • grDevices
                    • grid
                    • methods
                    • parallel
                    • splines
                    • stats
                    • stats4
                    • tcltk
                    • tools
                    • translations
                    • utils

                      dapengde
                      既然开始了,那就讨论一下。

                      其实我提出在 BT 擂台里加入 data.table,和站队无关,而是因为想起了 @Cloud2016 转发的 Mattlof 的文章。对文中的观点我不全认同,但是认为 data.table 值得拥有更多人知道这点,我无保留地支持。既然 BT 擂台“不是要他们分输赢,而是通过比较来强化我们对他们的理解和消化”,我想,在这个精神的指导下,加入 data.table 于比较的行列是件两全其美的好事:一来丰富了比较的多样性,让各系统的优劣充分展现;二来可以让更多人的了解 data.table 这个有很多优点的包。我觉得在数据整理部分为 data.table 单开一栏并无不可,不必拘泥于比较的对称性,即同时考虑作图和数据整理。不过既然考虑了这点,我想按照 data.table 的设计精神,将其划入 Base R 是自然的。如同建立系统发生树,总有合理的算法将“物种”聚类的。这个提议的初衷和站队无关,如果我觉得 data.table 和极乐净土更接近,也会毫不犹豫地提议将其划入 T 方案。

                      定义是重要的,在你举的 Thanos 的例子里,就算默认生命这个概念是自明的,但“一半”如何处理?是一个细菌等价于一个人这样算一半,还是按照体积或重量算的一半?如果现在设计一个函数帮助 Thanos 完成任务,定义的不清楚或许会让程序设计出现问题。你提出了你对 B 和 T 方案的定义,我想这表明你也至少部分认同定义边界是重要的。

                      我认同你对 T 方案的定义(考虑到极乐净土在一直囊括新包,不断扩张,其实这定义对 B 方案来说是不公平的;另外,管道这样本来中性的函数为管道所独占也不合理,它本不是专为 T 设计的,不过这些暂且先忽略),但我觉得 B 方案的定义太狭窄。在极乐净土出来之前,大家对 Base R 的理解和现在是很不同的。我想现在大家对 Base R 的理解一般为 “非 Tidyverse”。不过如果按照非 T 来理解 B 方案的话,似乎使得 B 方案有了无限可能,这有点耍赖:)会引发很多的问题,比如 lattice 作图要不要放到 B 方案里?但是我觉得加上一个设计精神源于 Base R,且功能强大,值得推广的 data.table 到 B 方案里应该是合理且有益的事情。

                      哈哈,突然想起最近看《西游记》时的一个感慨,“或许在天上佛道已然一家亲了,只苦了“愚昧”的世人,还在下界痴痴地守着分别心。”不过想想,世上很多事情都是由分辨始,至融汇终的(取其优点,秉承“拿来主义”),这也算世事的一个常态吧。