studio - Proponer peticiones de características al equipo R básico

manual de r pdf

Question

¿Cuál es la forma / flujo de trabajo recomendado para contactar al equipo central R para proponer solicitudes de funciones?

Por "solicitudes de características" no me refiero simplemente a disparar algo así como "Me gustaría ver la funcionalidad XY haciendo XY, así que sería genial si sigues adelante y lo implementases para mí", pero proponiendo el código real en su lugar.

Amo a R y estoy dispuesto a contribuir, compartir código y todo. Sin embargo, a veces me resulta un poco difícil averiguar exactamente cómo contribuir ;-) He visto la página del desarrollador de proyectos R y he usado la lista de distribución de r-devel un par de veces. Especialmente con respecto a este último, tengo la impresión de que no es el lugar correcto / no deseado para elaborar la solicitud de función de uno con el código real (que a veces puede ser más que un simple dos líneas). Entonces me pregunto si hay una forma "mejor" o más "sistemática" para hacer eso.

EDITAR 2011-11-09

Me pidieron que brindara un breve ejemplo:

Estoy usando clases de referencia S4 extensamente e implementado muchas pequeñas funciones de utilidad para mis objetos. Una de esas funciones de utilidad es una especie de funcionalidad de "reinicio":

setRefClass(
    "A", 
    fields=list(a="numeric", b="character"),
    methods=list(
        reset=function(fields=NULL, ...){
            temp <- new("A")
            if(is.null(fields)){
                fields <- names(getRefClass("A")$fields())
            }
            sapply(fields, function(x){
                .self$field(name=x, value=temp$field(x))        
            })
            return(TRUE)
        }
    )
)

x <- new("A", a=1:10, b=letters[1:10])

x$a
x$b
x$reset(fields="a")

x$a
x$b

x$reset()
x$a
x$b

Muy a menudo, no es la característica más elegante del mundo que aparece en mi lista de "oh, eso es lo que falta". Además, podría ser una función tan "singular" que el desarrollo de un paquete completo a veces se siente como romper la tuerca con un martillo.

Answer 1

En useR este año, Brian Ripley contó una anécdota que explica la postura del equipo R-core. Dijo que aceptó un parche de dos líneas para una función de un programador R muy respetado ( John Chambers , si mal no recuerdo). Las dos líneas de código contenían tres errores (!), Que luego tuvo que corregir. Desde entonces, la posición predeterminada de R-core es rechazar solicitudes de características para R-base, incluso aquellas con el código suministrado. (Las solicitudes de reparación de errores están bien, siempre y cuando haya verificado que realmente es un error. Use el R Bug Tracking System para esto).

Si bien no es imposible obtener algo en la base R, casi siempre es significativamente (p <1e-6) más fácil crear un paquete usted mismo o agregarlo a uno existente.

Answer 2

Es muy poco probable que obtenga nuevas características en la propia base R, a menos que: i despierte el interés de uno de los equipos de desarrollo R Core, o ii) sea una extensión de la funcionalidad existente que mejore la forma en que funciona o la haga más eficiente y un miembro de R Core está suficientemente interesado. Por supuesto, puede presentar un error según el criterio de la lista de deseos y proporcionar el código, pero no se sorprenda si el equipo central R no acepta características totalmente nuevas, incluso si vienen con código.

Las razones de esta postura se han discutido anteriormente; Incluso si proporciona un código que implementa la nueva característica X para su inclusión en R, está transfiriendo la carga de mantenimiento al Equipo R básico y estos tipos tienen recursos y tiempo limitados para hacerlo. El Equipo Principal R efectivamente desarrolla la base de R para sus propios intereses / investigación / necesidades.

Como los paquetes R son casi ciudadanos de primera clase, hay pocas razones para pedirle a R core que implemente o incluya su código para la característica X. Entonces, como han dicho otros, implemente sus funciones de ideas en su propio paquete o añádalas a otro paquete que ya proporciona código relacionado con su nueva característica X.

