Random-and-n

  • 2024年5月15日
  • 注册于 2022年3月27日
  • 于 如何看待 RStudio 公司将更名为 Posit

    脸书改 meta，谷歌改 alphabeta 都有扩展业务版图的意思， RStudio 这样做是大概为了摆脱对 R 的刻板印象。

    但是感觉保持名字不变把 R 按照 research 来解释要比另起炉灶简单多了，就宣传为 all-in-one research studio ，简称 RStudio 就可以了。现在这个 posit 多半既不会讨好 Python 社区，也不会让 R 社区高兴，产品改名会导致调名字里带 rstudio 的包都得报错，类似把 master 改成 main 这种。

    其实名字真无所谓，我很怀疑有多少人会因为改了名字而在 RStudio 里用 python，反而可能是到时候搜不到 RStudio 直奔 VS Code去了。

    • 于 hugo theme 的 css

      lennylin
      不要在/public里改，因为这是hugo编译之后的网站目录，修改其他网站内容之后刷新一下就被覆盖了。另外如果用较新版本的hugo serve的话，预览网站直接从内存serve，修改public下面的东西自然没有效果。

      准确的做法是

      1. 在themes/eureka/static/下找到css，复制到
        根目录/static/里。 这样根据hugo资源加载规则，会优先加载主目录/static/下的css
      2. 修改之，hugo预览看看是否有效。
        • 于 删除RData会有哪些影响？

          R默认会在关闭时提示是否需要保存工作空间，如果选择“是”就会保存到.RData文件里，并且下次启动R的时候如果发现.RData文件存在则会自动加载。优点在于会让你觉得这是从“上次结束的地方继续开始”，因为之前算好的东西都在那里。

          但实际上这样子有非常大的潜在问题：首先，这意味着你的工作空间并不“干净”，你启动R之后运行的代码结果可能受到了加载的工作空间的影响（比如一个在你代码里没有定义的变量a，却恰好在.RData里有你之前哪个项目里保存了的a变量）。这意味着你的代码结果是难以复现的——别人想重跑你的代码重现你的结果还需要跟你要一份.RData文件？

          顺着这个思路想下去，其实你自己也不能保证能够复现你的代码结果，因为这次退出之后你又保存了一下.RData文件，覆盖了曾经那个文件——你自己都回不到曾经的跑出结果的那个状态了。

          保存.RData的另一个问题在于你的不同项目、不同时期、不同目的的变量结果都存在一个.RData里面，除了前面说的带来混乱，影响结果的可重复性之外，另一个问题就是文件大小会越来越大。例如某次计算你保存了一个中间变量，是一个高维矩阵，占用内存和硬盘空间都很大，而且跑到最后忘了删除这个中间变量，于是它就一直存在在你的.RData里。

          进行数据分析，代码才是核心，有代码就可以重现出分析的结果，所以代码都是要好好保存好好注释的。而如果一些关键的计算结果，或者耗费时间很长的计算结果，就可以用RData文件保存下来，但是这个保存，往往也应该自己好好对结果文件命名，添加文档，让人知道保存的到底是什么。至于R自己默认的.RData工作空间，最好选择删掉，并设置默认不选择保存工作空间。

        • 于 【提问】关于LaTeX和Rmarkdown选择问题

          如果在rticles包里有的论文模板，那么实际上你用Rmarkdown去做是比较方便的。但这本质上还是对latex模板做的包装，而如果你的论文内容里要引入一些模板原先并未包含的内容或者别的latex包，那么就要稍微麻烦一点。另外就是现在很多合作者喜欢在overleaf这种线上latex平台合作写文章，所以你总要一点latex基础知识才好。

        • 于 【提问】关于LaTeX和Rmarkdown选择问题

          补充一句，R Markdown 的 PDF 输出实际上也是 Markdown 先转 LaTeX 再转 PDF。理论上你用 LaTeX 能写出来的东西，用 Markdown 一样都能写出来。但这只是理论上，实际上不一定有那么直接，取决于你的具体应用场景。如果你要的 PDF 格式已经有了现成的 R Markdown 包装，那通常会比直接用 LaTeX 要简单很多；否则你需要自己去做这个包装。

          如果你以后还要长期写论文，我是建议你系统学习一下 LaTeX，这些知识不会浪费的；就算你用 R Markdown，有一点 LaTeX 基础知识也是很好的，能让你更清楚背后的运作原理。

        • 于 【提问】关于LaTeX和Rmarkdown选择问题

          说一个重大区别。

          LaTeX 的输出一般是 PDF，R Markdown 则可以用一份文档输出多种格式，例如：HTML、docx、PDF（LaTeX）。

        • 于 新人求助，把数据框的每行按照某列拆分不同的行，只能用循环吗？

          试试tidyr::separate_rows()

          # 读数据
df=data.table::fread(
"
year      c1
2019     a;b
2019   c;d;e
2019     f;g
2020 h;i;j;k
2020     l;m
"
)

