## P值徘徊之谜
本文探讨了“P值徘徊”现象——质疑那些P值略低于传统显著性阈值0.05的结果。这个阈值大约在100年前被任意设定,尽管一直存在争议,但至今仍在使用。
作者深入探讨了P值的底层逻辑,其根源在于 Neyman-Pearson 框架,该框架侧重于在重复检验零假设时的错误率。一个关键点是:在真实的零假设下,P值应该均匀分布——任何值出现的可能性都相同。
然而,人们担心“P值操纵”(为了达到显著性而操纵数据)。模拟表明,诸如在达到期望的P值后停止数据收集之类的做法会扭曲这种均匀分布。这种扭曲*可能*证明对接近0.05的P值持怀疑态度是合理的。
进一步的复杂性来自于“林德利悖论”,即如果存在真实效应且研究具有高统计功效,那么低P值反而会*更*可能出现。这表明,在功效高的研究中,P=0.048并不一定比P=0.001提供更弱的证据。最终,作者得出结论,P值本身并不能充分证明学术不端行为,并提倡将P值置于研究功效和潜在偏差的背景下进行解读,并建议使用贝叶斯因子作为证据的更直接衡量标准。
本文是对一个复杂话题的个人探索,承认可能存在误解,并邀请反馈。
## Rust 编译器后端:总结
Rust 编译涉及多个阶段,将源代码转换为二进制代码。虽然 LLVM 是默认后端,但 Cranelift 和 GCC 等替代方案也存在。编译过程可以分解为以下阶段:AST(语法检查)、HIR(类型验证)、MIR(生命周期/借用检查),最后是代码生成(二进制生成)。
编译器的“前端”处理解析、linting 和检查,而“后端”将验证后的代码转换为特定处理器的指令。像 GCC 这样的后端充当桥梁,利用 API 生成汇编代码。
GCC 后端很有价值,因为 LLVM 不支持旧处理器。这使得 Rust 能够定位到 Dreamcast 等平台。与 `gccrs`(一个完整的 GCC 前端重新实现)不同,Rust GCC 后端 (`rustc_codegen_gcc`) 集成在现有的 Rust 编译器*内部*,利用 libgccjit 进行 GCC 交互。
实现后端需要遵循 `rustc_codegen_ssa` 接口并定义入口点。后端还可以添加优化——例如,将引用标记为不可为空,以启用进一步的代码改进。这展示了后端如何贡献于高效且平台特定的代码生成。