Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

`fwb` transpiler: progress bar is one tick short when `simple = TRUE`

Geschlossen
  • Stimmt etwas nicht?
#3 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
r
Bereich
developer-experience, tooling

Rechercherichtung

Untersuche den generierten Code in template_fwb_outer und template_fwb_FUN, beginnend damit, wie .progressr_skip_count rund um die Statistikaufrufe von fwb() gesetzt und dekrementiert wird. Überprüfe die Fortschrittsaktualisierungen gegen die Entwicklungsversion und fwb 0.6.0, einschließlich des versionsabhängigen Verhaltens; erledigt bedeutet, dass das erste Replikat nicht verschluckt wird und unterstützte Versionen genau R Aktualisierungen erzeugen, wenn die Anzahl der Replikate bekannt ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.)

Vorherrschende Sprache
R
Sterne
5
Forks
0
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus futureverse/progressify

Alle Issues in futureverse/progressify

Ähnliche Issues

Weitere Issues zu R

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.