【问题标题】:R dplyr summarise bug?R dplyr 总结错误?
【发布时间】:2017-12-22 18:08:53
【问题描述】:
library(tidyverse)
stats <- read_csv('stats.csv')

## Warning: Installed Rcpp (0.12.12) different from Rcpp used to build dplyr (0.12.11).
## Please reinstall dplyr to avoid random crashes or undefined behavior.

我很确定我在更新 Rcpp 之前得到了相同的行为。

sessionInfo()

## R version 3.3.2 (2016-10-31)
## Platform: x86_64-apple-darwin13.4.0 (64-bit)
## Running under: OS X El Capitan 10.11.6
## 
## locale:
## [1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
## 
## attached base packages:
## [1] stats     graphics  grDevices utils     datasets  methods   base     
## 
## other attached packages:
## [1] dplyr_0.7.1     purrr_0.2.2.2   readr_1.1.1     tidyr_0.6.3    
## [5] tibble_1.3.3    ggplot2_2.2.1   tidyverse_1.1.1
## 
## loaded via a namespace (and not attached):
##  [1] Rcpp_0.12.12     cellranger_1.1.0 plyr_1.8.4       bindr_0.1       
##  [5] forcats_0.2.0    tools_3.3.2      digest_0.6.12    lubridate_1.6.0 
##  [9] jsonlite_1.5     evaluate_0.10.1  nlme_3.1-131     gtable_0.2.0    
## [13] lattice_0.20-35  pkgconfig_2.0.1  rlang_0.1.1      psych_1.7.5     
## [17] yaml_2.1.14      parallel_3.3.2   haven_1.1.0      bindrcpp_0.2    
## [21] xml2_1.1.1       httr_1.2.1       stringr_1.2.0    knitr_1.16      
## [25] hms_0.3          rprojroot_1.2    grid_3.3.2       glue_1.1.1      
## [29] R6_2.2.2         readxl_1.0.0     foreign_0.8-69   rmarkdown_1.6   
## [33] modelr_0.1.0     reshape2_1.4.2   magrittr_1.5     backports_1.1.0 
## [37] scales_0.4.1     htmltools_0.3.6  rvest_0.3.2      assertthat_0.2.0
## [41] mnormt_1.5-5     colorspace_1.3-2 stringi_1.1.5    lazyeval_0.2.0  
## [45] munsell_0.4.3    broom_0.4.2

使用filterinvoke_map进行组聚合

test <- function(impl, size) {
  stats %>%
    filter(message.size==size & implementation==impl) %>%
    select(ts.in, ts.out) %>%
    summarise(begin=min(ts.in),
              end=max(ts.out),
              process.time=end - begin,
              message.rate=size * 10000/as.double(process.time)/1024/1024)
}

invoke_map_df(test, crossing(impl=c('Camel', 'Spark'), size=c(1024, 1024*5, 1024*10)) %>% transpose())

## # A tibble: 6 x 4
##                 begin                 end process.time message.rate
##                <dttm>              <dttm>       <time>        <dbl>
## 1 2017-07-17 04:27:52 2017-07-17 04:28:13      21 secs    0.4650298
## 2 2017-07-17 04:30:25 2017-07-17 04:32:02      97 secs   30.2029639
## 3 2017-07-17 04:32:58 2017-07-17 04:36:17     199 secs   29.4440955
## 4 2017-07-17 04:18:31 2017-07-17 04:18:54      23 secs    0.4245924
## 5 2017-07-17 04:19:47 2017-07-17 04:21:29     102 secs   28.7224265
## 6 2017-07-17 04:23:10 2017-07-17 04:26:28     198 secs   29.5928030

使用group_bysummarise

stats %>%
  group_by(implementation, message.size) %>%
  summarise(total.size=sum(message.size), 
            begin=min(ts.in), 
            end=max(ts.out), 
            duration=end-begin,
            message.rate=total.size/as.numeric(duration)/1024/1024) %>%
  ungroup() %>%
  select(begin, end, duration, message.rate)

