Pourquoi tant de NA

[Jean-Emmanuel Longueville]

Bonjour,
Voici mon problème :

Code : Tout sélectionner

fp1 <- data.frame(Date= c("48", "50", "03"))
sempr <- fp1 %>% factor(.$Date, levels = c("48", "50", "03")) 

Pourquoi cette écriture fait un vecteur NA. Alors que la suivante fonctionne :

Code : Tout sélectionner

fp1 <- data.frame(Date= c("48", "50", "03"))
sempr <- factor(fp1$Date, levels = c("48", "50", "03"))

Merci

Edit cette présentation est un ecm d'un code bien plus long d'où ma recherche de faire fonctionner la première syntaxe.

[Eric Casellas]

Salut,

Je n'utilise pas l'operateur %>% mais il me semble qu'il est destiné a remplacer le 1er argument de la fonction (factor dans ton exemple)
Donc il faudrait plutôt utiliser quelque chose comme :

Code : Tout sélectionner

fp1 <- data.frame(Date= c("48", "50", "03"))
sempr <- fp1$Date %>% factor(levels = c("48", "50", "03"))

Eric

[Jean-Emmanuel Longueville]

Malheuresement ce genre d'écriture ne passe pas dans mon pipeline

[Eric Casellas]

Malheuresement ce genre d'écriture ne passe pas dans mon pipeline

et quelque chose comme :

Code : Tout sélectionner

sempr <- fp1 %>% (function(x){factor(x$Date, levels = c("48", "50", "03"))})

?

Eric

[Mickael Canouil]

Bonjour,

l'explication du pourquoi du comment du pipe.
Le pipe utilise l'argument ".". Ici vous essayez d'utiliser un opérateur (au lieu d'une fonction) dans un argument, ce qui n'est conceptuellement pas possible de la façon dont est construit le pipe.

Si j'écris plus explicitement votre pipe, on obtient la même transformation avec des NAs :

Code : Tout sélectionner

library(magrittr)
fp1 <- data.frame(Date= c("48", "50", "03"))
fp1 %>% factor(x = ., .$Date, levels = c("48", "50", "03"))
#> Date 
#> <NA> 
#> Levels: 48 50 03    

L'utilisation d'une fonction anonyme est une solution comme l'indique Eric.

Voici d'autres alternatives (pour un objet héritant de la classe data.frame) :

Code : Tout sélectionner

fp1 %>% 
  .[["Date"]] %>% 
  factor(levels = c("48", "50", "03"))
#> [1] 48 50 03
#> Levels: 48 50 03    

Code : Tout sélectionner

fp1 %>% 
  .[, "Date"] %>% 
  factor(levels = c("48", "50", "03"))
#> [1] 48 50 03
#> Levels: 48 50 03    

Code : Tout sélectionner

fp1 %>% 
  `[[`("Date") %>% 
  factor(levels = c("48", "50", "03"))
#> [1] 48 50 03
#> Levels: 48 50 03    

Code : Tout sélectionner

fp1 %>% 
  `[`(, "Date") %>% 
  factor(levels = c("48", "50", "03"))
#> [1] 48 50 03
#> Levels: 48 50 03    

Cordialement,

[Florent Aubry]

Question bête que certains trouveront hors sujet : Pourquoi utiliser la notation pipeline quand l'écriture standard fonctionne très bien (dans pratiquement tous les cas de figure) et que, de plus, le pipeline augmente dramatiquement les temps d'exécution ?

[Mickael Canouil]

L'avantage du tidyverse est la "simplicité" de lecture, mais celui-ci n'a jamais prétendu être plus performant.
Hadley Whickham présente dans son livre "Advanced R" ce point sur plusieurs exemples.

Dans le cas présent, l'écriture avec l'opérateur pipe accroit le temps de calcul par un facteur 10, pour des temps de 15 à 150 microsecondes.
Donc, selon le cas, la perte de performance est presque complètement indolore par rapport au gain en lisibilité du code.
L'aspect "dramatique" est donc très relatif et dépend énormément du contexte.

Personnellement, quand j'ai besoin de performance (simulation), je passe par les fonctions bases et/ou les packages utilisant des fonctions C/C++.
Dans un cadre classique, j'utilise le pipe et le tidyverse.

[Florent Aubry]

Mickael

1) En effet, dans le cas d'un seul appel, la perte de temps est indolore mais quand l'utilisation du pipeline est fait à l'intérieur d'une boucle, cela n'est plus vrai.
2) Bien qu'on me répète l'argument d'une plus grande lisibilité, je ne suis pas convaincu, au contraire. Je trouve que les codes utilisant le pipeline sont très peu lisible quand ils ne sont pas inutiles et personnellement, je les déconseille. Ils sont inutiles dans le cas de l'appel d'une seule fonction comme ici pour factor car placer l'objet auquel appliquer la fonction (ou souvent la méthode) en premier est plus naturel et lisible. D'ailleurs même les défenseurs de l'écriture x %>% plot n'écrivent jamais x %>% sqrt. Quant à chainer plusieurs fonctions par le pipeline, on se perd rapidement dans l’enchainement. Il faut souligner ici, que le problème d'enchainement n'est pas spécifique de R quand on utilise des fonctions, mais de tous les langages que ce soit le Fortran, le C...

