Як переконатися, що результати моїх моделювання та результати моєї роботи завжди синхронізовані?

В одному зі своїх робіт я перераховую деякі числові результати на додаток до деяких цифр. Що я хотів би зробити, це переконатися, що числові результати в моїй роботі завжди відповідають коду. Зараз я просто безпосередньо копіюю цифрові результати з моїх результатів імітації на папір, що є надзвичайно простим і низькотехнологічним, але схильним до помилок, тому що я можу неправильно скопіювати результати або забути синхронізувати результати паперу з вихід коду.

Чи є хороший спосіб зберегти числові результати, які я цитую у своїх роботах, синхронізовано з результатами, згенерованими моїм кодом? (Тут я припускаю, що виконувати код легко і практично, коли я хочу оновити свою роботу.) Ці числові результати не обов'язково піддаються таблиці. Іноді у мене є таблиці в рукописах, але частіше у мене є параметри моделювання, перелічені як числа в рівняннях . Прикладом може бути щось на зразок:

де я хотів би замінити елементи початкової умови на фактичні параметри, які я використовую при моделюванні, що чисельно інтегрує систему звичайних диференціальних рівнянь. Використання таблиці для одноразових даних, таких як цей приклад, здається завищеною і більше чорнила, ніж потрібно.$\mathbf{y}^{*}$

Я припускаю, що фігури - простіший випадок: щоразу, коли документ "будується" (з джерела LaTeX, Markdown, RST тощо), запускайте процес збирання, виконуючи код. Однак, якщо люди мають кращі пропозиції щодо синхронізації фігур, створених моїми імітаціями, синхронно з моїм документом, я б хотів їх почути.

Оскільки деякі коментарі запропонували цей підхід вже давно був розроблений в R спільноти, спираючись на Sweaveі зовсім недавно knitr. Очевидно, що цей підхід є недоліком того, що на даний момент є специфічним для мови, але тим перевагою, що його регулярно використовують в наукових працях.

Використання Sweave в реальних публікаціях

• Журнал Biostatistics заохочує ці уявлення, і поміщає Kitemark літери «R» на наукових роботах , в яких редактор відтворюваних вдалися запустити код і дані і отримати ці результати.
• По суті всі публікації в R-Journal створені на Sweave.

Звичайно, частіше користувачі Sweave / knitr представляють лише остаточний результат у більшості журналів, з впевненістю в тому, що методи дійсно відтворюють результати. Так само підмітання часто використовується для створення слайдів для професійних розмов тощо.

Корисні функції

Щоб бути корисною на практиці, така система повинна мати певні особливості. Маючи критичну масу користувачів, багато з них добре розвинені в Росії knitr. Кілька важливих моментів:

• Кешування. Написання у такому форматі, як розмітка чи латекс, який повинен бути складений, щоб побачити вихід, робить це неможливим, включаючи код, неможливо, коли результати неможливо кешувати. Розумне кешування в knitrнасправді робить налагодження інтенсивного коду набагато простішим, ніж робота в чистому режимі R, оскільки не потрібно повторно запускати успішні фрагменти.

• Увімкнути показ коду. У офіційній публікації може не захотіти, щоб будь-який з базових кодів був видно на виході. Тим часом часто важливо показати (добре відформатований, виділений синтаксисом) код, який дає результати у вихідному форматі, коли ви бажаєте, щоб читач точно бачив, що ви набираєте.

• Громада. Мабуть, найпереконливіша перевага такого підходу перед рішенням, яке виробляється в домашніх умовах, - це кількість людей, знайомих з цією моделлю та намагаються її вдосконалити.

• Багато демонстраційних прикладів інших функцій можна знайти на демонстраціях веб-сторінок в'язання , включаючи інструменти для «легкої публікації» або спільного використання в Інтернеті. Багато з цих функцій допомагають зробити цей підхід більш сумісним із загальним робочим процесом, а не щось робити лише під час написання рукопису.

Історична виноска.

Як випливає з назви, хоча, як випливає з цієї назви, йдеться про "грамотне програмування" Кнута, акцент зовсім інший, оскільки грамотне програмування зосереджене на з'єднанні програмного коду та документації (у спільноті R ця роль відіграється Roxygen, що простежує коріння в іншій галузі "грамотне дерево програмування").

Вихід за межі

В принципі, ми можемо попросити набагато більше від динамічного документа, наприклад, здатності читача змінювати входи та бачити результати, не потребуючи редагування та перекомпіляції всього документа, наприклад, за допомогою інтерактивної онлайн-платформи. XDynDocs може бути кроком у цьому напрямку.

Інші підходи

• Можливо, хочете слідкувати за dexy.it
• Дещо інший підхід: зростаюча кількість хостів економічних робіт, пов’язаних з публікаціями на веб-сайті http://www.runmycode.org/ , які повторно запускають аналізи в хмарі та дозволять користувацькі параметри введення або власні вхідні дані.

