Tests that run on CRAN, possibly missing changes in other packages
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- r
- Ambito
- testing-qa
Direzione di ricerca
Start by reviewing the snapshot-only test blocks and the five cores = 2 blocks named in the issue, including test_psis.R, test_gpdfit.R, test_relative_eff.R, test_E_loo.R, and test_loo_and_waic.R. Check testthat’s CRAN snapshot behavior and the CRAN macOS restriction described in the issue; decide which tests should run on CRAN and add fixed-value checks or narrower skips accordingly. Done means the relevant posterior numeric behavior and parallel paths are exercised on CRAN without exceeding its stated limits.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
projpred encountered a problem where some slow tests depending on other packages were not run on CRAN, and lme4 made a change which was then not caught by reverse dependency checks. I checked loo tests and currently there are also some things that are not tested in CRAN. The good thing is that those other packages are rstan, rstanarm, and posterior, so it is likely we would know about the changes.
Snapshot tests do not run on CRAN.
In testthat 3.3.2, expect_snapshot() and expect_snapshot_value() default to cran = FALSE, and loo never sets cran = TRUE. This is the biggest gap, larger than the skip_on_cran() blocks. Thirteen test_that() blocks contain only snapshot expectations, so on CRAN they check nothing. These blocks guard the numbers that loo gets from posterior:
| loo code | posterior function | fixed-value check that runs on CRAN |
|---|---|---|
psis() main path |
gpdfit(sort_x = FALSE) |
none (test_psis.R:13 is a snapshot) |
psis() smoothing |
qgeneralized_pareto() |
none |
loo::gpdfit() |
gpdfit(wip, min_grid_pts) |
none (test_gpdfit.R is snapshots only) |
psislw() (old) |
gpdfit(wip = FALSE), qgp |
yes, test_psislw.R:30-33 |
relative_eff() |
ess_mean() |
none (test_relative_eff.R:7); line 14 only compares against ess_mean |
E_loo() diagnostic |
pareto_khat(tail, ndraws_tail) |
none (test_E_loo.R:136,144) |
loo()/waic() all |
the above plus matrixStats | none (test_loo_and_waic.R:23) |
- Interface changes are already caught on CRAN. These functions run in tests that CRAN does run, so a removed or renamed posterior argument would cause an error.
- Numeric changes are not caught. Examples are a new default grid, prior or tail length in
gpdfit,ess_meanorpareto_khat. Only the oldpsislw()path has hard-coded values.
Should we
- enable some snapshot tests in CRAN?
- add new guard tests with small fixed non-random inputs that are run on CRAN?
- trust that when something changes in posterior, we remember to check things in loo?
parallel tests do not run on CRAN
None of the cores = 2 code runs on CRAN. That covers fork (mclapply) and PSOCK (parLapply, plus clusterExport in relative_eff). The stated reason applies only to macOS.
Should we
- in the 5
cores = 2blocks, skip only on CRAN macOS, instead of on all of CRAN? This uses at most 2 cores, which CRAN allows.
- Lingua principale
- R
- Stelle
- 159
- Fork
- 37
- Merge medio
- 18h 1m
- PR unite (30g)
- 8
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di stan-dev/loo
-
code cleanup
Difficoltà 3/5 1-2 giorni Idoneità per principianti 40/100
stan-dev/loo#408 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Extend loo_plot_differenceAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
stan-dev/loo#394 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Update output structure of `loo_compare` for subsampling caseForse già presa @florence-bockting l’ha presa 64 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
Clean up issuesAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
stan-dev/loo#388 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di stan-dev/loo
Issue simili
-
bug key bindings source editor
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
REQ - Positron IDE guidanceForse già presa @johannajokio l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
get_procs() @return docs don't match returned columns, and pid column is the row indexForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
posit-dev/connectapi#532 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
Huber-group-EMBL/Rarr#294 ·
I maintainer di solito rispondono entro 1 giorno