tidyr::separate_rows(df,c1)
#> # A tibble: 13 x 2
#>     year c1   
#>    <int> <chr>
#>  1  2019 a    
#>  2  2019 b    
#>  3  2019 c    
#>  4  2019 d    
#>  5  2019 e    
#>  6  2019 f    
#>  7  2019 g    
#>  8  2020 h    
#>  9  2020 i    
#> 10  2020 j    
#> 11  2020 k    
#> 12  2020 l    
#> 13  2020 m

          <sup>Created on 2022-05-02 by the reprex package (v2.0.1)</sup>

          • 于 列表转化为数据框
          • 于 核酸检测准确率是多少？

            一个有意思的计算，不过结果低估了核酸检测的准确性。一般核酸检测的真阳性率在百分之九十以上。

            低估的原因在于计算假设了每次核酸检测的样品里都有恒量的病毒。实际上，从感染者接触病毒到被检测出来，期间有个病毒在细胞内复制，排出细胞，最后在胞外积累的过程。核酸检测结果呈阳性的概率和样品中的病毒量有关：样品中的病毒含量越大，越容易被检测出来。检测样品里的病毒含量取决于取样部位的载毒量，而载毒量是随时间变化的。所以前几次的检测为阴性大概率是因为病毒还没有排出细胞，或者样品中痕量的病毒还不足以被 PCR 检测出来。通常感染者从接触病毒到病毒可被检测出来需要数天时间，这就是为什么核酸检测要分不同批次来做的原因---如果只是因为单次检测的真阳性率低，那么一次取样，重复检测就可以提高准确性了。去年上海迪士尼公园有个烟花下的核酸检测，新闻看起来挺暖心，但其实没有什么实际意义。因为当天去迪士尼的游客即使接触到了病毒，在几个小时内就被检测出来的可能性几乎为零。所以没啥悬念，三万多人一致阴性。坦率讲，就算有阳性，也更可能是在别的地方感染的。

            影响核酸检测结果的因素除了样品中的病毒量外，还有 PCR 引物的扩增效率， PCR 仪 和实验试剂的状态，以及实验员的操作等。其中引物的扩增效率是最先需要确定的，必须测试可靠才能大规模使用；PCR 仪和实验试剂的状态由每次实验中的阳性对照组来监测---只有这对照组的检测结果为阳性，这次实验的结果才能用；实验员的取样和 PCR 操作都很简单，可能有少数操作失误，但频繁出现操作失误的可能性很小。所以不用担心核酸检测的准确率太低 ：）

            • 于 手把手带你搭建个人博客（基础版）
            • 于 统计学专业本科生该找啥实习呢

              qaq
              关于寒假在家被骂这件事，找地方实习毕竟不治本。记得按时起床，起床后叠被子，吃饭多吃蔬菜，少玩手机；多少做点家务，跟家人多聊聊天，耐心听他们说话---毕竟这样的机会不多，而且以后可能会越来越少。

              ----------------------------------------------------------------------------------------------------------------------一个不愿意透露姓名的过来人留

              附注：该回复跟你找实习，搞钱并不互斥。

              • 于 R 4.1.0 官方支持管道 |>，爷青结

                barnett874 速度一样是不可能的，这辈子都不会一样的。|> 是从语法解析器层面实现的，把 x |> f() 直接解析为 f(x)，也就是 x |> f() 的速度几乎与直接运行 f(x) 一样；而 %>% 则没这么直接，它还要做一箩筐其它的事情。

                chuxinyuan 我的理解是 %>% 的实现太复杂了，规则太多；而 |> 的实现干净利落，有且仅有一条规则，就是我上面说的，比如它要求管道右边必须是一个函数调用，而不能是裸函数，而 %>% 则二者皆可。

                1:10 %>% head
1:10 %>% head()

1:10 |> head  # 这不可以
1:10 |> head()

                |> 也不支持 %>% 发明的占位符 .。要用占位符的话，只能显式地写一个函数，不过可以是简写版的匿名函数，如 \(.) head(., 8)，也就是一条反斜杠代替了 function 关键字。不过说实话我到现在仍然不习惯这个反斜杠，因为它在我脑子里根深蒂固成了转义符的代表，视觉上我很难把 \(x) 与 function(x) 等价起来。

                最后，不管是哪种管道，我个人对它们都并不是很热衷。%>% 的排错（debug）之麻烦，让我觉得简直难以忍受；若真能一气呵成写出一条管道，那皆大欢喜，而万一要是写不对，要查出是哪里错了，则麻烦得要死，所以我宁愿用结硬寨、打呆仗的办法写代码，哪怕这种呆办法被管道党一次次嘲弄。

                x = 1:10
x = head(x)

                因为 |> 的实现原理简单，所以出错后排错要容易得多，可以使用常见的排错手段，如 debug() 函数。