Те, що ви просите, - це великий виклик "Виконавчого паперу" Ельзів'є . Хоча було випробувано багато підходів, жоден не є таким переконливим, як можуть запропонувати автори. Ось кілька прикладів використовуваних прийомів.

Проект «Мадагаскар» використовує ваш підхід, всередині сценарію make є запущене моделювання, яке одночасно створює фігури та папір.

IPython Notebook надає документ, який можна виконати під час читання та створення фігур для вмісту серця. (Я бачив слова плагіни, Mathematica та багато інших рішень, які використовуються таким же чином)

VisTrails використовує сервісно-орієнтований підхід до архітектури та забезпечує менеджер "провидіння" або "робочий процес". В основному ви реєструєте гачки для кодування, а потім проектуєте робочий потік або експеримент, який відтворює вашу роботу. Він використовується в багатьох типах кодів, навіть кластерах HPC. При такому підході у вас з'явиться спосіб повторити експерименти.

Є багато тонн таких типів рішень, але це три, якими я був вражений. Це складна проблема, і я вважаю, що ми насправді навіть не близькі до вирішення. Ми навіть не можемо змусити людей випустити код зі своїми документами, як ми можемо очікувати, що вони відтворять результати = P

Я не мав великого успіху у використанні інших людей для вирішення цієї проблеми. Зазвичай я просто хочу чогось простого, що працює для мене і виконує роботу. З цією метою я, як правило, намагаюся написати один сценарій пітона, який відповідає за виконання всіх результатів, аналіз результатів, а також побудову фігур / таблиць.

Я пишу свої коди для створення файлів даних, які містять результати в якомусь текстовому форматі. Ви можете уникнути повторного одержання цих результатів у своєму скрипті, попередньо перевіривши наявність вихідного файлу (наприклад, у python, використовуючи os.path.isfile ()). Якщо ви хочете відновити результати, просто видаліть файли даних. Якщо файли даних існують, я виконую розбір цих файлів. Для цього дуже корисний модуль python для регулярних виразів (пере).

Потім з розбору результатів я створюю фігури або таблиці. Для таблиць в латексі ви можете написати код для генерації таблиці в окремий файл (я використовую розширення .tbl), а потім включити це у свій файл латексу. Для мене ключовим є використання 1 сценарію python. Якщо мене багато, то згодом мені цікаво, хто з них - що і що вони роблять. Якщо цей опис занадто розпливчастий, я можу надіслати вам кілька прикладів.

На мою думку, навіть важливіше - це переконатися, що ви зможете зрозуміти, як заново або генерувати всі результати з нуля протягом місяця чи року (наприклад, коли арбітри просять вас щось додати чи змінити). З цією метою я включаю текстовий файл з дуже детальними вказівками щодо відтворення всіх результатів. Найкраще, якщо ви перевірите це, змусивши когось іншого (наприклад, співавтора) спробувати їх. Я рекомендую також надати ці інструкції (і весь ваш код) суддям та читачам.

Ось приклад (насправді підготував мій співавтор Арон Ахмадія).

Оргамод Emacs у поєднанні з Бабелем цього досягає. Babel може виконувати фрагменти коду з різних мов програмування та сценаріїв, наприклад, він може відкрити файл, що містить дані симуляції, і помістити його в таблицю в органоді, яку можна експортувати в LaTeX (та багато інших форматів). Це займе певний час, щоб звикнути до всіх ключових комбо в оргамоді, але як тільки він працює, все автоматично.

Якщо запустити весь код дешево, ви можете зробити щось низькотехнологічне, наприклад:

Ви можете шаблонувати документи з відформатованими рядками, щоб вони виглядали приблизно так

"we observed a %(fractional_improvement)s increase in ..."

Майте сценарії python, схожі на це

results = {"alpha"                  : run_alpha_computation(...),
           "fractional_improvement" : run_fi_computation(...), 
           ...}

А потім зробіть щось подібне

for fn in filenames:
    file = open(fn);      s = file.read();       file.close()
    file = open(fn, 'w'); file.write(s%results); file.close()

Потім ви можете загортати це в Makefile.

Якщо ви використовуєте LaTeX, відносно низькотехнологічне рішення полягає в тому, щоб ваш код виплюнув файл (або використовуйте сценарій для фільтрації з виводу коду), що містить цілу купу таких рядків:

\newcommand{\myresults1}{<value>}

Потім ви можете скористатися \inputкомандою, щоб додати цей файл у ваш документ, а за допомогою визначених команд розмістити значення.

Я працюю на Elsevier. Моя компанія почала використовувати рамку Collage (розроблену у відповідь на Executable Paper Grand Challenge) у виданнях журналу, щоб автори могли публікувати шматки виконуваного коду зі своєю статтею. Ця функція полегшує читачам відтворювати результати, про які повідомляється у статті, та повторно використовувати опубліковані матеріали для власних досліджень. Collage підтримує широкий спектр програмного забезпечення з відкритим кодом та власним програмним забезпеченням; більше інформації можна знайти в інформаційному відео тут та на веб-сайті Collage Authoring Environment .