not - magritte

¿Debo evitar la programación de paquetes con operadores de tuberías?

Question

¿Hay alguna razón objetiva por la que los operadores de tuberías del paquete R de magrittr , como %>% , deberían evitarse cuando magrittr paquetes en R?

Más específicamente, quiero saber si el uso de operadores de tuberías puede causar conflictos de codificación o (de manera positiva o negativa) afectar el rendimiento. Estoy buscando ejemplos específicos, concretos de tales casos.

Answer 1

Al igual que todas las funciones avanzadas escritas en R, %>% conlleva una gran sobrecarga, así que no lo use en bucles (esto incluye bucles implícitos, como la familia *apply , o los bucles por grupo en paquetes como dplyr o data.table ). Aquí hay un ejemplo:

library(magrittr)
x = 1:10

system.time({for(i in 1:1e5) identity(x)})
#   user  system elapsed 
#   0.07    0.00    0.08 
system.time({for(i in 1:1e5) x %>% identity})
#   user  system elapsed 
#  15.39    0.00   16.68 

Answer 2

El paradigma de tuberías invierte el orden aparente de la aplicación de la función en comparación con la "programación funcional estándar". Si esto tiene consecuencias adversas depende de la función de la semiótica (mi engaño original estaba destinado a ser "semántica", pero el spielchucker me refería a la semiotics y eso parecía estar bien). Resulta que creo que las tuberías crean código que es menos legible, pero eso se debe a que he entrenado a mi cerebro para que estudie la codificación desde adentro hacia afuera. Comparar:

 y <- func3 ( func2( func1( x) ) )

 y <- x %>% func1 %>% func2 %>% func3

En mi forma de pensar, la primera es más legible ya que la información "fluye" hacia afuera (y hacia la izquierda) y termina en la posición más a la izquierda y , donde la información en la segunda fluye hacia la derecha y luego "gira y gira". se envía a la izquierda. El paradigma de tuberías también permite la aplicación de función sin argumentos que, en mi opinión, aumenta el potencial de error. ) usar nombres de argumentos tiene la ventaja de mensajes de error mucho más informativos.

Mi preferencia hubiera sido por un paradigma de tuberías que tenía una dirección consistente:

 y <- func3 %<% func2 %<% func1 %<% x
 # Or
 x %>% func1 %>% func2 %>% func3 -> y

Y creo que esto fue en realidad parte del diseño original de pkg- magrittr que creo que incluía un ''tubo izquierdo'' así como un ''tubo derecho''. Así que este es probablemente un problema de diseño de factores humanos. R tiene asociatividad de izquierda a derecha y el usuario típico del paradigma de tubería dplyr / magrittr generalmente obedece esa regla. Probablemente tengo el síndrome del cerebro rígido, y todos ustedes, jóvenes, probablemente sean el futuro, así que hacen su elección. Realmente admiro el objetivo de Hadley de racionalizar la entrada y el procesamiento de datos para que los archivos y servidores SQL se vean como dispositivos serie generalizados.

El ejemplo ofrecido por David Robinson sugiere que hacer un seguimiento de los argumentos es un gran problema y estoy completamente de acuerdo. Mi enfoque habitual es usar tabulaciones y espacios para resaltar la jerarquía:

func3 ( func2( 
           func1(x, a),    # think we need an extra comma here
               b, c),       # and here
        d, e, f) 

x %>% func1(a) %>% func2(b, c) %>% func3(d, e, f)

Es cierto que esto se hace más fácil con un editor que reconoce la sintaxis cuando se comprueban las comas o paréntesis faltantes, pero en el ejemplo anterior que no se hizo con uno, el método de apilamiento / espaciado resalta lo que creo que fue un error de sintaxis. (También agrego rápidamente nombres de argumentos cuando tengo dificultades, pero creo que eso sería igualmente aplicable a las tácticas de código de tuberías).

Answer 3

Agregar dependencias a un paquete no debe tomarse a la ligera. Hablando en general, cada paquete del que depende su paquete es un riesgo para el mantenimiento futuro siempre que se actualice la dependencia, o en caso de que la dependencia deje de mantenerse. También hace que sea (un poco) más difícil para las personas instalar su paquete, aunque solo de manera notable en los casos en que la conexión a Internet no es confiable. Pero si alguien quiere poner su paquete en una unidad de disco para instalar en algún lugar, también deberá asegurarse de que tiene todas sus dependencias (y las dependencias de sus dependencias ...).

Base R y los paquetes predeterminados tienen una larga historia, y R-Core es muy consciente de no introducir cambios que puedan romper las dependencias de la corriente. magrittr es mucho más nuevo, parece que fue el primero en CRAN en febrero de 2014.

En términos prácticos, magrittr ha sido estable y parece una dependencia de bajo riesgo. Especialmente si está importando solo %>% e ignorando los operadores más esotéricos que proporciona (como lo hacen dplyr , tidyr , et al.) Probablemente esté bastante seguro. Su popularidad casi garantiza que incluso si su creador lo abandona, alguien se hará cargo del mantenimiento.