#+STARTUP: overview indent inlineimages logdrawer #+TITLE: C028AL-W2 #+AUTHOR: Arnaud Legrand #+TAGS: noexport(n) * Test et informations :noexport: ** Images # - file:assets/img/donald_trump.jpg :: [[https://upload.wikimedia.org/wikipedia/commons/d/d4/Donald_Trump_%252825653047910%2529.jpg][Wikimedia]] # - file:assets/img/trump_vs_obama_inauguration.png :: Screenshot from the # [[https://www.nytimes.com/interactive/2017/01/20/us/politics/trump-inauguration-crowd.html][NY Times]] # - file:assets/img/in_science_we_trust.jpg :: crop from [[http://drrichswier.com/2014/04/23/atheism-evolution-and-secular-humanism-masquerading-as-science-against-the-bible-and-creation/][the blog of a # conservative]]. # - file:assets/img/les_decodeurs.png :: Montage à partir du site # http://www.lemonde.fr/les-decodeurs/ le 30 juillet. Origin of every image used in this series of slides: - PhD Comics: - [[file:../assets/img/phd010708.png][phd010708.png]]: http://phdcomics.com/comics/archive.php?comicid=961 c'est du fan art, là ;) je cite phdcomics dans la vidéo donc je pense qu'on est bon et je doute qu'il vienne nous embêter vu le sujet. - [[file:../assets/img/in_science_we_trust.jpg][in_science_we_trust.jpg]]: https://www.google.fr/search?client=firefox-b&dcr=0&biw=1450&bih=783&tbm=isch&sa=1&q=in+science+we+trust&oq=in+science+we+trust&gs_l=psy-ab.3..0i13k1j0i30k1l3.2692.5748.0.5946.6.5.0.0.0.0.694.1147.0j3j5-1.4.0....0...1.1.64.psy-ab..2.4.1144...0i7i30k1.0.JVlXKVLc9a4#imgrc=bt5vbb5C4e9fHM puis http://www.patheos.com/blogs/unreasonablefaith/2012/03/a-better-motto/in-science-we-trust-coin/ normalement - [[file:../assets/img/Researcher-test.jpg][Researcher-test.jpg]]: https://fr.wikipedia.org/wiki/Imagerie_par_r%C3%A9sonance_magn%C3%A9tique_fonctionnelle#/media/File:Researcher-test.jpg - [[file:../assets/img/flipping_fiasco.png][flipping_fiasco.png]]: https://people.ligo-wa.caltech.edu/~michael.landry/calibration/S5/getsignright.pdf - [[file:../assets/img/in_science_we_trust_small.jpg][in_science_we_trust_small.jpg]]: voir file:../assets/img/in_science_we_trust.jpg - [[file:../assets/img/box-she-s-told-not-to-open-in-it-the-gods-had-placed-all-the-evils-9vbl9q-clipart.jpg][box-she-s-told-not-to-open-in-it-the-gods-had-placed-all-the-evils-9vbl9q-clipart.jpg]]: trouvé à la base sur https://politicsinpinkdotcom.files.wordpress.com/2016/12/box-she-s-told-not-to-open-in-it-the-gods-had-placed-all-the-evils-9vbl9q-clipart.jpg mais visiblement achetable ici: http://www.istockphoto.com/fr/vectoriel/femme-laissant-d%C3%A9mons-de-la-poitrine-gm165517954-24325536 *à acheter*. - [[file:../assets/img/in_code_we_trust.jpg][in_code_we_trust.jpg]]: https://www.google.fr/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwiJ2ZfIi4fXAhUJVxQKHb-xCBoQjRwIBw&url=https%3A%2F%2Fwww.spreadshirt.com%2Fa%2Bprogrammer%2Blife-A14770086&psig=AOvVaw1ZDWatztzt2-ycU-7qy-Gh&ust=1508859944930121 - [[file:../assets/img/iceberg.jpg][iceberg.jpg]]: http://www.jdubuzz.com/files/2016/03/iceberg-principle.jpg - [[file:../assets/img/iceberg_publication-1.png][iceberg_publication-1.png]] and others alike: - Crédits Juliana Freire: slides 2 à 5 de http://catt.nyu.edu/sites/default/files/files/Provenance_In_Data_Exploration.pdf - https://en.wikipedia.org/wiki/Large_Hadron_Collider#/media/File:CERN_LHC.jpg - https://fr.wikipedia.org/wiki/T%C3%A9lescope#/media/File:Hubble_01.jpg - https://en.wikipedia.org/wiki/DNA_sequencer#/media/File:DNA-Sequencers_from_Flickr_57080968.jpg - https://cnet3.cbsistatic.com/img/Ly9WLBFBoWxby2UraBktS1ftx90=/2014/06/10/1bd4587d-63a5-4d1a-b2fe-c6b692daa9bb/plantsensors-1.jpg - http://www.cerfacs.fr/avbp7x/img/FULLSCREEN/explosion-masri_incite_1Md.png - https://fr.wikipedia.org/wiki/Treemap#/media/File:Carte-proportionnelle-france.png - https://fr.wikipedia.org/wiki/Repr%C3%A9sentation_graphique_de_donn%C3%A9es_statistiques - https://fr.wikipedia.org/wiki/Visualisation_d%27informations#/media/File:InteractionAandB.png - [[file:../assets/img/RStudio-Logo-Blue-Gradient.png and file:../assets/img//knitr.png][RStudio-Logo-Blue-Gradient.png and file:../assets/img//knitr.png]]: https://www.rstudio.com/about/logos/ - [[file:../assets/img/jumping_penguin.png][jumping_penguin.png]]: http://www.istockphoto.com/be/photo/saut-penguins-de-papou-sur-iceberg-gm466554153-33737494 *à acheter*. * Internal refs/notes :noexport: ** phdcomics - version control : http://phdcomics.com/comics/archive.php?comicid=1531 - http://r-bio.github.io/intro-git-rstudio/ - https://xkcd.com/1597/ - http://phdcomics.com/comics/archive.php?comicid=961 ** Pandoc - https://enacit1.epfl.ch/markdown-pandoc/ - https://www.markdowntutorial.com/ ** Jupyter *** Install #+begin_src sh :results output :exports both sudo apt-get install jupyter-notebook sudo apt-get install python3-pip sudo apt-get install python3-matplotlib python3-numpy #+end_src Then following https://github.com/kirbs-/hide_code (note sure this is as useful as I thought though :() #+begin_src sh :results output :exports both sudo pip3 install hide_code sudo jupyter-nbextension install --py hide_code jupyter-nbextension enable --py hide_code jupyter-serverextension enable --py hide_code #+end_src Pour que l'export via latex fonctionne: #+begin_src shell :results output :exports both sudo apt-get install wkhtmltopdf sudo apt-get install texlive-xetex #+end_src Pour avoir R: #+begin_src shell :results output :exports both sudo apt-get python3-rpy2 #+end_src Pour avoir le [[https://github.com/brospars/nb-git][git push/pull dans les notebooks]]: #+begin_src shell :results output :exports both jupyter nbextension install https://raw.githubusercontent.com/brospars/nb-git/master/nb-git.js jupyter nbextension enable nb-git #+end_src Autres extensions (code-folding): https://stackoverflow.com/questions/33159518/collapse-cell-in-jupyter-notebook #+begin_src shell :results output :exports both pip3 install jupyter_contrib_nbextensions # jupyter contrib nbextension install --user # not done yet #+end_src https://stackoverflow.com/questions/33159518/collapse-cell-in-jupyter-notebook (collapsible headings) Pour avoir le kernel R (from https://irkernel.github.io/installation/): #+begin_src R :results output graphics :file (org-babel-temp-file "figure" ".png") :exports both :width 600 :height 400 :session *R* install.packages(c('repr', 'IRdisplay', 'evaluate', 'crayon', 'pbdZMQ', 'devtools', 'uuid', 'digest')) devtools::install_github('IRkernel/IRkernel') # Don’t forget step 2/2! IRkernel::installspec() #+end_src *** Export http://markus-beuckelmann.de/blog/customizing-nbconvert-pdf.html https://nbconvert.readthedocs.io/en/latest/ #+begin_src sh :results output :exports both ipython3 nbconvert --to pdf Untitled.ipynb #+end_src *** Pour aller plus loin - https://www.dataquest.io/blog/jupyter-notebook-tips-tricks-shortcuts/ * C028AL-W2-S0 (\approx 4:00); Le document computationnel ** Le document computationnel *La vitrine et l'envers du décor* #+BEGIN_EXPORT html #+END_EXPORT Note: Bonjour à tous, Si comme moi et que vous êtes assez mal organisés, cette petite bande dessinée doit vous parler. Nous l'avons intitulée la vitrine et l'envers du décors mais nous aurions aussi bien pu la baptiser "La Théorie et la Pratique". L'apparence que nous donnons en tant qu'expert de notre domaine, en particulier lorsque nous communiquons avec des collègues, c'est d'avoir une organisation impeccable, garante de la qualité de nos travaux. Mais en pratique, nous sommes souvient bien moins organisés que ce que aimerions être. Si vous êtes comme moi, vous avez probablement eu envie de faire en sorte que cela change. Dans ce module, nous allons voir ensemble ce qu'est un document computationnel et comment en réaliser un. C'est un terme un peu barbare mais il nous a semblé que c'était celui qui décrivait le mieux ce type de document qui permet d'améliorer la traçabilité d'un calcul. ** Module 2. La vitrine et l'envers du décor : le document computationnel 1. Exemples récents d'études assez discutées 2. Pourquoi est-ce difficile ? 3. Le document computationnel : principe 4. Prise en main de l'outil
Au choix : - Jupyter - Rstudio - OrgMode 5. Travailler avec les autres 6. Analyse comparée des différents outils Note: Pour vous convaincre de l'importance de cette traçabilité, je vais commencer par vous présenter quelques exemples récents de travaux dont les résultats ont été particulièrement controversés et discutés. Ils illustrent à quel point la capacité à pouvoir inspecter les méthodes utilisées pour produire tel ou tel résultat est essentielle. Comme nous le verrons, la plupart des problèmes rencontrés sont liées au calcul, qu'il s'agisse d'erreurs de programmations, de transformations de données peu rigoureuses, ou bien de procédures statistiques discutables. Une fois les origines de tous ces problèmes identifiées, je vous présenterai rapidement quelles bonnes pratiques mettre en oeuvre afin de les éviter. En particulier, je vous expliquerai ce que c'est que ce fameux document computationnel: un document qui permet de présenter agréablement des résultats à d'autres (ce que j'appelle la vitrine) mais aussi d'accéder à l'ensemble des calculs sous-jacents (ce que j'appelle l'envers du décor). Il existe plusieurs formats de tels documents et nous vous proposons trois environnements permettant d'en produire facilement. Ces trois environnements se distinguent par le niveau de technicité nécessaire à leur mise en oeuvre. À vous de choisir celui qui vous convient le mieux quitte à en essayer un autre plus tard. Jupyter, le premier, a été intégré au MOOC et au gitlab et ne nécessite donc aucune installation de votre part. C'est donc le plus simple à mettre en oeuvre. L'ensemble des données et des calculs sera hébergé sur nos serveurs, mais vous pourrez y accéder et les récupérer sur votre propre ordinateur à tout moment via le gitlab si vous le souhaitez. Jupyter vous permettra de gérer des notebooks et d'utiliser le langage python3 ou bien le langage R. Rstudio, le second, est un environnement de développement spécifique au langage R. Il vous faudra l'installer sur votre machine et synchroniser vos productions avec le gitlab. C'est un logiciel très bien maintenu, qui fonctionne aussi bien sous linux et mac que sous windows et son installation ne devrait pas poser de difficulté particulière. Si vous êtes déjà familier avec le langage R, c'est l'option que je vous recommande. L'avantage de cette approche est que vous aurez à la fin du MOOC sur votre machine un environnement de travail directement prêt à l'emploi. Avec Rstudio, il est également possible d'utiliser occasionnellement du code python mais si vous avez l'intention de faire principalement du python, il vaut mieux utiliser jupyter. Enfin, OrgMode, est clairement celui qui est le plus délicat à mettre en oeuvre mais c'est aussi celui que Konrad, Christophe et moi-même utilisons quotidiennement aussi bien pour gérer notre cahier de laboratoire que pour rédiger des articles ou des notes techniques. Nous nous sommes donc dit qu'il pouvait être intéressant de vous le présenter. OrgMode nécessite l'installation d'Emacs, un éditeur de texte qui révèle toute sa puissance dans un environnement linux ou mac. Il permet de combiner très efficacement différents langages et est par certains aspects moins limité que les deux précédents. Cette option est à réserver à un public averti mais le jeu en vaut la chandelle. Une fois familiarisé avec un de ces environnements, nous vous proposerons une petite séance pratique dont l'objectif sera de produire un petit document computationnel. Les dernières séquences peuvent être visionnées indépendemment et traitent de sujets un peu plus techniques, en particulier de comment utiliser de tels outils avec vos co-auteurs qui peuvent avoir leurs propres habitudes, ou de comment produire des documents avec un style bien spécifique. Nous concluons enfin ce module avec une comparaison de ces différents outils et une présentation des bénéfices d'une utilisation quotidienne. * C028AL-W2-S1 (\approx 7:30); Exemples récents d'études assez discutées ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. *Exemples récents d'études assez discutées* 2. Pourquoi est-ce difficile ? 3. Le document computationnel : principe 4. Prise en main de l'outil
Au choix : - Jupyter - Rstudio - OrgMode 5. Travailler avec les autres 6. Analyse comparée des différents outils ** Exemples récents d'études assez discutées file:assets/img/in_science_we_trust.jpg&size=cover Note: Je vous avais promis quelques exemples récents de travaux dont les résultats ont été particulièrement controversés et discutés. C'est ce que je vais vous présenter dans cette séquence. ** Économie : politiques d'austérité (1/2) *** 2010 # - /gross debt [..] exceeding 90 percent of the economy has a # significant negative effect on economic growth/ #+BEGIN_QUOTE Lorsque la dette extérieure brute atteint 60 pourcents du PIB, la croissance annuelle d'un pays diminue de deux pourcents. [..] pour des niveaux de dette extérieure dépassant 90 pourcents du PIB, la croissance annuelle est à peu près divisée par deux. -- [[https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt][Reinhart et Rogoff]]: /Growth in a Time of Debt/ #+END_QUOTE # - données non publiées mais disponibles sur demande Note: Commençons par des travaux en économie. 2007: crise des subprimes aux États-Unis. De 2008 à 2009, deux économistes prestigieux, Carmen Reinhart et Kenneth Rogoff présentent leurs travaux et annoncent que la crise financière est loin d'avoir produite toutes ses conséquences. En 2010, ils publient un article intitulé "Growth in a Time of debt" qui étudie le lien entre dette et croissance. Leurs principales conclusions sont que lorsque lorsque la dette extérieure d'un pays dépasse 90% du PIB, les conséquences sur la croissance sont dramatiques. De nombreux politiciens, journalistes et activistes s'appuient sur cet article pour soutenir la mise en place de politiques d'austérité budgétaire. ** Économie : politiques d'austérité (2/2) *** 2013 # - Herndon, Ash and Pollin: /While using RR's working spreadsheet, we # identified *coding errors*, *selective exclusion* of/ /available data, # and *unconventional* weighting of summary *statistics*./ #+BEGIN_QUOTE En utilisant leurs feuilles excel, nous avons identifié des *erreurs de programmations*, des *exclusions* de certaines données, et des pondérations *statistiques non conventionnelles*.
-- Herndon, Ash et Pollin
#+END_QUOTE # #+BEGIN_EXPORT html #
# #+END_EXPORT # - Wray: /combining data across centuries, exchange rate regimes, # public and private/ /debt, and debt denominated in foreign currency # as well as domestic currency/ #+BEGIN_QUOTE R&R combinent des données de siècles différents, des régimes de changes différents, des dettes privées et publiques, et des dettes exprimées en monnaies étrangères et nationales.
-- Wray
#+END_QUOTE Note: Ces seuils de 90% ainsi que l'ampleur des conséquences sont très discutés, d'autant plus que certains chercheurs échouent à obtenir des résultats similaires en utilisant les données disponibles publiquement. Ils demandent donc à Reinhart et Rogoff l'ensemble des données et des feuilles de calculs utilisées dans l'étude et ces derniers finissent par leur fournir. Dans ces feuilles, des erreurs de calcul évidentes apparaissent rapidement ainsi que des traitement de données assez douteux (exclusion de données, pondérations suspectes, etc.). Reinhart et Rogoff répondent point par point en expliquant que ces quelques erreurs ne changent rien au résultat final, que leur façon de calculer les statistiques sont tout à fait standard. En fait, une fois les détails révélés, pour beaucoup de chercheurs ces calculs n'ont pas beaucoup de sens, les valeurs utilisées sont très discutables, et il est malhonnête d'utiliser ces travaux pour justifier une politique d'austérité budgétaire. Mais le mal est fait. Pendant plus de trois ans, l'austérité n'est pas présentée comme un choix mais comme une nécessité. Et quand bien même l'article original est considéré comme non pertinent par les économistes, ces idées ont fait leur chemin et sont difficiles à détrôner. Au delà du caractère idéologique de ce genre de travaux, une des raisons pour lesquelles ce débat a mis autant de temps à avoir lieu est lié à la non publication de l'ensemble des procédures de calcul et des données utilisées, pratique courante en économie. Sous les feux de la rampe, les auteurs ont bien été forcés de mettre à disposition ce qui sous-tendait leur travaux mais sans pression médiatique particulière, en général, rien ne se passe... ** IRM fonctionnelle # file:assets/img/Irmf.jpg&size=cover - 2010 : [[https://www.researchgate.net/publication/255651552_Neural_correlates_of_interspecies_perspective_taking_in_the_post-mortem_Atlantic_Salmon_an_argument_for_multiple_comparisons_correction][Bennett et al. et le saumon mort]] \smiley - 2016 : [[http://www.pnas.org/content/113/28/7900.abstract][Eklund, Nichols, and Knutsson]]. [[http://www.sciencealert.com/a-bug-in-fmri-software-could-invalidate-decades-of-brain-research-scientists-discover][A bug in fmri software could invalidate 15 years of brain research]] (/40 000 articles/) - 2016 : Mais [[https://www.cogneurosociety.org/debunking-the-myth-that-fmri-studies-are-invalid/][c'est plus subtil que ça]]. [[http://blogs.warwick.ac.uk/nichols/entry/bibliometrics_of_cluster/][Nichols]]. /\approx 3 600 études concernées/

Des méthodes statistiques à améliorer mais pas de remise en cause fondamentale.

#+BEGIN_EXPORT html ![Irmf](assets/img/Researcher-test.jpg) #+END_EXPORT Note: Continuons avec un autre exemple: l'imagerie cérébrale, qui permet d'observer l'activité du cerveau d'un individu lorsqu'il effectue une tâche cognitive et ainsi de mieux comprendre la structure et le fonctionnement du cerveau. L'IRM fonctionnelle est l'une de ces techniques et mesure de très faibles variations locales du taux d'oxygénation du sang dans le cerveau. En 2010, Craig Bennett et ses encadrants ont une idée saugrenue. Ils placent un saumon mort dans un appareil d'IRM et lui présentent des images. Étonnamment, ils observent des signes d'activité cérébrale, ce qui est pour le moins surprenant puisque le saumon est bel et bien mort. Aussi drôle que cela puisse paraître, Bennett et ses encadrants savent très bien ce qu'ils font. Les données brutes obtenues lors d'une IRM sont très bruitées et toute une série de calculs et de tests statistiques sont appliqués pour transformer ces données en images intelligibles. Mais il arrive que le bruit soit trop important, que la machine soit mal calibrée, que la procédure de calcul soit inadaptée et que des signaux apparaissent fortuitement. Leur article rédigé avec un ton très humoristique fait sensation car il met le doigt sur des faiblesses méthodologiques. L'an dernier, des collègues me sachant intéressé par ces problèmes de réplication me font suivre un article récent assez alarmant. Cet article présente un problème dans les procédures statistiques utilisées dans les logiciels d'analyse d'IRMf les plus courants, ce qui remet potentiellement en cause les résultats obtenus ces quinze dernières années. Étant donnée l'ampleur de l'erreur, les auteurs concluent que 40,000 articles pourraient être concernés. De plus, les données étant très volumineuses dans ce domaine, elles ne sont pas archivées et il ne sera pas possible de simplement les réanalyser. L'ensemble des expériences seraient à refaire... En fait, suite aux retours qui leurs sont faits, les auteurs revoient rapidement à la baisse leurs estimations assez alarmistes. Au final, le problème méthodologique et la capacité à vérifier les études suite à des erreurs de calcul reste entier même s'il ne remet pas pour autant en cause l'ensemble des résultats obtenus ces dernières années. ** Les fausses structures de protéines #+BEGIN_EXPORT html #+END_EXPORT *Geoffrey Chang* : étude de la structure de protéines présentes dans des bactéries résistant aux antibiotiques. MsbA de Escherichia Coli (Science, 2001), Vibrio cholera (Mol. Biology, 2003), Salmonella typhimurium (Science, 2005) *2006* : Incohérences, alertes, puis 5 rétractations #+BEGIN_QUOTE a homemade data-analysis program had flipped two columns of data, inverting the electron-density map from which his team had derived the protein structure. -- [[https://people.ligo-wa.caltech.edu/~michael.landry/calibration/S5/getsignright.pdf][une "erreur de programmation"]] #+END_QUOTE Note: Un dernier exemple, cette fois-ci en cristallographie. Geoffray Chang est un chercheur à la trajectoire fulgurante, récompensé par de nombreux prix. Son équipe, basée au Scripps Institute à l'Université de Californie San Diego, a publié une série d'articles dans des revues prestigieuses et détaillant la structure de certaines protéines présentes dans les membranes de cellules. Ces protéines jouent un rôle essentiel dans la résistance de ces bactéries à certains médicaments et connaître leur structure est une étape importante dans la compréhension de leur fonctionnement. Hélas, peu de temps après, d'autres équipes de chercheurs qui étudient des protéines très similaires rapportent des structures anormalement différentes de celles publiées par Chang et son équipe. En lisant ces travaux Chang, horrifié, remonte vite à la source du problème. Un des codes d'analyse aurait inversé deux colonnes de données et ainsi inversé la répartition de la densité d'électrons à partir de laquelle la structure finale de la protéine est calculée. D'après Chang, ce code aurait été hérité d'un autre laboratoire et s'était également répandu depuis dans d'autres équipes. Même si toute l'acquisition des données avait été faite soigneusement, ce n'était pas le cas de l'analyse et ce petit grain de sable a conduit à la rétractation immédiate de 5 articles par Chang et son équipe. Ces publications ont eu un impact énorme sur la communauté, à tel point que plusieurs années après la rétractation, les résultats contradictoires avec ceux de Chang paraissaient suspects avaient du mal à être publiés. ** Crise de foi ? #+BEGIN_EXPORT html #+END_EXPORT - [[http://www.nature.com/nrd/journal/v10/n9/full/nrd3439-c1.html?foxtrotcallback=true][Oncologie]] : "/plus de la moitié des études publiées, même dans des journaux prestigieux, ne/ /peuvent être reproduites en laboratoire industriels/" - [[http://theconversation.com/we-found-only-one-third-of-published-psychology-research-is-reliable-now-what-46596][Psychologie]] : "réplication d'une centaine d'articles /seulement un tiers de résultats cohérents/" *Lanceurs d'alerte* ou *institutions malades* ? *** La remise en cause fait partie du processus scientifique *** Tout comme la rigueur et la transparence... Note: Il n'y a à ce jour pas un domaine des science qui ne soit épargné par ces difficultés à reproduire les travaux publiés. En oncologie, un article récemment publié rapporte que plus de la moitié des études publiées ne peuvent être reproduites en laboratoire industriel, et ce même si les études sont publiées dans des journaux prestigieux. En psychologie, les capacités à reproduire les résultats publiés sont également très basses. Le problème est méthodologique mais également certainement sociologique, lié à une pression productiviste trop importante. Mais attention aussi à ne pas donner non plus trop d'importance aux signaux d'alertes que nous venons de voir... Le problème est compliqué mais il faut garder à l'esprit que la remise en cause fait partie du processus scientifique. Il n'est donc pas surprenant que de telles difficultés de reproduction de travaux scientifiques soit présentes. Cependant, deux autres caractéristiques essentielles du processus scientifique sont la rigueur et la transparence et il est clair que dans l'ensemble des cas que nous venons de voir il manquait souvent l'un et l'autre... * C028AL-W2-S2 (\approx 11:30); Pourquoi est-ce difficile ? ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. Exemples récents d'études assez discutées 2. *Pourquoi est-ce difficile ?* 3. Le document computationnel : principe 4. Prise en main de l'outil
Au choix : - Jupyter - Rstudio - OrgMode 5. Travailler avec les autres 6. Analyse comparée des différents outils ** Pourquoi est-ce difficile ? file:assets/img/box-she-s-told-not-to-open-in-it-the-gods-had-placed-all-the-evils-9vbl9q-clipart.jpg&size=contain Note: Comme nous l'avons vu, reproduire les travaux de recherche, même publiés dans des revues prestigieuses est souvent assez difficile. Dans cette séquence, nous allons identifier les difficultés les plus communes. ** 1) Le manque d'informations Expliciter : + *Sources* et *données*
/Données non disponibles = résultats difficiles à vérifier/

+ *Choix*
/Choix non expliqués = choix suspicieux/

*** Le cahier de laboratoire peut vous aider Note: La première source de difficultés rencontrées lors de tentatives de reproduction est tout simplement le manque d'informations. Si on ne prend pas soin d'expliciter comment on a obtenu nos données et qu'on les garde secrètes, il est certain qu'il va être difficile pour une tierce personne de vérifier si elle arrive aux mêmes conclusions ou pas. # C'est étrange car mettre les données utilisées à disposition permet au # lecteur d'en évaluer la qualité (voire d'y trouver des erreurs). Sans # cette évaluation, difficile pour le lecteur de savoir quelle confiance # avoir dans les conclusions de l'article. De même expliciter les choix effectués à chacune des étapes de l'étude s'avère essentiel. Quel protocole expérimental a été choisi et pourquoi ? Quelles données ont été conservées ? Quelles données ont été soigneusement écartées et pourquoi ? Quelle procédure statistique a été utilisée et les hypothèses sous-jacentes étaient elles raisonnables ? Etc. Après tout, on doit toujours faire des choix à un moment donné. Mais ne pas expliquer ces choix, même en étant rigoureux et de bonne foi, c'est prendre le risque que les lecteurs deviennent suspicieux. D'autre part, être totalement transparent sur ces choix, c'est permettre à d'autres (ou à vous-même) de décider s'il est nécessaire de revenir dessus ou pas Pour garder trace de tous ces choix et des informations sur ces données, le cahier de laboratoire un outil essentiel. Encore faut-il ensuite mettre ces informations à disposition, mais nous reviendrons sur ce point par la suite. ** 2) L'ordinateur, [[http://theconversation.com/how-computers-broke-science-and-what-we-can-do-to-fix-it-49938][source d'erreurs]]
- *Point and click* : - *Les tableurs* : [[https://qz.com/768334/years-of-genomics-research-is-riddled-with-errors-thanks-to-a-bunch-of-botched-excel-spreadsheets/][erreurs de programmation]] et de manipulation de données - ~Membrane-Associated Ring Finger (C3HC4) 1, E3 Ubiquitin Protein Ligase~ \to ~MARCH1~ \to 2016-03-01 \to 1456786800 - ~2310009E13~ \to 2.31E+19 - *Pile logicielle complexe* - *Bug* : /Programmer, c'est dur !/ Note: La deuxième source de difficultés rencontrées lors de tentatives de reproduction de travaux est tout simplement les erreurs induites par l'utilisation effrénée des ordinateurs. Comme toute innovation technologique, les ordinateurs nous permettent d'aller plus vite, plus loin mais aussi de faire des erreurs plus facilement et plus rapidement... Au premier plan des sources d'erreurs, ces logiciels intuitifs où l'interaction se fait à la souris et qui ne permettent pas d'expliciter ce qui est calculé et à partir de quoi. Leur simplicité d'utilisation incite à les utiliser pour tout, même pour ce pour quoi ça n'est pas vraiment prévu. Il est par exemple très difficile de comprendre la logique du calcul ayant lieu dans une feuille excel pleine de macros. Bien sûr, il est possible de gérer des stocks et la comptabilité d'une entreprise avec un tableur, mais ceux qui ont déjà eu à faire à ce genre d'abominations savent qu'un ERP permet d'éviter bien des soucis. Et bien de la même façon, un tableur n'est pas le bon outil pour faire des statistiques ou du traitement de données ! Tenez, quelques exemples d'anecdotes effroyables liées à l'utilisation d'un tableur. En génomique, il est bien pratique de donner des petits noms aux gènes tels que celui-ci. Celui-ci, c'est MARCH1. Seulement pas mal de tableurs croient bien faire en l'interprétant comme une date et par effet de bord comme le nombre de secondes écoulées depuis le 1er janvier 1970... L'identifiant de gène 231 000 9E13 se retrouve lui aussi fréquemment convertit en nombre. Alors bien sûr, il n'y a peut-être qu'une vingtaine de gènes concernés par ce genre de problème sur les 30,000 du génome humain, mais c'est quand même assez désagréable. De manière générale, il est courant de se reposer sur une pile logicielle complexe. Complexe et souvent mal maîtrisée. Combien d'études reposent ainsi sur des logiciels propriétaires, sortes de boites noires dont on ne maîtrise pas le contenu et qui appliquent aveuglement des procédures de calculs et de transformations de données? # - l'utilisation de telle ou telle méthode plutôt qu'une autre est # souvent discutable Alors, je ne suis pas en train de dire qu'il faut tout reprogrammer soi même. Ce n'est bien sûr par la meilleure façon d'échapper aux bugs. Dans les cas de l'étude Reinhart et Rogoff ou des fausses structures de protéines de Chang, les erreurs venaient de programmes maisons. Mais il me semble essentiel d'être en mesure de déterminer dans son analyse si chacune des briques est digne de confiance ou pas. Et si l'un des composants, par sa nature, l'interdit, il faut sérieusement songer à le remplacer. ** L'informatique, seule responsable ?
*Le manque de rigueur et d'organisation* - Pas de backup - Pas d'historique - Pas de contrôle qualité Note: Enfin, la dernière cause méthodologique de non-reproductibilité et source d'erreurs est certainement le mangue de rigueur et d'organisation. Même si le stockage ne coûte plus rien de nos jours, la sauvegarde des données est souvent mal assurée et il est courant d'en perdre suite à une mauvaise manipulation, ou bien à la suppression de son compte informatique lors du passage d'une institution à une autre. En l'absence de mécanisme de gestion de version, il est courant de remplacer par inadvertance d'anciennes données par de nouvelles et de ne plus arriver à accéder à d'anciennes observations. Dans un certain nombre de domaines, l'utilisation de plans d'expériences randomisés ou de pré-études (study pre-registration), n'est absolument pas systématique. De même les bonnes pratiques de développement logiciel comme la revue de code ou l'intégration continue sont encore rarement appliqués au logiciels utilisés dans la recherche. ** Une dimension culturelle et sociale #+BEGIN_QUOTE
Article = version _simplifiée_ de la procédure
#+END_QUOTE
#+BEGIN_QUOTE
*Tracer* toutes ces informations et les *rendre disponibles* = investissement conséquent
#+END_QUOTE
Si personne n'exige/n'inspecte ces informations, à quoi bon s'embêter ? Note: Enfin, il serait naïf de ne pas évoquer la dimension culturelle et sociale du problème. Un article est une version simplifiée et intelligible des résultats. Certains diraient même la publicité... Une description de haut niveau est essentielle car elle permet de prendre du recul mais elle est devenue la norme alors que la technicité de la recherche actuelle est telle qu'il est clairement impossible de donner dans un document de 8 à 10 pages toutes les informations permettant de refaire les expériences et les analyses. - La description du protocole expérimental est souvent succincte - Les données sont généralement bien trop nombreuses pour être données in extenso et sont résumées à travers quelques courbes. - Les traitements statistiques appliqués pour parvenir à ces courbes ne sont décrits que rapidement. Alors, bien sûr il est possible de tracer toutes ces informations et de les mettre à disposition. À ceci près que cela demande du temps, voire beaucoup de temps si on ne dispose pas des bons outils. # - sans compter que mettre à disposition toutes ces informations, alors # qu'on a soi-même peiné à les obtenir, c'est permettre à d'autres de # récupérer les fruits de notre travail sans efforts. Mais si personne n'exige ces informations, à quoi bon s'embêter ? ** Tout rendre public ?
- Les /faiblesses/ deviendraient évidentes - Quelqu'un pourrait trouver une /erreur/ - Quelqu'un pourrait en [[http://www.nature.com/news/the-top-100-papers-1.16224][tirer avantage à ma place]] - /Les données peuvent être sensibles/ # sécurité, machine learning pour la police #+BEGIN_EXPORT html
#### Donnons nous les moyens que tout soit inspectable à la demande #+END_EXPORT Note: Mais donner accès, mettre à disposition, cela veut dire tout rendre public ? N'est-ce pas un peu radical ? Et risqué ? Démontons ensemble quelques idées reçues. Si je donne accès à tout ce que j'ai fait, il deviendra alors évident que ce que j'ai fait n'est pas aussi parfait que ce que je prétends, que c'est un peu sale et pas toujours très rigoureux, que j'ai sélectionné les résultats que je présente. - C'est sûr. En même temps, c'est la réalité et vous auriez tort de croire que vous êtes le seul dans cette situation. Si ça se trouve, vous travaillez mieux que les autres et dans un domaine où la réputation est essentielle, vous avez probablement plutôt intérêt à le montrer. Pire, si vous le cachez, cela finira par paraître suspicieux. Vous me direz qu'en révélant tout, je prend le risque que quelqu'un trouve une erreur et de passer pour un imbécile. - C'est certain, mais tout le monde fait des erreurs, même les plus grands. Et en ce qui me concerne, je préfère que quelqu'un trouve une erreur et m'aide à la corriger afin que mes travaux deviennent corrects. Oui, mais quelqu'un pourrait tirer parti, réanalyser ces données que j'ai eu tant de mal à obtenir, ou simplement utiliser ce code que j'ai eu tant de mal à écrire et faire trois ou quatre papiers là où je n'ai eu le temps d'en faire qu'un. - Alors d'abord, si quelqu'un réutilise votre travail, il se doit de le citer correctement et de vous rendre le crédit qui vous est dû. Ensuite les articles les plus cités de tous les temps sont des articles présentant des contributions méthodologiques ou du logiciel qui sont devenus essentiels dans un domaine. Une petite parenthèse : ceux d'entre vous qui connaissent github, savent que cette plate-forme est à mi-chemin entre la plate-forme de développement logiciel et le réseau social. Les contributions d'un développeur à différents projets sont visibles ainsi que la fréquence de ses contributions, ce qui permet à un jeune développeur de se faire une carte de visite infalsifiable et ultra-visible. Montrer ce que l'on fait est une façon efficace d'atteindre une certaine forme de reconnaissance par la communauté. Mettre ses travaux à disposition de tous est probablement la meilleure façon de démontrer sa propriété intellectuelle. Enfin, il est possible que les données soient sensibles et ne puissent être divulguées sans prendre le risque de causer du tort à des gens. Par exemple, s'il s'agit de données médicales, de données judiciaires, d'informations sur des enfants ou sur des intentions de vote, etc. - Dans ce type de situation où les travaux ont une dimension éthique, il convient de définir quelles personnes peuvent avoir accès aux informations pour les vérifier ou les réutiliser. Ensuite, il existe des techniques cryptographiques assez faciles d'accès permettant de s'assurer que seulement les personnes habilitées peuvent accéder aux données. Dans tous les cas, même si au final ces informations sont semi-publiques, il est essentiel de se donner les moyens de permettre à autrui d'inspecter ce que nous avons fait. ** Outils à éviter et alternatives
- *Outils, formats, et services propriétaires* 1. excel, word, evernote - markdown, orgmode, csv, hdf5, ... 2. SAS, Minitab, matlab, mathematica, ... - scilab, R, python, ... 3. dropbox, cahiers de labo en ligne propriétaires, ... - framadrop, gitlab/github, ... - *Outils "intuitifs" * - tableurs, interfaces graphiques, exploration interactive - apprendre à se contrôler... ☺ - R, python, ... Note: Et pour permettre l'inspection, il faut utiliser les bons outils Cela commence par banir autant que possible les logiciels et les formats propriétaires. Bien sûr, ces outils sont bien faits et vous y êtes habitués mais on en est également captif et les entreprises qui les développement n'offrent aucune garantie sur le long terme. Je suis sûr que ces mises à jours automatiques vous agacent vous aussi. :) L'expérience montre qu'il est hélas très courant de perdre des données et des informations lors de ces mises à jour. Alors, soyons honnête, l'utilisation de logiciel libre ne vous protège absolument pas de ce genre de mauvaises surprises. Mais comme vous avez accès librement à l'ensemble des versions, les chances d'arriver à récupérer vos données sont quand même bien plus élevées. De même l'adoption de formats textes simples et ouverts augmente vos chances d'arriver à les relire avec d'autres logiciels. En ce qui me concerne, à chaque fois que j'ai utilisé un format binaire ou pas bien ouvert, j'ai fini par perdre des données. Cela fait donc 10 ans que je n'utilise plus que des formats texte ou des standards binaires ouverts et le problème ne s'est plus jamais posé, et ce malgré les mises à jours logicielles très régulières de ma machine. Donc règle numéro 1 : utiliser autant que possible du format texte (markdown, orgmode pour vos notes, csv pour vos données). Règle numéro 2 : utiliser autant que possible les logiciels et les langages de programmation libres comme R ou python. Et Règle numéro 3 : éviter de stocker vos données chez un hébergeur dont vous pourriez être captif. En effet, les services gratuits (ou pas) et très intégrés sont tentants mais correspondent à un business plan particulier qui peut se révéler incompatible avec vos besoins futurs, ne pas être pérenne et ne vous donne pas forcément les garanties de confidentialité que vous souhaiteriez. Enfin, attention aux tableurs et outils graphiques qui peuvent vous donner au premier abord l'impression d'une meilleur efficacité et productivité mais qui sur le long terme ne vous permettent pas d'atteindre la traçabilité et l'inspectabilité que vous souhaiteriez. C'est plus difficile, en particulier au début, mais en utilisant des langages comme R ou python, passé la première marche, on gagne rapidement en puissance et en efficacité. ** Conséquences :noexport: - Des *erreurs*... - Des *difficultés* certaines à *réutiliser* le travail des autres, voire son propre travail - Un *doute* dommageable pour tout le monde (auteur, détracteurs, lecteur, décideur...)
Note: C'est pour toutes ces raisons que les résultats de recherche contiennent parfois des erreurs et sont si difficile à répliquer et à réutiliser, même au sein d'une même équipe. Les doutes que cela engendre sont dommageable pour tout le monde. Lorsque l'on propose un résultat, il n'est pas agréable d'être soupçonné de fraude ou d'incompétence. En même temps, les détracteurs d'un résultat apparaissent comme de simples aigris ou au contraire comme des lanceurs d'alertes selon le contexte alors qu'il est normal de questionner un résultat et d'avoir un débat apaisé et rationnel à son sujet. Face à ces problèmes, il me semble que la meilleur attitude à avoir est celle de la transparence : Expliciter augmente les chances de trouver les erreurs et de les éliminer. C'est d'ailleurs une demande de plus en plus pressante de la part de la société civile afin d'éviter les dérives et d'améliorer l'efficacité de nos travaux. ** Changement de paradigme 1. Manque d'information, problème d'accès aux données 2. Erreurs de calcul 3. Manque de rigueur scientifique et technique #+BEGIN_EXPORT html #+END_EXPORT *** Expliciter augmente les chances de trouver les erreurs et de les éliminer # Demande de *traçabilité* de plus en plus pressante de la société, des # institutions, de l'Europe, ... Note: Nous avons vu que la première cause d'échec de reproduction de résultats scientifiques est tout simplement le manque d'information, la non disponibilité des données ou des procédures appliquées. Cela ne signifie pas que le résultat soit faux mais cela empêche de le vérifier et de s'appuyer dessus. La seconde cause d'échec est tout simplement l'erreur de calcul qui peut se glisser n'importe où. De manière générale, le manque de rigueur scientifique et technique est souvent à l'origine de ces deux problèmes. Il me semble que la meilleur attitude à avoir est celle de la transparence : Expliciter augmente les chances de trouver les erreurs et de les éliminer. C'est pour cela que nous assistons ces dernières années à un changement de paradigme de recherche et que l'on exige un accès à l'ensemble des données et des procédures de calcul. C'est d'ailleurs une demande de plus en plus pressante de la part de la société civile (en particulier le Conseil Européen) afin d'éviter les dérives et d'améliorer l'efficacité de nos travaux. * C028AL-W2-S3 (\approx 7:40); Le document computationnel : principe ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. Exemples récents d'études assez discutées 2. Pourquoi est-ce difficile ? 3. *Le document computationnel : principe* 4. Prise en main de l'outil
Au choix : - Jupyter - Rstudio - OrgMode 5. Travailler avec les autres 6. Analyse comparée des différents outils ** Le document computationnel :
principe file:assets/img/iceberg.jpg&size=contain Note: Dans cette séquence, je vais vous présenter ce qu'est un document computationnel ainsi que les principes généraux que nous retrouverons dans chacun des trois environnements dont je vous ai précédemment parlé. L'intérêt de ce type de document est de permettre une transparence la plus complète possible. ** La science moderne
#+BEGIN_EXPORT html #+END_EXPORT Note: # Data \to visualization/analysis \to article Si une partie de l'activité scientifique nécessite des mesures sur le terrain ou derrière une paillasse, la majeure partie se passe maintenant derrière un ordinateur, les données provenant de machines spécifiques : je pense par exemple à un accélérateur de particules, des séquenceurs d'ADN, un téléscope, un réseau de capteur ou bien sûr des simulations numériques s'exécutant sur des supercalculateurs. Une fois ces données obtenues, elles sont transformées pour être analysées, visualisées afin de mieux en comprendre la structure. Il est courant de partager ces visualisations avec des collègues, d'avoir un certain nombre d'itérations, de passer d'une vue à une autre jusqu'à trouver celle qui explique le mieux les choses. On utilise d'ailleurs souvent une multitude de logiciels spécifiques pour obtenir ces visualisations. Il arrive souvent qu'on soit déçu par les résultats, qu'on n'y comprenne rien ou qu'on se rende compte que les données ne sont pas intéressantes et qu'il faut se poser la poser la question sous un angle différent. Dans ce cas, retour à la case départ : acquisition de données, visualisations, statistiques, nombreux échanges avec les collègues... Puis ça y est, on trouve enfin quelque chose d'intéressant. On prend alors nos plus belles figures, on y ajoute les explications qui sont finalement les bonnes, on tente de rendre tout cela intéressant et on envoie l'ensemble à une conférence ou un journal. Hélas, dans un pdf de 8 pages, le lecteur trouvera une jolie histoire, des figures convaincantes mais n'aura aucune idée du réel travail effectué. L'article, c'est la partie émergée de l'iceberg et il n'y a alors plus aucun moyen de revenir sur les nombreuses tentatives et échecs, ni sur les calculs et les données derrière chacune de ces figures. La recherche reproductible, c'est permettre de pouvoir naviguer dans les deux sens et de combler le fossé séparant l'auteur du lecteur. ** Objectifs méthodologiques
Garder trace afin de : - *Inspecter* : justifier/comprendre - *Refaire* : vérifier/corriger/réutiliser Note: Notre objectif est donc d'avoir un outil nous permettant : - d'une part d'inspecter toute cette démarche, afin que l'auteur puisse justifier pourquoi tel ou tel code est utilisé et que le lecteur puisse comprendre ce qui a été fait; - et d'autre part de refaire le calcul et l'analyse le plus simplement possible, ce qui est essentiel 1. pour permettre aux lecteurs de vérifier que ces calculs sont corrects, 2. pour permettre éventuellement de corriger des erreurs s'il y en a 3. et enfin pour permettre à d'autres de réutiliser ces travaux, soit sur un jeu de données différent, soit en réutilisant une partie de la procédure d'analyse dans un autre contexte. ** La vitrine... et l'envers du décor #+BEGIN_EXPORT html #+END_EXPORT Note: Voici la partie émergée du document computationnel. Au premier abord, il s'agit d'un document tout à fait banal avec un titre, du texte, éventuellement un petit morceau de code illustrant une procédure de calcul, des résultats numériques, des formules de maths, des figures, etc. Bref, un article classique au format pdf ou html. Voici maintenant ce qui se cache derrière ce document : ici, un notebook Jupyter tel que nous pouvons le voir dans un navigateur web. C'est un document dynamique constitué de différentes parties sur lesquelles on peut interagir. Tout d'abord du texte au format markdown : ce sont les zones de texte que j'ai surlignées en orange. Le formattage est assez simple, on peut assez facilement y inclure des liens hypertextes ou des formules mathématiques. Entre ces zones de texte, on trouve des zones de code, que j'ai surlignées en bleu. Ici il s'agit de fragments de code python relativement simples. Dans cet environnement, il est possible d'éditer directement ces fragments de code et les exécuter. En fait, un notebook a en interne une console python ouverte et lorsque l'on demande l'exécution d'un fragment de code, le code est directement envoyé dans la console et le résultat est automatiquement récupéré. Le résultat de chacun de ces différents codes est stocké juste en dessous dans les zones que j'ai surlignées en jaune. Puisque cette console reste "vivante" tout au long du document, les résultats calculés dans un bloc sont visibles dans le bloc suivant, ce qui encourage à ne pas écrire de longs blocs de code infâmes, mais au contraire à écrire de petits fragments, à calculer les choses petit à petit, tout en expliquant dans les zones de texte (en orange) comment les différents fragments de code (en bleu) s'enchaînent et éventuellement pourquoi, en fonction de ce que l'on vient de calculer (en jaune), on décide d'appliquer tel nouveau fragment. Une fois satisfait avec les calculs, on aime en général bien créer un document classique en exportant vers du pdf ou du html. Chaque zone (texte, code, résultat) est convertie et assemblée en un seul document markdown qui est à son tour transformé vers le format désiré avec un outil comme pandoc. Bien sûr, dans le document final, on ne souhaite pas forcément rendre tous les fragments de codes et tous les résultats visibles. C'est la raison pour laquelle pour chacune de ces zones, il est possible de spécifier si l'on souhaite la cacher ou pas. Enfin, si les résultats intermédiaires sont stockés automatiquement dans le notebook, l'environnement permet de ré-exécuter très simplement l'ensemble du code du notebook et de mettre à jour les résultats. C'est donc à vous de décider, selon le contexte, si vous souhaitez partager le document final, qui est souvent plus compact, ou le document computationnel qui va permettre une inspection complète et une réutilisation. ** Les différents outils 1. Jupyter 2. Rstudio/knitR 3. Org mode # | Principes | Différences | # |---------------------------------+--------------------| # | • Explications, code, resultats | • Syntaxe | # | • Session | • Interopérabilité | # | • Export | • Contrôle export |
*Principes identiques* *Différences*
  • *1 seul document* :
    explications, code, résultats
  • Session
  • Export
  • Syntaxe
    .
  • Interopérabilité des langages
  • Contrôle export
Note: Les trois environnements les plus matures permettant de créer de tels documents sont Jupyter, que vous venez de voir, Rstudio/knitr, et Org-mode. Ces trois environnements se distinguent par le niveau de technicité nécessaire à leur mise en oeuvre. Je ferai une petite démo de chacun de ces trois environnements dans les séquences suivantes. À l'issue de ces démonstrations, vous pourrez choisir lequel vous convient le mieux. Vous verrez que le principe reste le même dans les trois environnements : - Tout d'abord, avoir un seul document comprenant un entrelacs d'explications au format markdown, de code exécutable simplement, et les résultats de ces exécutions. Cette organisation permet l'inspection et la réexécution que nous nous étions fixés comme objectifs. - En interne, une console python ou R est active et assure une persistance des variables d'un fragment de code à l'autre. C'est la notion de session sur laquelle nous reviendrons pendant les démonstrations. - Enfin, il est possible d'exporter le document computationnel vers un format plus traditionnel éventuellement en masquant certaines parties. Les différences entre ces différents environnements sont relativement mineures : - Il y a quelques différences de syntaxe. Jupyter et Rstudio utilisent du markdown alors que Org mode utilise le format org qui est légèrement différent mais tout aussi lisible. La façon d'indiquer les zones de code et les résultats est également un peu différente mais c'est sans grande importance une fois dans l'environnement correspondant. - Plus important, peut-être l'interopérabilité entre différents langages. Jupyter vous permet de faire du python, du R, du ruby ou bien du julia mais pas vraiment d'utiliser plusieurs langages dans un même notebook. /Enfin/, c'est possible mais ça demande un peu de travail. Rstudio est conçu spécifiquement autour du langage R. Même s'il est possible d'utiliser du code python, vous verrez que ça n'est pas aussi convivial que pour R. Enfin, Org-mode permet une interaction entre les différents langages relativement naturelle mais comme je le disais, la courbe d'apprentissage est un peu plus raide. - Enfin, ces outils diffèrent par le contrôle offert en terme de mise en page lors de l'export. Jupyter et Rstudio se reposent sur markdown et donc sur pandoc. Le style par défaut est très bien, surtout si on souhaite produire du HTML. Mais si on doit produire un document PDF respectant un style particulier, ça peut être peu compliqué de demander à pandoc d'appliquer ce style. Org-mode ne fait à peu près rien pour vous de ce point de vue là. Il vous faudra donc de toutes façons configurer le style de votre export. Ceci dit, un des points que j'apprécie particulièrement lorsque je prépare un article en latex avec org-mode, c'est la capacité à écrire directement du LaTeX qui sera passé tel quel lors de l'export, ce qui me permet de faire exactement ce que je souhaite. Bien. Vous savez tout. Alors maintenant, Démo ! * C028AL-W2-S4-A; Prise en main de l'outil (Jupyter) ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. Exemples récents d'études assez discutées 2. Pourquoi est-ce difficile ? 3. Le document computationnel : principe 4. *Prise en main de l'outil*
Au choix : - *Jupyter* - Rstudio - OrgMode 5. Travailler avec les autres 6. Analyse comparée des différents outils ** Prise en main de l'outil :
Jupyter #+BEGIN_EXPORT html

#+END_EXPORT ** Lancement - Ouverture d'un document - Description rapide - Sauvegarde - Aide ** Exécution des blocs - Exécution et récupération des résultats - Ajout d'un bloc - Attention à l'ordre - Notion de session - Incohérences possibles - Tout réexécuter depuis le début ** Raccourcis clavier,
auto-complétion,
et Ipython magic - Raccourcis clavier == - Complétion python (exemple de numpy) - =%matplotlib=, =%lsmagic= # =%run=, =%load=, =%load_ext= ** Utiliser d'autres langages - Exemple pour R : - =%load_ext rpy2.ipython= - =%%R %%sh %%perl= - Interaction entre =R= et =python= possible - mais fragile... ** Production et partage
du document final - Résultats stockés dans le document - $\to$ visibles dans gitlab - =git pull/push= - Export HTML/PDF classique ** Préparer un document # Contrôler la visibilité du code et des résultats - Hide-code plugin - =%%latex= et =%%html= - [[http://nbconvert.readthedocs.io/en/latest/external_exporters.html][Personnaliser les /exporters/ de NBConvert]]
~jupyter nbconvert --to mypackage.MyExporter~
        ~notebook.ipynb~ ** Recap - Beaucoup d'informations en peu de temps - Mettez en pratique ! * C028AL-W2-S4-B; Prise en main de l'outil (Rstudio) ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. Exemples récents d'études assez discutées 2. Pourquoi est-ce difficile ? 3. Le document computationnel : principe 4. *Prise en main de l'outil*
Au choix : - Jupyter - *Rstudio* - OrgMode 5. Travailler avec les autres 6. Analyse comparée des différents outils ** Prise en main de l'outil :
Rstudio #+BEGIN_EXPORT html

#+END_EXPORT Note: Même plan que précédemment ** Lancement - Ouverture d'un document - Description rapide - Sauvegarde - Aide ** Exécution des blocs - Exécution et récupération des résultats - Ajout d'un bloc - Attention à l'ordre (notion de session, incohérences possibles) - Tout réexécuter depuis le début ** Raccourcis clavier et auto-complétion - Raccourcis claviers - Complétion R - Folding ** Production et partage du document final - Knit - Partage à peu de frais via rpubs ** Contrôler la visibilité du code et des résultats - Complétion (paramètres des blocs) ** Utiliser un style particulier - pdf, LaTeX - html - word/office Possibilité de faire du LaTeX (R Sweave : =Rnw=) ou du
html (R html : =Rhtml=) directement pour avoir un contrôle parfait. ** Utiliser d'autres langages - Ajout et exécution d'un bloc python - Attention, pas de session ! - Interaction uniquement via fichiers et dans de longs blocs ** Recap - Beaucoup d'informations en peu de temps - Mettez en pratique ! * C028AL-W2-S4-C; Prise en main de l'outil (OrgMode) ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. Exemples récents d'études assez discutées 2. Pourquoi est-ce difficile ? 3. Le document computationnel : principe 4. *Prise en main de l'outil*
Au choix : - Jupyter - Rstudio - *OrgMode* 5. Travailler avec les autres 6. Analyse comparée des différents outils ** Prise en main de l'outil :
Org Mode #+BEGIN_EXPORT html

#+END_EXPORT Note: Même plan que précédemment ** Lancement - Ouverture d'un document - Description rapide - Folding / Navigation - Restructuration - Sauvegarde - Aide ** Exécution des blocs - Ajout d'un bloc R - Exécution et récupération des résultats - Attention à l'ordre - Notion de session - Incohérences possibles - Tout réexécuter depuis le début ** Raccourcis clavier - Bloc expansion - R graphique - Python, perl, ... - Shell session - Plusieurs sessions, plusieurs langages ! - Communication entre langages possible ** Navigation :noexport: - Folding - Restructuration # - Annotation (tags) ??? # - Sparse Tree ??? ** Production et partage
du document final - Git Commit - Attention aux fichiers produits - Export # - Désactiver le recalcul - Visibilité du code et des résultats - Sections cachées ** Utiliser un style particulier - pdf, LaTeX - html - Possibilité de reprendre le contrôle ** Recap - Beaucoup d'informations en peu de temps - Apprivoiser les raccourcis claviers avec la
première entrée du journal - Mettez en pratique ! * C028AL-W2-S5; Travailler avec les autres ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. Exemples récents d'études assez discutées 2. Pourquoi est-ce difficile ? 3. Le document computationnel : principe 4. Prise en main de l'outil
Au choix : - Jupyter - Rstudio - OrgMode 5. *Travailler avec les autres* 6. Analyse comparée des différents outils ** Travailler avec les autres # file:assets/img/jumping_penguin.png&size=contain #+BEGIN_EXPORT html
#+END_EXPORT ** Préparer un document pour un journal Pré-requis pour faire un *pdf* : - Actuellement caché. En interne /pandoc/, /knitr/ ou /emacs/org-mode/ - /LaTeX/ installé Export *office/word* possible dans jupyter mais à configurer. Sinon export *html*... * Dans tous les cas* : - Besoin de cacher certaines cellules - Utiliser le bon style
# Soyons honnêtes *** Produire un tel document demande d'avoir un environnement parfaitement configuré Note: Tout ces détails auront été expliqués avant pour chaque environnement. - http://blog.juliusschulz.de/blog/ultimate-ipython-notebook - https://github.com/kirbs-/hide_code is a must-have - http://svmiller.com/blog/2016/02/svm-r-markdown-manuscript/ - https://github.com/balouf/Kleinberg/blob/master/KleinbergsGridSimulator.ipynb - Il y doit y avoir des choses équivalentes, mais plus simples pour Rmd - Et pour emacs, c'est d'une certaine façon plus simple car on est habitué à bidouiller. ** Convaincre vos co-auteurs
Face à cette complexité, plusieurs réactions : 1. Pas grave, c'est génial ! Je m'y mets ! 2. Euh... c'est bien. Mais je n'ai pas le temps d'apprendre... 3. Un nouvel outil ? Jamais ! $\leadsto$ différentes organisations possibles ** Option 1 : les co-auteurs enthousiastes
Il faudra *assurer le service après-vente* : - Compatibilité avec les différents environnements - Gérer cette complexité (jupyter/rstudio/emacs, git, ...) C'est la meilleure façon de *s'assurer que tout est reproductible* et inspectable (et pas uniquement sur votre propre machine...) ** Option 2 : investissement a minima
Vos co-auteurs vous laissent gérer le code, les résultats mais adoptent votre style de document. *Ils peuvent :* - Éditer le texte de l'article (markdown ou org-mode) *Ils ne peuvent pas :* - Recalculer - Exporter et voir le document final ** Option 3 : les co-auteurs "réfractaires"
*Les co-auteurs ne changent pas leurs habitudes* - Un document /computationnel/ séparé produit tous les résultats et toutes les figures - Un autre document (/classique/) inclut les figures générées Mais tout est *conservé*, *documenté* et *recalculable* dans votre document computationnel ! ** Publier / partager votre document *Rpubs* - Parfait pour partage rapide, pas pérenne *Dropbox et autres* - +Pérénité+, accès ??, ... *Gitlab/Github/...* 1. Rendre public (tout l'historique !) 2. Faire le ménage et archiver l'état courant dans un site compagnon *Sites compagnons* - Runmycode, Éditeurs, ... - Article : *HAL* ; code et données : *Figshare / zenodo* ** Conclusion
Plusieurs modalités possibles en fonction de : - vos co-auteurs - vos contraintes techniques - vos contraintes de confidentialité/copyright * C028AL-W2-S6; Analyse comparée des différents outils ** Le document computationnel _Module 2. La vitrine et l'envers du décor : le document computationnel_ 1. Exemples récents d'études assez discutées 2. Pourquoi est-ce difficile ? 3. Le document computationnel : principe 4. Prise en main de l'outil
Au choix : - Jupyter - Rstudio - OrgMode 5. Travailler avec les autres 6. *Analyse comparée des différents outils* ** Analyse comparée
des différents outils #+BEGIN_EXPORT html #+END_EXPORT Un document computationnel,
mais pour quoi faire exactement ? Note: - Pour comparer ces différents outils, il est important de bien identifier l'usage que l'on souhaite en faire. - Nous allons regarder ensemble quelques cas d'usages ** Un cours ou un tutoriel Un notebook Jupyter - Facile à prendre en main - Document dynamique Note: - Super pratique. - Téléchargement, exécution dynamique, résultats interactifs, variations faciles, etc. - C'est idéal pour un document à destination d'auto-formation. ** Un journal [[file:~/org/journal.org][Mon journal en org-mode]] - Un seul auteur - Organisation chronologique - Étiquettes - Notes, liens, code Note: - Structuration type: par date - Mots-clés - Navigation aisée - Réexécution de code comme d'habitude ** Un cahier de laboratoire [[file:~/Work/Documents/Articles/2018/Alya-Perf/LabBook.org][Un cahier de laboratoire en org-mode]] - Organisation sémantique - Conventions - Plusieurs auteurs - Étiquettes pour auteurs,
expériences, etc. Note: - Assez proche d'un journal mais avec un contenu bien plus technique et fait pour être exploitable par des collègues. - Exemple de structuration. ** Un article reproductible [[file:~/Work/Documents/Articles/2017/paper-hpl-at-scale/paper.org][Un article en cours]] - Plusieurs auteurs - Regénérer les figures - Revenir aux sources Note: - On voit la structure de l'article. - Certaines sections sont cachées - Elles pointent vers le cahier de laboratoire traçant les données que je vais exploiter. - Ici, je suis reparti de figure que Tom avait faites et je les ai retravaillées et adaptées à ce dont j'avais besoin pour mon article. - Ici, c'est un peu "sale", il y a des liens vers des fichiers qui sont sur mon disque dur mais c'est un article en cours de préparation et vous voyez que j'ai bien accès à l'ensemble des informations dont j'ai besoin. - Plusieurs structurations sont possibles. En général, j'ai une grosse section cachée au début de l'article où j'indique comment récupérer l'ensemble des données (avec les commandes git ou les URLs). Le reste du code d'analyse contenu dans l'article peut alors être exécuté. - Ici, comme on prépare un article, il est essentiel de pouvoir cacher certaines sections et d'avoir un contrôle complet sur la typographie car on n'a jamais assez de place. - Dans tous les cas, tout ceci n'est possible que si on a suffisemment de matière, c'est-à-dire que si on a pris régulièrement des notes sur comment on a obtenu les données et sur comment on les a analysées. C'est ce que vous mettrez en pratique dans le module 3 avec l'outil de votre choix. ** Différences techniques | | Origine | Technologie | Utilisation | Navigation | Format | Article? | |---------------+-----------+--------------------+---------------+------------+--------+-----------| | Jupyter | 2001 | Web App., Python | Facile | Limitée | JSON | Difficile | | Rstudio/knitr | 2011/2014 | IDE, Java/R | Facile | Limitée | Rmd | Oui | | Org-Mode | 1976/2008 | Editeur, EmacsLisp | Plus complexe | Puissante | Org | Oui | L'outil importe peu, ce qui importe, c'est : - collecter l'information - l'organiser et la rendre exploitable - la rendre disponible Note: - L'écosystème évolue mais vous pouvez déjà vous en saisir. ** Bonus : expériences vécues - Complétion, introspection donc développement/composition pas si désagréable comparé à un IDE avancé. - Objectif atteint. Mois par mois : permet aux collègues d'aider, d'avancer ensemble, etc. Communication de "problèmes" (données manquantes par exemple) bien plus simple. - Un document dynamique et traçable, réexecutable, modifiable, réutilisable, ... Quand le reviewer 3 demande de refaire la figure 5 en noir et blanc et de changer les légendes. Ou bien de rajouter de la compléter. - Au jour le jour : meilleur réutilisation (par exemple entre l'article et le slide) Éléments clés lors du choix : - Simplicité de prise en main vs. vrai éditeur - Où sont fait les calculs - Multi-langage - http://carreau.github.io/posts/23-Cross-Language-Integration.html - Gestion des langages compilés - Notions de caches et d'état Les principaux outils actuels : - jupyter - rstudio - org-mode Limitations : - Longs calculs - Grands documents - Solutions wysiwyg pour jupyter Historique/diff un peu compliqué pour jupyter