`fwb` transpiler: progress bar is one tick short when `simple = TRUE`
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- r
- Lĩnh vực
- developer-experience, tooling
Hướng nghiên cứu
Kiểm tra mã được sinh ra trong template_fwb_outer và template_fwb_FUN, bắt đầu bằng việc xem .progressr_skip_count được thiết lập và giảm như thế nào xung quanh các lần gọi statistic của fwb(). Xác minh các cập nhật tiến trình so với phiên bản phát triển và fwb 0.6.0, bao gồm cả hành vi phụ thuộc vào phiên bản; được xem là hoàn tất khi replicate đầu tiên không bị nuốt mất và các phiên bản được hỗ trợ tạo ra chính xác R cập nhật khi có thể biết được số lượng replicate.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.)
- Ngôn ngữ chính
- R
- Star
- 4
- Fork
- 0
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của futureverse/progressify
-
Add support for for-loops Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
Tất cả issue của futureverse/progressify
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
easystats/performance#950 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
briandconnelly/airnow#9 ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Copy cohorts to keep old cohorts Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
OHDSI/CohortConstructor#774 ·