Question:
Comparaison des stratégies de recherche reproductibles: Brew ou Sweave vs R2HTML
Tal Galili
2011-09-21 17:30:58 UTC
view on stackexchange narkive permalink

C'est un peu plus une question "réfléchissez-y" - mais je la vois comme une question importante à poser.

J'ai du mal ces derniers jours à avoir une recherche plus reproductible. comme le flux de travail. Je suis confus avec les deux stratégies différentes pour rédiger un rapport.

Les deux stratégies sont:

  1. Sweave ou brasser. Où il y a un fichier report.Rnw ou report.brew qui a un mélange de langage de balisage (HTML ou LaTeX) et de code R entre accolades spéciales (par exemple << >> = @). Ce fichier doit être exécuté via Sweave ou brew afin de créer le fichier de rapport (report.html ou report.tex).
  2. R2HTML (pour HTML) et Hmisc (pour LaTeX). Où le fichier .r utilise des fonctions R pour construire report.html ou report.tex; l'exécution des commandes R génère directement le rapport.

Ce qui est clair pour moi, c'est que la plupart des gens en ligne semblent utiliser l'option 1. Mais je ne comprends pas pourquoi c'est si courant, quand l'option 2 me semble (sans trop expérimenter) être moins de travail.

Quand est-ce que chacune des deux stratégies est meilleure?

Based on your comment below, I'd suggest editing the question to take out your struggles with LaTeX, as that makes it feel like it's an HTML vs LaTeX question, and mentioning the Hmisc library in method 2 as a way of doing a similar thing but with LaTeX.
Salut Aaron, je vais le modifier un peu ...
Thanks for your edit. I took the liberty of editing it further to make it clearer what Hmisc does (and some other smaller edits); if it makes it past peer review, you can decide if it still reflects your question accurately.
Je voulais juste ajouter le mode org avec Babel comme un autre moyen de réaliser quelque chose de sweave sans avoir besoin de creuser profondément dans le latex (ou de l'utiliser comme point de départ pour un réglage plus fin du latex). Disponible dans emacs.
Cinq réponses:
Aaron left Stack Overflow
2011-09-21 20:48:40 UTC
view on stackexchange narkive permalink

Nouvelle réponse basée sur le commentaire ci-dessous:

Si je comprends bien, la méthode 1 consiste à mélanger le code R et HTML ou LaTeX dans le même document, en utilisant Sweave ou brew par exemple , pour créer un document final, tandis que la méthode 2 consiste à utiliser du code R pour générer du HTML ou LaTeX, en utilisant les packages R2HTML ou Hmisc par exemple, puis à simplement exécuter le code R pour créer le document final. Je viens principalement d'utiliser la méthode 1, mais je vais peser de toute façon.

Comme je le vois, c'est vraiment juste une question de préférence; Je ne vois aucune raison technique ou statistique de préférer l'un à l'autre; ce sont les deux façons de rendre votre recherche reproductible.

Je pense que la méthode 1 est plus simple car vous n'avez pas besoin de savoir quelles sont les fonctions R qui créent le LaTeX ou le code HTML; vous écrivez simplement du code R, et vous écrivez du code HTML ou LaTeX, et le logiciel se charge de les assembler. Cela est particulièrement vrai lorsque la sortie R ne représente qu'une petite quantité du document final; ce serait pénible d'écrire le code R nécessaire pour sortir beaucoup de texte, par exemple. Dans les éditeurs de texte intelligents, vous obtenez également le bon formatage de syntaxe pour chaque type de code que vous n'obtenez pas lorsque vous utilisez R2HTML ou Hmisc. Cette méthode sépare également les résultats du commentaire plus proprement, à mon avis.

Cependant, pour de courts extraits ou simplement pour afficher les résultats d'une commande sans commentaire, utiliser R2HTML ou Hmisc pourrait être plus facile, cependant ( parlant de mon expérience), une fois que vous avez pris l'habitude de Sweaving, vous ne reviendrez jamais en arrière.

Thank you for the response Aaron. Notice though that the question is not between HTML and LaTeX, but between writing the report and having the R code in it Versus writing R code that also include code for constructing the report. Maybe I should come up with an example to illustrate - but thanks for taking the time to answer...
On dirait qu'Aaron et moi avons eu la même lecture de votre question. Je considérerais un exemple pour illustrer, et j'espère que nous pourrons être plus utiles.
@TalGalili: édité en fonction de votre commentaire; aussi, pensez à mettre cela dans la question, voir mon commentaire sur la question pour plus de détails.
Aaron - merci pour la réponse mise à jour. Je suis généralement d'accord avec votre réponse. J'aurai besoin de réfléchir davantage au Sweaving ...
Jeromy Anglim
2011-09-22 04:06:14 UTC
view on stackexchange narkive permalink

Ce ne sont que quelques points.

  • Si vous voulez simplement écrire des rapports simples, alors l'ensemble des commandes LaTeX que vous devez apprendre est beaucoup plus petit que si vous voulez le faire des choses complexes.
  • Un aspect attrayant de LaTeX par rapport à certains systèmes de balisage simples est que si vous voulez des fonctionnalités telles que le référencement, la numérotation automatique, des tableaux multi-pages, un réglage de type attrayant, ces fonctionnalités sont disponibles. En particulier, il y a eu des fonctionnalités auxquelles je n'avais même pas pensé au départ, mais quand j'en ai eu besoin, elles ont été disponibles dans LaTeX en tant que package.
  • Si vous voulez que votre rapport final soit dans un autre format, tel que HTML ou rtf, vous pouvez alors utiliser divers programmes de conversion comme pandoc pour convertir le latex dans ce format.
Le point 1 est rassurant :)
Abhijit
2011-09-22 07:09:51 UTC
view on stackexchange narkive permalink

