[Forum] Discussion générale sur la documentation #9

Closed linogaliana closed 3 years ago

In GitLab by @oliviermeslin on Mar 17, 2020, 08:47

Bonjour,

Cette issue a vocation à rassembler toutes nos réflexions et discussions sur l'orientation générale de la documentation. Ci-dessous les messages de Christian et Romain.

In GitLab by @oliviermeslin on Mar 17, 2020, 08:50

Message de Christian:

Blague à part, les fiches ont plusieurs catégories de destinataires:

Ceux qui écrivent des programmes pérennes, pour lesquels la maintenabilité longtemps après leur départ est capitale. On pourrait davantage leur recommander dplyr en raison de la lisibilité supérieure de sa syntaxe.

Ceux qui écrivent des programmes plus "ad hoc", pour lesquels en effet dplyr n'a pas à être l'alpha et l'omega. Je ne sais pas s'il faudrait distinguer d'autres catégories.

On peut envisager que certaines fiches ne soient écrites que pour un seul de ces deux publics, et certaines fiches pourraient être rédigées différemment pour les deux cibles.

In GitLab by @oliviermeslin on Mar 17, 2020, 08:51

Réponse de @RLesur :

Bonjour,

Je me permets de contribuer au débat dplyr vs. le reste du monde. Tout dépend de l'objectif de cette doc et du contexte.