Incluso los paquetes increíblemente útiles que son ampliamente utilizados, por ejemplo, data.table es poco probable que lleguen a la base R en el corto y mediano plazo, ya que aumentan la complejidad de la base de código, tienen una carga de mantenimiento en el R Core Team, y / o no reemplazan el código existente; data.table proporciona una extensión tipo marco de datos que es increíblemente rápida y más adecuada para grandes conjuntos de datos y "consultas" sobre esos datos. Sin embargo, no es compatible con el marco de datos de R, que emplea diferentes convenciones. Funciona bien como un paquete y puede seguir haciéndolo sin necesidad de estar en R.

Lo anterior describe la situación como la veo para las nuevas características. Para informes de errores, ¡presente un informe de error! Luego considere continuar con una discusión más detallada sobre R-Devel que cita la ID del informe de error. Los parches proporcionados para respaldar su informe de errores facilitarán la reparación de errores o la incorporación de nuevas funciones / mejoras. El parche debe incluir tanto las fuentes R que necesitan cambiar como un parche para cualquier documentación que deba cambiar como resultado. El parche debe estar en contra del árbol SVN encontrado en el servidor R SVN . Como @BenBolker menciona en los comentarios, los informes de errores se archivan mejor en el sitio web de informes de errores de R. Cualquier discusión sobre el error en R-Devel debería vincularse al informe de error. De esta forma los insectos no caen en las grietas y se pierden.

Answer 3

Esta es una gran pregunta. Aunque realmente me gusta mucho R, su modelo de desarrollo me resulta frustrante a veces. Yo diría que las mejores opciones son

1. publique la idea inicial (sin un código extenso) en R-devel y vea si puede lograr un debate / entusiasmo. Tienes que estar dispuesto a presionar: por ejemplo, logré obtener una verificación de errores adicional incorporada en el sweep hace unos años (haciendo que se queje de las dimensiones desiguales en lugar de devolver silenciosamente la respuesta incorrecta), pero solo después de proponer la idea ; esperando una semana; volver a plantear la idea; enviando un código de prototipo; probarlo para asegurarse de que no causó un golpe de rendimiento; más discusión ...
2. implementa tu idea como un paquete adicional. Esto es, por supuesto, mucho más difícil si lo que propone es un cambio en la funcionalidad del núcleo R (por otro lado, ese tipo de cambio también será mucho más difícil de aceptar). Por otro lado, puede implementar casi cualquier cosa que desee en un paquete complementario, y tiene varias ventajas. (1) Su código estará disponible para que todos puedan usarlo de inmediato (si publica en R-forge, Rforge o CRAN); (2) es una manera para que las ideas se desarrollen y refinen sin aceptación desde R core; (3) incluso si nunca es aceptado en R-core, seguirá siendo un paquete.
3. editar : intente encontrar una utilidad existente o un paquete "misc" para contribuir (por ejemplo, he contribuido al paquete plotrix Jim Lemon, que es una compilación de pequeñas utilidades de trazado), y póngase en contacto con el mantenedor / autor.
4. Publique sus elementos de lista de deseos en el rastreador de errores R (con archivos adjuntos de código, etc.). Sin embargo, serán vistos por mucha menos gente que si usas las opciones n. ° 1 o n. ° 2 y, como resultado, es más probable que languidecen en el rastreador de errores sin siquiera ver la luz del día.

Answer 4

La forma habitual es escribir un paquete y obtenerlo en CRAN. (Todos los anuncios enviados a la lista de paquetes se copian en rhelp). Luego, al demostrar su uso productivo en rhelp (o tal vez SO) se notará. Estoy pensando en los esfuerzos de Hadley Wickham, Dirk Eddelbuettel, Terry Therneau, Gabor Grothendieck, Frank Harrell y Matthew Dowle a lo largo de los años, por nombrar a los primeros seis colaboradores que vienen a mi mente y que han hecho mis esfuerzos de R más productivos. De hecho, mientras escribía esa lista, cada vez me queda más tiempo y pido disculpas a muchas otras personas que han hecho contribuciones que uso a menudo.