Переход исследовательского проекта на установку на базе Knitr
Наконец, я решил приблизить свое диссертационное исследование к цели сделать его настолько хорошим, насколько это возможно, воспроизводимым исследованием, учитывая мои обстоятельства. Так как в настоящее время я не использую LaTeX для моего диссертации диссертации (хотя я рассматриваю этот вариант), я считаю, что knitr это лучший способ пойти.
Проект программного обеспечения, реализующий эмпирическую часть моего диссертационного исследования (анализ данных), пишется в R, Проект содержит несколько файлов в структуре каталогов, что довольно типично для научных рабочих процессов (подкаталоги верхнего уровня: analysis, cache, data, figures, import, prepare, present, results, sandbox, utils).
Я прочитал много информации (включая примеры) по использованию knitr для автоматической генерации отчетов и воспроизводимых исследований в целом. Тем не менее, я несколько ошеломлен множеством вариантов конфигурации и, что еще более важно, все еще смущен лучшим / правильным / оптимальным подходом для использования knitr в таких проектах, как мой, содержащий несколько файлов и каталогов. В частности, меня интересуют советы по структуре и действиям по переходу существующей кодовой базы без слишком большого количества изменений в R модули.
В качестве примера давайте рассмотрим мои модули, связанные с анализом поисковых данных (EDA). Мой текущий рабочий процесс EDA включает в себя:
предварительные данные, преобразованные из исходных необработанных данных (расположенных в подкаталогах "data/transform");
модуль "eda.R", расположенный в каталоге "анализ";
каталог "results/eda", где мой текущий код генерирует цифры (файлы SVG) из одномерного и многомерного EDA, а также отчет в виде одного документа (файл PDF) с той же графической информацией (генерируется описательная статистика) в виде консольный вывод при запуске скрипта "eda.R").
Для перехода к knitr на основе проекта, я создал файл "eda-report.Rmd" с R Markdown заявления для установки местного knitr варианты, в том числе read_chunk("eda.R"), Насколько я понимаю, теперь мне нужно определить существующие блоки R код в "eda.R" как knitr куски, а затем вызвать эти именованные чанки, в соответствии с моим рабочим процессом EDA.
Вопросы:
Это правильный подход? Каковы лучшие практики для использования knitr в отношении настройки путей проекта, используя source(), группируя некоторые участки через gridExtra, предотвращая потенциальные проблемы? Мне кажется, что в дополнение к "eda-report.Rmd" мне нужно создать еще один модуль R, который будет инициировать обработку .Rmd подать knitr, Если да, какой звонок мне следует использовать: rmarkdown::render() или же knitr::knit() (пока я пользуюсь RStudio для разработки, я хочу, чтобы мой код был независим от среды разработки)?
ОБНОВЛЕНИЕ 1 (Дополнительный вопрос):
Почему обработка .Rmd файл в RStudio через кнопку "вязать HTML" выдает HTML документ, при обработке через Makefile команда Rscript -e 'library("knitr"); knit("eda-report.Rmd")' производит .md файл, но не HTML несмотря на наличие output: html_document Директива?
Спасибо за чтение этого! Ваш совет будет с благодарностью!
1 ответ
Чтобы перевести ваш рабочий процесс на использование knitr, я предлагаю вместо того, чтобы пытаться сделать каждый последний фрагмент кода, который вы пишете, воспроизводимым, вы должны начать с битов, которые будут наиболее полезны.
Поскольку knitr - это инструмент для создания отчетов, лучше всего начать с написания диссертации в knitr. (Вы упомянули, что в настоящее время вы не используете LaTeX. Это нормально: knitr также поддерживает AsciiDoc, который, как мне кажется, легче написать. Если в вашей диссертации нет большого количества уравнений или таблиц, вам, возможно, не понравится писать его в Уценка или Текстиль, что еще проще.)
Точно так же knitr хорош для любых отчетов или работ, которые вы можете написать.
Для более сложного использования вы можете создавать презентации, используя knitr. (Я иногда вяжу презентации в формате xhtml.)
То, с чем я бы не стал беспокоиться, это попытка связать весь ваш исследовательский анализ данных. Большинство вещей, которые вы найдете, скучны или тупики, так что это не стоит дополнительных усилий. Сосредоточьтесь на том, чтобы исследовать так быстро, как вы можете, а затем связать интересные кусочки потом. Аналогично, очистка данных обычно не так интересна, поэтому часто достаточно хорошо прокомментированного кода.
Чтобы ответить на ваш вопрос о структуре каталогов, я предпочитаю, чтобы, поскольку отчеты knitr предназначались для окончательного вывода, их нужно было помещать в "песочницу", не занимаясь исследовательской работой. То есть они могут иметь свой собственный каталог и создавать свои собственные копии рисунков.