Bonjour, j'ai un tableau avec 3 variables comme ci-dessous
Région produit valeurs A a 20 B b 30 C d 53 D f 68 E t 26 F g 98
et je voudrais le transformer comme ci-dessous
Région a b d f t g A 20 B 30 C 53 D 68 E 26 F 98
et merci d'avance
Version imprimable
Bonjour, j'ai un tableau avec 3 variables comme ci-dessous
Région produit valeurs A a 20 B b 30 C d 53 D f 68 E t 26 F g 98
et je voudrais le transformer comme ci-dessous
Région a b d f t g A 20 B 30 C 53 D 68 E 26 F 98
et merci d'avance
Hello,
Code:
1
2 xtabs(valeurs ~ Region + produit, data )
Bonjour, j'ai utilisé une autre méthode avec la library tidyr qui donne directement le tableau
Code:data_trans<-data %>% spread(key=produit, value=valeurs)
R propose de nombreuses possibilités pour faire ce que tu désires, notamment la fonction reshape de base.
Question : pourquoi dans ta solution utiliser "%>%" et non directement : data_trans<-spread( data, key=produit, value=valeurs), le premier argument de la fonction spread étant les données sur lesquelles tu travailles ? Vas-tu utiliser x %>% sqrt à la place sqrt( x) ? Si non quel est le critère pour utiliser ou non le pipe ? [N.B. : je n'ai jamais eu de réponse à cette dernière question pourtant cela fait un certain temps que je la pose.]
Bonjour,
Pour améliorer la lisibilité lors d'un enchainement d'opérations sans avoir explicitement de valeurs allouées ou des appels imbriqués. Après libre à chacun de choisir de l'utiliser ou non...
voir par exemple https://uc-r.github.io/pipe
cdltCode:
1
2
3
4
5
6
7
8
9
10 df <- faa(bar(foo(df))) df <- foo(df) df <- bar(df) df <- faa(df) df <- foo(df) %>% bar() %>% faa()
Merci de ta réponse mais c'est la réponse convenue. En effet, sur ton exemple, cela peut améliorer la lisibilité mais dans de nombreux cas plus complexes, quand l'enchainement s'étend sur une demi-douzaine, voir plus d'une dizaine de lignes de code, cela finit par devenir très abscons. De plus, et c'est un paramètre à prendre en ligne de compte, non seulement cette écriture peut coûter très chère en termes de performances (temps de calcul essentiellement) mais n'est pas toujours compatible avec le code R, notamment d'après ce qu'on trouve sur le net, dès qu'il y a évaluation lazzy evaluation qui est quand même un point fort de R.
De plus, malgré tout ce qui est dit, je n'ai jamais trouvé aucun argument convaincant pour écrire x %>% sin() à la place de sin( x).
Bonnes fêtes
je suis assez d'accord :) Parfois il ne faut pas chercher plus loin que la réponse convenue (en réalité je n'ai rien d'autre à offrir comme réponse)... Je crois que je n'utilise le pipe qu'avec dplyr pour enchaîner qqs sélections, filtres etc!
Je suis tout à fait d'accord pour les performances mais je ne pense pas pas que le pipe soit le seul pb, plus les commandes sont "abstraites", plus ce qui se passe en dessous est "complexe" et on maîtrise peu ou pas l'allocation mémoire etc...!
Bonnes fêtes aussi et merci pour ttes tes réponses sur le forum :)