L'autre chose intéressante potentiellement à propos de LaTeX ou d'un autre balisage dans le paradigme Sweave / odfWeave / asciiWeave est que pour les rapports répétés, vous pouvez le modéliser un peu mieux une fois, puis réutiliser simplement le modèle. Voir le package rreport de Harrell comme exemple

Fomite
2011-09-21 22:07:50 UTC
view on stackexchange narkive permalink

Vous êtes assez sûr d'utiliser l'un ou l'autre - même si j'avoue que je n'utilise aucun des deux. Je soupçonne que la principale raison de la popularité de la méthode LaTeX / Sweave est le nombre de champs qui utilisent LaTeX comme format papier / présentation / manuscrit principal qui incite à utiliser un système basé sur LaTeX. Je ne connais pas un seul champ où un produit final .html est tout cela directement utile.

je ne sais pas sur la popularité du latex en raison des exigences du terrain. Je travaille dans un domaine (la psychologie) où presque nulle part le tex ne prend, et je l'utilise toujours (pour éviter de dessiner des tableaux et de les formater manuellement). Je pense que sa popularité a plus à voir avec son âge qu'autre chose.
@richiemorrisroe Il y a certainement des gens qui l'utilisent pour une raison quelconque - ils l'aiment, ils n'aiment pas le formatage manuel, peu importe. J'ai cependant trouvé, en sautant entre les champs, que je rencontre des champs qui n'utilisent presque * jamais * LaTeX (le mien) et des champs où il était une fois affirmé "Si ça va être publié, ça doit être en LaTex". Cette conversation s'est terminée par le fait que j'ai dû imprimer une copie des directives de soumission d'AJE.
J'aurais parfois aimé travailler dans l'un des domaines lourds de LaTeX, cela me ferait gagner beaucoup de temps et de tracas tout au long de mon doctorat.
M Adams
2011-09-23 14:01:16 UTC
view on stackexchange narkive permalink

La raison pour laquelle l'option 1 est si courante est que ... elle est si courante. Sweave existe depuis près de 10 ans et, pour de nombreux utilisateurs de R, est synonyme de recherche reproductible. De plus, les types de personnes qui entendraient l'expression «recherche reproductible» et penseraient «ça sonne bien» sont probablement déjà familiers avec LaTeX. Ainsi, ce n'est pas comme s'ils choisissaient entre deux options, car beaucoup ne sauront même pas que l'option 2 existe.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...