Interface for ensembles
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- r
- Ambito
- machine-learning
Direzione di ricerca
Inizia con la discussione sulle funzioni generiche dei modelli nella issue #39, quindi confronta gli approcci ensemble citati in loo, brms e marginaleffects. Determina se l’interfaccia debba appartenere a posterior o rstantools e definisci il comportamento del modello e dei pesi, nonché le funzioni supportate, prima dell’implementazione; il lavoro sarà considerato completato quando saranno concordati il design e la collocazione nel progetto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
(I'm not sure where this lives, so I'm putting it here because at least I know the relevant folks will see it and then we can discuss ;).)
I think it might be helpful to have a lightweight class for ensembles of models with weights. Perhaps something that contains a list of models and weights, and implements calls to most of the generic model functions (posterior_predict(), etc; basically the list here: #39) by resampling output from the model list according to those weights.
Unless I've missed something, current approaches to this seem to be duplicated across several packages (loo, brms, marginaleffects, ...); see some discussion on this twitter thread.
The advantage of what I am proposing is that packages that build on top of the generic model functions (#39) would then automatically support ensembles. Currently such packages have to be "ensemble-aware" in a non-generic way; e.g. for ensembles of brms models they have to use brms::pp_average() instead of posterior_predict() / etc.
Not sure where such a class should live (here? rstantools?). I guess this partly depends on if the generic functions from rstantools eventually get moved here per #39.
Thoughts? Pinging @avehtari @paul-buerkner @jgabry.
- Lingua principale
- R
- Stelle
- 172
- Fork
- 27
- Merge medio
- 5g 12h
- PR unite (30g)
- 5
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un 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/posterior
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Use testthat 3eForse già presa @mcol l’ha presa 7 giorni fa. Apertagood first issue test
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Tutte le issue di stan-dev/posterior
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
cran-task-views/Spatial#127 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Add two cautions to the `simulate_dyad_responses()` helpForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertadocumentation priority: low
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
Pascal-Kueng/dyadMLM#179 ·
I maintainer di solito rispondono entro 1 giorno
-
Consider changesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
OHDSI/OmopSketch#618 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
GSK-Biostatistics/tfrmt#854 ·