`fwb` transpiler: progress bar is one tick short when `simple = TRUE`
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 68/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- r
调研方向
检查 template_fwb_outer 和 template_fwb_FUN 中生成的代码,首先确认在 fwb() 的 statistic 调用前后 .progressr_skip_count 是如何设置和递减的。对照开发版本和 fwb 0.6.0 验证进度更新,包括依赖版本的行为;完成的标准是第一个 replicate 没有被吞掉,并且在 replicate 数量可知时,受支持的版本恰好产生 R 次更新。
由索引模型根据 Issue 内容生成。
描述
The fwb transpiler's skip count assumes fwb() calls statistic on unit weights
twice when simple = TRUE. In the current fwb development version it calls it once,
whatever simple is, so the wrapper swallows the first real bootstrap replicate's update
and the bar finishes one tick short of R. This might cause an issue once the development version is on CRAN, so I wanted to let you know before I submitted it.
template_fwb_outer sets:
.progressr_skip_count <- if (.progressr_simple) 2L else 1L
and template_fwb_FUN decrements that on each call before it starts ticking. The count is
the number of times fwb() calls statistic before the R replicates begin.
In fwb 0.6.0 and earlier, simple = TRUE did call statistic twice on unit weights: the
second call existed only to detect whether statistic had a random component, which
determined whether the bootstrap weights could later be recovered. The development version
recovers the weights from recorded RNG streams instead, so that detection became
unnecessary and the second call was removed. There is now exactly one unit-weight call in
both cases.
An unconditional
.progressr_skip_count <- 1L
is correct for the development version and for every release after it.
It would break fwb 0.6.0, though: simple = TRUE there would leave the second
unit-weight call to be counted as a tick, giving R + 1 updates against a progressor with
R steps. So if you want to keep 0.6.0 working, this needs a version test:
.progressr_skip_count <- if (.progressr_simple &&
utils::packageVersion("fwb") <= "0.6.0") 2L else 1L
Note that an unconditional skip count also removes the need to infer simple,
which the template currently does by reproducing fwb()'s default rule:
.progressr_simple <- if (is.null(SIMPLE)) WTYPE != "multinom" else SIMPLE
With a constant skip count, SIMPLE and WTYPE are not needed at all.
Related, separate: R is not always the number of replicates
Worth flagging while you're in this code, since it also makes .progressr_steps wrong.
The development version adds an exhaustive multinomial bootstrap: because there are only
n^n distinct multinomial resamples of n units, when R reaches that many fwb() uses
each exactly once and reduces R to that number. The transpiler takes steps from the
R in the call, so the bar stalls partway.
Only reachable for very small n (n = 6 already has 46656 resamples, so with the default
R = 999 nothing above n = 4 is affected), and fwb() emits a message saying it has done
this. There may be nothing worth doing about it since the number of replicates isn't knowable
from the call alone, so a transpiler arguably cannot get this right in general. Recording it
rather than proposing a fix. Sorry to add this complication.
(Note: I used Claude Code to help with these edits and this issue.)
- 主要语言
- R
- 星标
- 4
- 派生
- 0
- PR 合并指标
- 30 天内没有已合并 PR
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
futureverse/progressify 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 55/100
查看 futureverse/progressify 的全部 Issue
相似的 Issue
-
Affects Web App documentation PRIORITY LOW
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 1/5 1 小时以内 新手友好度 80/100
hubverse-org/hubCI#36 ·
-
难度 1/5 1 小时以内 新手友好度 85/100
-
Release 1.4.0 未关闭
难度 2/5 1-3 小时 新手友好度 70/100
pharmaverse/pharmaverseadam#170 ·