Au SSM Justice, par exemple, nous avons "imposé" l'utilisation de dplyr (et SQL) : en effet, les données étant dans des bases de données, on impose l'utilisation de dplyr/dbplyr. Et on explique que l'objectif est de déporter les traitements : on proscrit un dbGetTable() suivi de R-base (ou bien data.table). On leur interdit également de sauvegarder des données localement (sauf des petits cubes). Avec ça on couvre 90% des besoins et on explique que si les personnes veulent aller plus loin, elles doivent faire leurs requêtes en SQL. D'ailleurs, petite digression, je suis frappé par le manque de maîtrise global de SQL. Evidemment, les rares économètres ont besoin de plus mais ils auront compris que le reste des ressources du serveur R leur est disponible : donc ils soutiennent ces recommandations (c'est dans leur intérêt).

L'utilisation de dplyr a également pour avantage de former très facilement des non statisticiens. Dans le contexte d'un SSM, c'est important.

De façon générale, il me semble essentiel d'apprendre aux personnes à faire des choix éclairés en fonction du contexte.

Et sinon, autre sujet : git. Tout les utilisateurs de R s'y sont mis chez nous, c'est maintenant perçu comme allant de pair. Ils commencent également à mettre leurs programmes SAS sous git. On commence également à basculer des documents de comitologie sous git : chefs de division et chef de département font l'effort d'y passer. Chez nous, tout le monde est maintenant convaincu qu'il faut systématiquement mettre son code source et ses documents sous contrôle de version, donc l'adhésion est forte. En tout cas, personne n'a envie de revenir en arrière. On envisage donc d'imposer l'utilisation de git à tous les projets stats.

Bon confinement,

Romain

In GitLab by @linogaliana on Mar 17, 2020, 09:11

changed title from Discussion générale sur la documentation to {+[Forum] +}Discussion générale sur la documentation

In GitLab by @linogaliana on Mar 17, 2020, 16:35

changed the description

In GitLab by @linogaliana on Mar 17, 2020, 16:35

changed the description

In GitLab by @linogaliana on Mar 17, 2020, 17:29

Je vais apporter ma contribution au débat brûlant dplyr vs data.table. Pour être tout à fait honnête, j'utilise data.table tout le temps, même pour de petites données. Du coup, mon coeur penche pour data.table. Je vais essayer aussi de contextualiser par rapport à l'infrastructure de l'Insee.

PS: beaucoup d'éléments proviennent de la formation que je prevois sur le traitement de données volumineuses avec R.

Sur la grammaire

La syntaxe data.table a mauvaise presse auprès des utilisateurs de dplyr. Il est effectivement certain que passer à la syntaxe data.table induit un coût d'apprentissage pour les utilisateurs habitués à la grammaire du tidyverse. Cependant, comme ces deux approches reposent sur la philosophie du split-apply-combine, passé la forme différente, ce qu'on sait faire avec l'un peut facilement être traduit avec l'autre. Je recommande vivement la consultation de ce post qui compare de manière extensive les deux grammaires. Les 5 verbes fondamentaux du tidyverse (filter, select, mutate, arrange et summarise) ont ainsi une traduction en data.table.

Comme Hadley Wickham l'évoque, il est vrai que sans connaissance de data.table, les verbes équivalents sont moins intelligibles que ceux du tidyverse. En revanche, une fois que l'utilisateur est familiarisé avec elle, cette syntaxe est très puissante et permet de réaliser des opérations très complexes de manière assez aisée.

Pourquoi utiliser data.table quand on sait utiliser le tidyverse?

Je vois alors trois raisons principales:

La difficulté à utiliser l'évaluation standard avec dplyr vs facilité en data.table
data.table est très rapide et parcimonieux en RAM. Pour une infrastructure partagée aux ressources limitées, si on est dans une approche in-memory, on peut difficilement faire mieux que data.table à mon avis
La moindre stabilité du tidyverse par rapport à data.table. Pour moi c'est secondaire (avec des tests de non-régression on peut contrôler) mais je comprends que cela rébute pour des besoins de production. Je pense que ce ne serait pas un problème avec une architecture dockerisée mais ce n'est pas le cas sous AUS.

1. Evaluation standard vs non standard

La plupart des tutos qu'on trouve sur internet reposent sur le principe de l'évaluation non standard, que ce soit en dplyr ou data.table. On est généralement rapidement amené à avoir besoin de l'évaluation standard lorsque, par exemple, on désire écrire une fonction dont un argument est un nom de colonne. Sur ce point, je trouve que c'est la galère avec dplyr (mais c'est peut-être une histoire de goût personnel, je peux l'avouer). La vignette sur le sujet est, je trouve, assez obscure. En data.table c'est beaucoup plus simple, je trouve: un petit get et c'est gagné ! :smile:

Approche	Evaluation standard (SE)	Evaluation non standard (NSE)
`dplyr`	`df %>% dplyr::filter(x < 10)`	`df %>% dplyr::filter(!!rlang::sym("x")<10)`
`data.table`	`df[x<10]`	`df[get('x')<10]`

2. Sur la vitesse et la mémoire

C'est le gros point fort de data.table. La réponse d'Hadley Wickham sur cette limite est intéressante:

Memory and performance [...] to me, they're not that important. Most R users work with well under 1 million rows of data, and dplyr is sufficiently fast enough for that size of data that you're not aware of processing time. We optimise dplyr for expressiveness on medium data; feel free to use data.table for raw speed on bigger data.

Hadley Wickham (lien)

Ce que je comprends de ce post c'est que traiter efficacement de grosses bases de données en R ne correspond pas aux cas d'usage pour lesquels le tidyverse a été développé. Le package data.table est plus rapide mais est aussi moins gourmand en RAM. Il s'agit donc d'une solution intéressante pour des bases de données de grosses tailles (comme les données administratives) mais dont le volume reste inférieur à la mémoire disponible.

L'alternative à data.table sur des bases de cette taille ne me paraît pas être dplyr mais dbplyr. C'est probablement mieux pour une infrastructure aux ressources limitées en RAM: on n'importe pas les données dans une seule machine mais réparti mieux la charge entre CPUs. Mais, sauf erreur de ma part, on ne peut pas encore appliquer cette approche sous AUS...

3. Sur la continuité

J'ai un avis moins tranché parce que, à mon avis, c'est un faux problème. Le tidyverse évolue vite parce qu'il est porté par une communauté très active, qui l'améliore continuellement. Il faut être prudent quand on utilise un des packages de l'écosystème, notamment s'il repose sur rlang, mais c'est aussi un des intérêts d'utiliser des langages open-source que l'amélioration continue.

In GitLab by @RLesur on Mar 17, 2020, 20:32

J'approuve les termes du débat tels que posés par @linogaliana. Pour moi, ça résume bien la situation.

In GitLab by @gillesfidani on Mar 18, 2020, 08:48

quelques réflexions / idées / questions en vrac :

comme soulevé par PY, quid de l'intersection des projets ussr/documentationr
risque de saturation / éparpillement de la doc R en général (voir une liste de ressources déja dispo sur https://github.com/frrrenchies/frrrenchies) --> recentrer documentationr sur l'usage de R dans le cadre d'un INS ? cibler les besoins "grand public à l'insee" : profil type chargé d'étude ?
est-il possible de télécharger des jeux de données depuis gitlab et les intégrer dans la doc pour montrer autre chose que des exemples déja dispo dans les vignettes des packages ?
concernant le téléchargement de données depuis R, c'est un besoin récurrent pour moi, si c'est également le cas pour d'autres utilisateurs, ne devrait-on pas faire une fiche (ou au moins un paragraphe) sur cet aspect ? via download.file, rsdmx ?

In GitLab by @oliviermeslin on Mar 18, 2020, 09:35

Je suis d'accord avec @linogaliana. Quelques éléments en plus:

Depuis quelques mois, je manipule quotidiennement de grosses données administratives avec R (environ 20/30 Go), ce qui me paraît être un cas d'usage assez courant à l'Insee si l'usage de R se généralise. Ces traitements m'amènent à occuper quasiment un serveur AUS entier (ma session R occupe souvent plus de 60 Go de RAM). J'utilise uniquement data.table, essentiellement en raison de sa gestion de la mémoire. Indépendamment de la question de la vitesse, je ne pense pas que je pourrais exploiter les données avec le tidyverse en raison des limitations d'AUS (100 Go de RAM par VM).
L'opposition dplyr facile à utiliser mais lent versus data.table rapide mais compliqué va peut-être être dépassée grâce au package dtplyr qui permet de faire du data.table avec une syntaxe dplyr. Ceci dit je ne l'ai pas encore testé, mais c'est une piste intéressante.
Sur la question de la continuité des codes pérennes: je ne pense pas que le choix des packages soit la bonne entrée dans le sujet, car les outils adaptés (et donc les packages) peuvent varier d'un cas d'usage à un autre. Selon moi, la meilleure question serait plutôt: comment contrôler suffisamment bien les versions de code et les dépendances pour assurer la reproductibilité des codes? Cette question tourne plutôt autour de l'usage des outils type Gitlab/renv/Docker. Et là, je pense qu'on a une grosse marge de progression (notamment sur la gestion des dépendances).

In GitLab by @linogaliana on Mar 18, 2020, 09:45

L'opposition dplyr facile à utiliser mais lent versus data.table rapide mais compliqué va peut-être être dépassée grâce au package dtplyr qui permet de faire du data.table avec une syntaxe dplyr. Ceci dit je ne l'ai pas encore testé, mais c'est une piste intéressante.

Je suis d'accord, c'est une piste intéressante. D'autant que la tambouille derrière (basée sur l'évaluation paresseuse) a été modifiée pour accélérer le code. (cf. Hadley) Je vois néanmoins un problème majeur, mentionné ici:

To match dplyr semantics, mutate() does not modify in place by default. This means that most expressions involving mutate() must make a copy that would not be necessary if you were using data.table directly. (You can opt out of this behaviour in lazy_dt() with immutable = FALSE)

Donc il faut faire attention avec ce type de wrapper car il ne s'agira pas d'un approche qui soulagera la charge RAM du serveur autant qu'une approche data.table only

In GitLab by @linogaliana on Mar 18, 2020, 09:48

concernant le téléchargement de données depuis R, c'est un besoin récurrent pour moi, si c'est également le cas pour d'autres utilisateurs, ne devrait-on pas faire une fiche (ou au moins un paragraphe) sur cet aspect ? via download.file, rsdmx ?

Oui je pense que ça peut typiquement faire l'objet d'une fiche (webscraping par exemple) car il existe des centaines d'approches possibles et il est difficile de savoir, a priori, laquelle est préférable (personnellement je n'ai pas les idées claires pour savoir s'il existe une voie royale pour le faire). Il faudra mettre une section: Comment gérer le proxy je suppose

In GitLab by @gillesfidani on Mar 18, 2020, 09:53

Sur la question de la continuité des codes pérennes: je ne pense pas que le choix des packages soit la bonne entrée dans le sujet, car les outils adaptés (et donc les packages) peuvent varier d'un cas d'usage à un autre. Selon moi, la meilleure question serait plutôt: comment contrôler suffisamment bien les versions de code et les dépendances pour assurer la reproductibilité des codes? Cette question tourne plutôt autour de l'usage des outils type Gitlab/renv/Docker. Et là, je pense qu'on a une grosse marge de progression (notamment sur la gestion des dépendances).

question essentielle selon moi. Je partage le point de vue de @pierre-lamarche . Pour les "gros projets, de prod", une approche tinyverse me semble appropriée à l'heure actuelle (pas de doctrine claire pour gérer la reproductibilité). En attendant, un usage raisonné des packages tiers me semble la seule solution.

Je rajoute packrat dans la liste des outils, mais je crois savoir qu'il y en a bien d'autres.

In GitLab by @gillesfidani on Mar 18, 2020, 10:19

Il faudra mettre une section: Comment gérer le proxy je suppose

@AureDisanto , effet boomerang du problème dont je t'avais parlé pour accéder aux données eurostat depuis le poste nomade en télétravail (ipv4 / ipv6 for ever ...)

In GitLab by @oliviermeslin on Mar 18, 2020, 12:56

comme soulevé par PY, quid de l'intersection des projets ussr/documentationr

Il faut effectivement y réfléchir. Ceci dit, je ne souhaite pas trop me contraindre à ce stade avec l'approche USSR qui ne fait pas consensus (notamment la recommandation systématique de dplyr et de ggformula).

risque de saturation / éparpillement de la doc R en général (voir une liste de ressources déja dispo sur https://github.com/frrrenchies/frrrenchies) --> recentrer documentationr sur l'usage de R dans le cadre d'un INS ? cibler les besoins "grand public à l'insee" : profil type chargé d'étude ?

Dans l'esprit des personnes qui en ont lancé l'idée (notamment Benoît), la documentation R est 1/ centrée autour des cas d'usage de l'Insee; 2/ pas exhaustive du tout; 3/ pleine de références à d'autres ressources internes (formations, tutoriels divers) et externes (doc et vignettes des packages, tutoriels, livres de H. Wickham and co, posts de SO...).

In GitLab by @oliviermeslin on Mar 18, 2020, 12:59

concernant le téléchargement de données depuis R, c'est un besoin récurrent pour moi, si c'est également le cas pour d'autres utilisateurs, ne devrait-on pas faire une fiche (ou au moins un paragraphe) sur cet aspect ? via download.file, rsdmx ?

Entièrement d'accord. Tu peux le proposer ici: #6

In GitLab by @gillesfidani on Mar 23, 2020, 09:21

je continue l'échange engagé ici

Ce que je veux dire par là, c'est que si on m'imposait de choisir entre R-base/data.table et dplyr, je choisirais... SQL.

Tout d'abord, bravo @RLesur pour la "chute", je ne la voyais pas venir : excellent !

Faites attention, ce serait vraiment dommage de recréer au sein de l'Insee la fracture qu'il y a dans la communauté R entre tidyverse et tinyverse. Je ne comprends pas ce besoin que ressentent les adeptes/partisans de chaque côté de vouloir imposer leurs vues aux autres...

effectivement, ce serait dommage et dommageable pour tous. Mon post n'avait d'autres objectifs que de préciser l'orientation pédagogique de documentationR. En d'autres termes : que fait-on ? baseR, tidyverse, data.table, les 3, autres ? Pour ma part, je pense que "mixer" les 3 syntaxes dans la doc serait pénalisant pour les agents qui découvrent / doivent se former à R. Sur cette question, je pencherais plus pour n'en utiliser qu'une seule, par souci de cohérence et d'accessibilité. J'ai juste donné mon point de vue , mais ne considère pas détenir la vérité (d'ailleurs, en existe-t-il une ? ou alors elle est ailleurs ... :space_invader: ). J'ajoute également que je porte un regard biaisé sur la question (j'ai commencé par baseR).

A mon boulot, il y avait eu un gros cycle de formations à R-base en 2014-2015. Bilan : énorme flop, les gens ont détesté et ont été découragés. Avec les mêmes personnes, on a essayé le tidyverse en 2017/2018. Les retours ont été : on n'avait rien compris avant et là, ça paraît plus simple. Et les gens se sont mis à R grâce au tidyverse.

j'ai fait les 2, et n'ai pas réussi à convaincre grand monde, pour l'une ou l'autre syntaxe : je suis le maillon faible :sob:

Ma position rejoint donc celle de @RLesur : les débutants ont tendance à apprécier le tidyverse, et je suis convaincu que c'est plus facile pour débuter, mais ça ne peut en aucun cas suffire en régime de croisière.

L'approche dplyr semble faire consensus pour une entrée en matière. La question que je me pose alors, c'est l'intérêt de lancer un projet comme documentationR distinct des travaux déja réalisés par le GT USSR. J'ai bien en tête la remarque de Benoit Roupper à ce sujet : "ça ne me choque pas de voir plusieurs initiatives se monter ...". Peut-être que son objectif est de fusionner les 2 "branches" plus tard, lorsqu'elles seront arrivées à maturité ?

Dans tous les cas, vous pouvez compter sur moi pour ~~troller un max~~ participer à l'effort de documentation / formation / pédagogie sur R. Je vous fais confiance pour la stratégie pertinente à adopter. J'ai juste besoin de savoir pour adapter la syntaxe dans mes contrib.

In GitLab by @ggenin on Mar 28, 2020, 17:55

Bonsoir (je viens de finir de cuire les crêpes, je vous en envoie par mail)

Je viens seulement de lire ce fil.

En fait, dbplyr fonctionne avec une base de données (db), non ? Il faut donc avoir une base de données. Une base, non une "table" de données. Une base contient un moteur. Ça fait bizarre de dire cela, mais je doute parfois que tlm connaisse les db. Si au SSM Justice ils stockent leurs données dans des db, ce n'est (malheureusement à mon avis) pas le cas à l'Insee. La seule db dont nous avons accès dans les SED est celle de SL42, qui est une série de tableaux avec 1000 colonnes enregistrés dans une db.

Et d'après ce que j'ai compris, au SSM, c'est la db qui effectue le gros des traitements, pas R. R se contente d'envoyer les instructions à la db et récupérer de petits tableaux, puis faire quelques fignolages pour enjoliver (un graphique par exemple).

Je me trompe ?

In GitLab by @ggenin on Mar 28, 2020, 18:53

Autre chose : avec dplyr, je peux empiler tout plein d'actions les unes après les autres. Et chaque étape peut donner un résultat. Je ne sais pas si cela reste lisible avec data.table. Un exemple :

# toto <-    # pour voir la tête de la table intermédiaire, au cas où...
tab_indic %>%                                # table de départ
  # ajout du dépt pour jointure ultérieure
  mutate(dept = case_when(commune < "97000" ~ substr(commune, 1, 2),
                          TRUE              ~ substr(commune, 1, 3))) %>% 
  # jointure ouverte pour récupérer la région (reg)
  merge(y = ref_dept %>% select(dep, reg), 
        # by = c("dept", "dep"), # ne marche pas ??
        by.x = "dept", by.y = "dep",
        all.x = TRUE) %>%
  mutate(dept = factor(x = dept,               # transforme dept en facteur (- gros)
                       levels = ref_dept$dep),
         dept_lib = factor(x = dept,           # récupère le dept_lib 
                           levels = ref_dept$dep,
                           labels = ref_dept$ldep)) %>% 
  mutate(reg = factor(x = reg,                 # code région
                      levels = ref_reg$reg),
         reg_lib = factor(x = reg,             # récupère le libellé region
                      levels = ref_reg$reg,
                      labels = ref_reg$libreg)) %>% 
  group_by(reg_lib) %>%                        # regroupe par région
  summarise(pop_2016 = sum(p16_pop)) %>%       # calcule la population régionale
  arrange(pop_2016 %>% desc())                 # un tri pour faire joli

In GitLab by @oliviermeslin on Mar 28, 2020, 19:07

Si au SSM Justice ils stockent leurs données dans des db, ce n'est (malheureusement à mon avis) pas le cas à l'Insee.

c'est la db qui effectue le gros des traitements, pas R. R se contente d'envoyer les instructions à la db et récupérer de petits tableaux, puis faire quelques fignolages pour enjoliver (un graphique par exemple).

Je ne connais pas le SSM Justice, mais j'ai deux commentaires:

c'est vrai que tu peux faire travailler la base de données et récupérer les résultats avec R, mais un autre gros intérêt des bases de données porte sur la mise à disposition des données: elles permettent charger directement des données en R, sans passer par un format csv ou SAS ou autre.
En fait, mon expérience (récente) est qu'il y a beaucoup de données qui sont structurées sous forme de bases de données à l'Insee, mais que les utilisateurs n'y ont pas accès car ces bases sont réservées à la production. Par exemple, toutes les zonages d'études sont mis à disposition sous forme de tables SAS, mais en demandant à la bonne personne j'ai obtenu l'accès à la base de données, et c'est vraiment beaucoup plus agréable pour travailler avec R.

In GitLab by @oliviermeslin on Mar 28, 2020, 19:11

On peut enchaîner très facilement les opérations avec data.table (il y a un équivalent de %>%). C'est vrai que la syntaxe data.table est vraiment déroutante au début, mais quand on a appris à s'en servir, le code est aussi lisible (et beaucoup plus court) qu'avec dplyr. Et c'est beaucoup plus rapide sur des grosses données.

Si ça t'intéresse, @linogaliana et moi avons presque fini une fiche sur data.table dans la branche fiche_datatable. Tu peux la lire si tu veux, on serait très preneurs de ton avis.

In GitLab by @ggenin on Mar 28, 2020, 19:45

Je suis assez d'accord, sauf que je ne trouve pas bien normal de devoir avoir les bons amis pour pouvoir travailler alors que ceux qui n'ont pas les bons amis se galèrent avec des fichiers XL téléchargés depuis internet. Comme de plus en DR tout tout doit passer par la hiérarchie, c'est même plus que dangereux, voire suicidaire. Pour moi, il y a un truc qui ne tourne pas rond.

In GitLab by @ggenin on Mar 28, 2020, 19:47

OK, je découvrirai cette méthode au passage ! Merci bien !

In GitLab by @RLesur on Mar 28, 2020, 21:25

Je me trompe ?

Non, tu as tout compris. On a un peu travaillé (pas moi, mes prédécesseurs) à ce que pouvait être l'environnement de travail adapté (en tenant compte du profil des utilisateurs mais aussi des informaticiens qui alimentent les statisticiens en données).

elles permettent charger directement des données en R, sans passer par un format csv ou SAS ou autre.

:smile: Sauf motif valable (économétrie/machine learning), la personne qui fait ça aura le droit à une piqûre de rappel sur le fait qu'il faut mettre dplyr::collect() tout à la fin de son traitement :wink:.

In GitLab by @gillesfidani on Mar 29, 2020, 08:34

closed

In GitLab by @gillesfidani on Mar 29, 2020, 08:34

reopened

In GitLab by @ggenin on Mar 29, 2020, 09:43

Ah tiens, j'y pense. Ce qui m'aiderait, c'est une liste des erreurs fréquemment rencontrées. En annexe de la doc, référencée selon la fonction. Car on reste souvent coincé pendant des heures sur un truc idiot. On avait cela pour Oracle, un bouquin sur tous les messages d'erreur, très bien fait d'ailleurs. Le but ici n'est pas d'être exhaustif, mais d'aider à résoudre des cas fréquents, ou des bugs, avec une solution simple.

In GitLab by @RLesur on Mar 29, 2020, 10:09

Object of type 'closure' is not subsettable

In GitLab by @gillesfidani on Mar 29, 2020, 11:31

cannot allocate vector of size n Mb

In GitLab by @oliviermeslin on Mar 29, 2020, 13:46

Je trouve cette idée excellente. Je crée une issue sur le sujet.

In GitLab by @gillesfidani on Mar 30, 2020, 07:25

ce qu'il ressort de nos échanges dans les issues (script on demand)

Je me sers parfois de ce type de support dans des présentations pour :

faire joli ...
discuter des "thèmes/questions/concepts" les + fréquents

nuage_documentationr

PS : juré, je n'ai pas rajouté des occurences du mot datatable pour qu'il soit plus gros que dplyr :hand_splayed:

In GitLab by @linogaliana on Mar 30, 2020, 08:01

@gillesfidani @RLesur et @oliviermeslin : nos échanges l'autre jour m'ont amené à enfin rédigé un post de blog que j'avais en tête depuis longtemps

In GitLab by @ggenin on Mar 30, 2020, 08:26

Vous connaissez ce truc ? https://teaching.slmc.fr/r/ On vient tout juste de nous l'envoyer dans ma DR. C'est du Rbase :) dplyr, c'est pas gagné !!

In GitLab by @gillesfidani on Mar 30, 2020, 08:28

ici pour dplyr : https://teaching.slmc.fr/perf/index.html

In GitLab by @gillesfidani on Mar 30, 2020, 08:38

j'en conclus que tu préfères dplyr à data.table ... :smile:

btw, très intéressé par "Les conséquences économiques de l'intelligence artificielle".

In GitLab by @ggenin on Mar 30, 2020, 09:09

Je commence à tester tidyfst, dans le but de NE PAS charger mes grosses données. https://cran.r-project.org/web/packages/tidyfst/tidyfst.pdf Déjà j'ai réussi une requête qui marche. :) Je peux tenter une fiche, si vous voulez.

In GitLab by @ggenin on Mar 30, 2020, 09:19

j'en conclus que tu préfères dplyr à data.table ... :smile: Ben oui, je ne connais pas (encore) data.table.

In GitLab by @RLesur on Mar 30, 2020, 09:26

intéressant ! je ne savais pas que tu avais un blog :thumbsup:

In GitLab by @RLesur on Mar 30, 2020, 09:30

C'est la formation de Martin Chevalier, elle existe depuis un bout de temps, c'est dommage que l'information n'ait pas été diffusée avant. @ggenin Martin nous a fait une présentation pour spyrales ici. Dans ce même blog, tu trouveras également différentes présentations de formations disponibles en ligne sur R (celle du MTES, de Joseph Larmarange et de Julien Barnier).

In GitLab by @oliviermeslin on Mar 30, 2020, 09:33

Super article!

Il y a un brouillon de fiche data.table dans la branche fiche_datatable. Tous commentaires et commits bienvenus.

In GitLab by @RLesur on Mar 30, 2020, 09:48

Je ne connaissais pas tidyfst. C'est très très récent (le package semble encore un peu confidentiel, 14 stars sur github) et le développeur n'a pas l'air très expérimenté (il utilise bizarrement git en faisant beaucoup d'upload de fichiers, ça a l'air d'être le premier package qu'il diffuse sur le CRAN, il n'y a pas de tests dans le package).

Le package a l'air intéressant et mérite d'être essayé. J'aurais tendance à conseiller d'attendre un peu avant d'utiliser un package aussi récent dans une documentation qui se veut assez générale ou alors en prenant beaucoup de précautions (c'est le :cop: qui parle :smile: ).

Cette discussion n'est plus active depuis presque 10 mois, je ferme.

InseeFrLab / utilitR