Option to visualize event times and censoring times as dots in ppc_km_overlay()
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 62/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- r
- Área
- data-visualization
Línea de trabajo
Comience en el punto de entrada ppc_km_overlay() e inspeccione cómo se trazan actualmente las curvas de Kaplan-Meier para los tiempos de evento y censura. Añada el comportamiento solicitado para los puntos opcionales, conservando el comportamiento predeterminado de la curva, y verifique después que ambos modos de visualización produzcan los gráficos previstos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I was presenting my work related to predictive model checking for survival models (Predictive Assessment and Comparison of Bayesian Survival Models for Cancer Recurrence) at StanCon and somebody asked me about a case where there are so few event times that the Kaplan-Meier curve is far from continuous. In this case, plotting the Kaplan-Meier curve for the observations is clumsy. A similar issue can arise if the time is discretized and there are only few different time points where events are happening, even though the number of events is high.
For these kinds of cases, I think it would be useful if ppc_km_overlay() had a binary parameter dots that could be used to plot the event times and censoring times as dots instead of plotting the Kaplan-Meier curve. The default value could still be dots = FALSE, which plots the Kaplan-Meier curve as before. There are some examples below.
When plotting the Kaplan-Meier curves for these two models, it can be a little bit unintuitive to say which one is fitting and which one is not, since you have to look at the points where the Kaplan-Meier curves fall.
In my opinion, the dots would be a clearer visualization, because from these you can instantly tell, which model fits and which does not.
Another nice thing about the dots is that they can indicate the exact locations where censoring is happening.
I have already implemented this in my own fork so I can make the pull request relatively easily if this is deemed to be a wanted feature for the package.
- Lenguaje dominante
- R
- Estrellas
- 443
- Forks
- 93
- Merge medio
- 15 h 46 min
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de stan-dev/bayesplot
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
pp_check and rvarsAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
documentation
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
Todos los issues de stan-dev/bayesplot
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
rfordatascience/tidytuesday#1089 ·
-
Component: R Type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
apache/arrow#51695 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
nflverse/nflverse-rosters#102 ·
-
bug priority: should
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
The-Strategy-Unit/nhp_outputs#477 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
InseeFrLab/melodi#27 ·