En définitif, le choix du pipeline est en effet un problème de choix personnel. Ce que je regrette c'est qu'on lit un peu partout les 'avantages' de cette écriture en omettant de citer les limites, les inconvénients et les configurations où cela ne fonctionne pas.

Amicalement

[Mickael Canouil]

Pour la lisibilité (logique linéaire d’écriture des étapes), c'est plus au niveau des néophytes des langages de programmations.

En ce qui concerne le pipe, je suis tout à fait d'accord sur les abus, c.-à-d., si dans une commande R, il n'y a qu'un seul pipe, c'est qu'il y en a un de trop.
C'est un sujet qui revient souvent: viewtopic.php?f=3&t=9789#p45262

[Logez Maxime]

Bonjour,

Je partage vos avis quand a l'efficacité du pipeline, et son intérêt quand il n'y a qu'un seul pipe. Il est beaucoup plus clair pour moi de faire sqrt(x) que x %>% sqrt().
Par contre quand le code commence à être long (multiplication de fonction) alors je trouve que l'écriture pipeline est beaucoup plus lisible et permet même de séparer les parties d'un même code.
Par exemple quand tu fais des opérations, une sous sélection sur un tableau, et qu'ensuite tu fais un graph ggplot.
Par contre ça ne reste qu'une utilisation personnelle d'un code, mais pour la relecture ça va beaucoup plus vite.

Ce que je trouve dommage/dangereux, c'est que cette synthaxe et les packages tidyverse commence à être enseigné avant même les bases.
Du coup certains ne savent même plus faire des choses de bases et ou se servir de fonctions plus efficaces demandant des fois plus de manipulation.

Cordialement,
Maxime

[Florent Aubry]

Maxime
Entièrement d'accord avec votre analyse et notamment le dernier paragraphe : trop souvent des étudiants commencent par essayer de 'ruser' avec tidyverse sans vraiment savoir ce qu'ils veulent faire et ce comportement est visible quand ils viennent chercher de l'aide car leurs explications sont souvent très confuses.

Quant à la lisibilité, cela est peut-être vrai pour la personne qui a écrit le code - en fait tidyverse ne fait que reprendre une partie d'une approche utilisée depuis longtemps dans la conception des bases de données et des systèmes d'information, le diagramme des flux, mais devient pour moi assez obscur quand il s'agit de reprendre un code, peut-être aussi parce que je sais qu'il existe souvent des fonctions de base de R qui font les choses aussi bien.

Cordialement

Florent

[Jean-Emmanuel Longueville]

Bonjour,
Je ne pensais pas lancer tant de discussion dans mon cas je cherchais à modifier localement un df avant de l'afficher par un plot.
Et suis d'accord que la méthode classique est souvent plus pratique mais un code via pipe permet d'occuper moins d'espace mémoire par moment ou de ne pas devoir penser à supprimer des variables temporaires.