Les verbes dplyr sont descriptifs : rendons-les plus verbeux !

Encore une pipe pour R.

Motivation

Dans SAS, chaque étape DATA imprime un journal :

NOTE: There were 120000 observations read from WORK.SALES.
NOTE: 7153 observations were deleted.
NOTE: The data set WORK.RESULT has 112847 observations and 11 variables.

les R dplyr les pipelines sont silencieux. logrittr comble cette lacune avec %>=%un canal déroulant qui enregistre le nombre de lignes, le nombre de colonnes, les colonnes ajoutées/supprimées et le timing à chaque étape, sans masquage de fonction.

Avec les ligatures Fira Code, %>=% s’affiche sous la forme d’une seule flèche large visuellement similaire à %>% avec un soulignement ajouté, comme un sous-titre ou, disons, pour lire entre les lignes d’un pipeline (ce qui s’est passé).

Contextes multiples

Il se passe des choses :

NOTE: There were 120000 observations read from WORK.SALES.
NOTE: 120000 observations were deleted.
NOTE: The data set WORK.RESULT has 0 observations and 11 variables.

“C’est ici que nous avons perdu toutes les lignes dans l’exécution du script”.

Pro

Lire ceci longtemps après l’exécution d’un script vous aide à voir :

• ce qui s’est passé à chaque étape du traitement des données sans avoir à réexécuter le code, par exemple dans un environnement de production où les données d’entrée changent constamment
• surveiller les processus clés
• Assurez-vous de pouvoir expliquer ce qui s’est passé (un audit, par exemple)

Dans des contextes professionnels, c’est souvent nécessaire.

Pédagogique

Cela sera également plus clair grâce à un journal de console pour ceux qui ont peu d’expérience avec le Tidyverse : les personnes qui font leurs premiers pas en programmation en suivant un tutoriel ou en apprenant elles-mêmes.

Installation

install.packages('logrittr', repos="

# or from github
# devtools::install_github("GuillaumePressiat/logrittr")

Voir github ou r-universe.

Usage

library(logrittr)
library(dplyr)

iris %>=%
  as_tibble() %>=%
  filter(Sepal.Length < 5)  %>=%
  mutate(rn = row_number()) %>=%
  semi_join(
    iris %>% as_tibble() %>=%
      filter(Species == "setosa"),
    by = "Species"
  )  %>=%
  group_by(Species) %>=%
  summarise(n = n_distinct(rn))

── iris  [rows:       150  cols:    5] ─────────────────────────────────────────────────────
ℹ as_tibble()                            rows:       150 +0        cols:    5 +0    [   0.0 ms]
ℹ filter(Sepal.Length < 5)               rows:        22 -128      cols:    5 +0    [   3.0 ms]
ℹ mutate(rn = row_number())              rows:        22 +0        cols:    6 +1    [   1.0 ms]
  added: rn
ℹ > filter(Species == "setosa")          rows:        50 -100      cols:    5 +0    [   1.0 ms]
ℹ semi_join(iris %>% as_tibble() %>=%    rows:        20 -2        cols:    6 +0    [   5.0 ms]
  filter(Species == "setosa"), by =
  "Species")
ℹ group_by(Species)                      rows:        20 +0        cols:    6 +0    [   3.0 ms]
ℹ summarise(n = n_distinct(rn))          rows:         1 -19       cols:    2 -4    [   2.0 ms]
  dropped: Sepal.Length, Sepal.Width, Petal.Length, Petal.Width, rn
  added: n

Capture d’écran

library(dplyr)
library(logrittr)

logrittr_options(lang = "en", big_mark = ",", wrap_width = NULL, max_cols = 3)

nycflights13::flights %>=% 
  as_tibble() %>=%
  group_by(year, month, day) %>=% 
  count() %>=% 
  tidyr::pivot_wider(values_from = "n", names_from = "day") %>=% 
  glimpse()

Tidylog est un package vraiment intéressant qui me motive pour celui-ci.
tidylog fonctionne en masquant les fonctions dplyr, ce qui n’est pas idéal pour moi.

Quoi qu’il en soit, c’était aussi pour moi l’occasion de tester un nouvel outil de programmation qui est beaucoup utilisé en programmation à l’heure actuelle.

logrittr utilise un opérateur de canal personnalisé et ne touche jamais à l’espace de noms dplyr. Sa sortie console est colorée et informative grâce au package cli.

Travailler avec lumberjack

Si vous connaissez déjà le package bûcheron, la compatibilité est disponible avec logrittr (les horaires sont approximatifs).

Appel logrittr_logger$new():

library(lumberjack)
library(dplyr)

l <- logrittr_logger$new(verbose = TRUE)
logfile <- tempfile(fileext=".-r.log.csv")

iris %L>%
   start_log(log = l, label = "iris step") %L>%
   as_tibble() %L>%
   filter(Sepal.Length < 5) %L>%
   mutate(rn = row_number()) %L>%
   group_by(Species) %L>%
   summarise(n = n_distinct(rn)) %L>%
   dump_log(file=logfile, stop = FALSE)
   

mtcars %>% 
  start_log(log = l, label = "mtcars step") %L>%
   count() %L>%
   dump_log(file=logfile, stop = TRUE)


logdata <- read.csv(logfile)

Écrira le contenu du journal logrittr de plusieurs étapes de données dans le même fichier csv.

Limites

• Comme tidyloglogrittr ne fonctionne qu’avec les pipelines dplyr sur R data.frames (en mémoire) et n’est pas capable de le faire avec les pipelines dbplyr à partir de bases de données (table distante/paresseuse).

• Les cardinalités de jointure bien faites dans Tidylog sont difficiles à obtenir à partir du tube car la jointure est déjà faite, pour le moment nous ne montrons que l’évolution de N lignes et N cols (avant/après).

• Oui c’est une autre pipe, pas idéale. On peut rêver d’un with_logging(TRUE) contexte qui activera le comportement du tube logrittr dans |> ou dans %>%.

Prends une autre pipe pour faire un tour

logrittr donne la priorité à l’expérience utilisateur avec un affichage structuré et coloré dans la console.

Pour l’instant, ce package n’est qu’une preuve de concept qui m’a donné l’occasion d’expérimenter un peu le cli paquet et quelques autres choses. Mais je pense que cela est nécessaire dans R, dans un domaine spécifique où les sorties SAS sont si informatives.

En rapport