## # A tibble: 6 x 4
##                 begin                 end       duration message.rate
##                <dttm>              <dttm>         <time>        <dbl>
## 1 2017-07-17 04:27:52 2017-07-17 04:28:13 21.000000 secs    0.4650298
## 2 2017-07-17 04:30:25 2017-07-17 04:32:02  1.616667 secs   30.2029639
## 3 2017-07-17 04:32:58 2017-07-17 04:36:17  3.316667 secs   29.4440955
## 4 2017-07-17 04:18:31 2017-07-17 04:18:54 23.000000 secs    0.4245924
## 5 2017-07-17 04:19:47 2017-07-17 04:21:29  1.700000 secs   28.7224265
## 6 2017-07-17 04:23:10 2017-07-17 04:26:28  3.300000 secs   29.5928030

由于某种原因,process.time 计算不正确,但令人惊讶的是 message.rate 取决于它是正确的!我在这里做错了吗?

使用group_bydo

stats %>%
  group_by(implementation, message.size) %>%
  do(tibble(total.size=sum(.$message.size), 
            begin=min(.$ts.in), 
            end=max(.$ts.out), 
            duration=end-begin,
            message.rate=total.size/as.numeric(duration)/1024/1024)) %>%
  ungroup() %>%
  select(begin, end, duration, message.rate)

## # A tibble: 6 x 4
##                 begin                 end duration message.rate
##                <dttm>              <dttm>   <time>        <dbl>
## 1 2017-07-17 04:27:52 2017-07-17 04:28:13  21 secs    0.4650298
## 2 2017-07-17 04:30:25 2017-07-17 04:32:02  97 secs   30.2029639
## 3 2017-07-17 04:32:58 2017-07-17 04:36:17 199 secs   29.4440955
## 4 2017-07-17 04:18:31 2017-07-17 04:18:54  23 secs    0.4245924
## 5 2017-07-17 04:19:47 2017-07-17 04:21:29 102 secs   28.7224265
## 6 2017-07-17 04:23:10 2017-07-17 04:26:28 198 secs   29.5928030

Do 的行为匹配 filterinvoke_map 组合。

外部链接

【问题讨论】:

  • 您应该包含示例输入数据以解决此问题reproducible。使用summarize 时,它肯定看起来没有正确合并时差的单位。
  • 好的电池现在包括在内:D
  • 你把durationprocess.time搞混了吗?
  • 刚刚意识到,在早期版本中我称之为 process.time,后来我认为它太长了,所以我将它命名为 duration。

标签: r dplyr tidyverse


【解决方案1】:
# Warning: Installed Rcpp (0.12.12) different from Rcpp used to build dplyr (0.12.11)

我也遇到了这个问题,通过运行解决了

remove.packages('Rcpp')
install.packages('Rcpp')
# You may need to run install.packages for multiple times and restart the R session in the process

【讨论】:

    【解决方案2】:

    我打算发表评论,但显然这需要 50 个代表点。我将 R 更新为 3.3.3,将 RStudio 更新为 1.0.143(在 OS X Yosemite 上),然后在今天早些时候更新了所有软件包。在加载 dplyr 时开始出现相同的错误,但在前期:

    警告信息: 安装的 Rcpp (0.12.12) 与用于构建 dplyr (0.12.11) 的 Rcpp 不同。 请重新安装 dplyr 以避免随机崩溃或未定义的行为。

    重新安装 dplyr 两次并没有使错误消失 - 所以我想我会等待更新的 dplyr(现在是 0.7.1)并祈祷同时我只会遇到随机崩溃,而不是未定义的行为。

    【讨论】:

    • 我想办法是安装较低版本的 RCpp,因为最新的 dplyr 是针对稍旧版本的 RCpp 编译的。我没有自己做,因为我只是使用 R 来做一些琐碎的分析,如果你正在做一些非常严肃的事情,你可以试一试。 support.rstudio.com/hc/en-us/articles/…
    • 感谢您的链接。只需在熟悉的数据集上重新运行 dplyr 函数,到目前为止没有错误,结果与以前一样。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-04-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-29
    • 2017-09-14
    • 2021-06-30
    • 1970-01-01
    相关资源
    最近更新 更多