Виконайте MCMC: використовуйте jags / stan або реалізуйте його самостійно

Я новачок у баєсівській статистиці. Я чув від дослідників, що байєсські дослідники краще впроваджують MCMC самостійно, а не використовують такі інструменти, як JAGS / Stan. Чи можу я запитати, яка користь від самостійного впровадження алгоритму MCMC ("не дуже швидкими" мовами, такими як R), за винятком цілей навчання?

Загалом, я настійно пропоную не кодувати свій власний MCMC для реального прикладного байєсівського аналізу. Це і велика робота, і час, і дуже ймовірно, що в коді будуть внесені помилки. Пробовідбірники Blackbox, такі як Stan, вже використовують дуже складні пробовідбірники. Повірте, ви не будете кодувати пробовідбірник цього калібру лише для одного аналізу!

Є спеціальні випадки, коли в цьому цього буде недостатньо. Наприклад, якщо вам потрібно було зробити аналіз в режимі реального часу (тобто рішення на комп'ютері на основі вхідних даних), ці програми не були б гарною ідеєю. Це тому, що Стен вимагає компілювати код C ++, що може зайняти значно більше часу, ніж просто запустити вже підготовлений зразок для відносно простих моделей. У такому випадку ви можете написати власний код. Крім того, я вважаю, що існують особливі випадки, коли такі пакети, як Stan, роблять дуже погано, такі як моделі не-гауссового простору держави (повне розкриття: я вважаю, що Стен в цій справі робить погано, але не знаю). У цьому випадку можливо, варто застосувати спеціальний MCMC. Але це виняток, а не правило!

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

Крім того, хоча не має сенсу писати власний пробовідбірник для одного аналізу , це може мати багато сенсу писати власний код для класу аналізів. Оскільки JAG, Stan та ін. Є зразками з чорного ящика, ви завжди можете зробити все швидше, спеціалізуючись на даній моделі, хоча сума вдосконалення залежить від моделі. Але писати надзвичайно ефективний зразок з нуля - це, можливо, 10-1000 годин роботи, залежно від досвіду, складності моделі тощо. Якщо ви займаєтесь дослідженнями методів Байєса або пишете статистичне програмне забезпечення, це добре; це ваша робота. Але якщо ваш начальник скаже: "Ей, чи можете ви проаналізувати цей набір даних про неодноразові заходи?" і ви витрачаєте 250 годин на написання ефективного пробовідбору, швидше за все, ваш начальник буде засмучений. На противагу цьому, ви могли написати цю модель в Стен за, скажімо, 2 години, а у вас було 2 хвилини часу замість 1 хвилини пробігу, досягнутого ефективним пробовідбірником.

Це питання ґрунтується насамперед на думці, але я думаю, що тут достатньо записати відповідь. Причин кодування власної вибірки для дослідницької проблеми може бути багато. Ось деякі з них

1. Пропозиція: Як запропонував fcop у своєму коментарі, якщо зразок MH, то кодування вашого власного пробовідбірника дозволяє вам пограти з розподілами пропозицій, щоб отримати найкращий вибірник для змішування.

2. Гнучкість: у вбудованих програмах можливо не надавати потрібної вам гнучкості. Ви можете почати з конкретного випадкового значення або використовувати конкретну структуру насіння.

3. Розуміння: Кодування власного пробовідбірника допомагає зрозуміти поведінку вибірки, даючи уявлення про ланцюговий процес Маркова. Це корисно для дослідника, який працює над проблемою.

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

Можливо, є більше причин, але саме ці чотири змушують мене кодувати власні пробовідбірники.

Я дав +1 на відповідь Cliff AB. Щоб додати ще один маленький ласощі, якщо ви хочете працювати на нижчому рівні, але не знижуватись до рівня коду-все-про себе, вам слід поцікавитись пакетом LaplacesDemon . Оригінальний автор був геніальним, але, схоже, випав із сітки, а пакунок перебрав хтось інший. (Я вважаю, що це на Github.)

Він реалізує вражаючу кількість алгоритмів, які використовуються в MCMC, і включені віньєтки варто прочитати, навіть якщо ви не використовуєте пакет. Практично будь-який пробовідбірник, про який ви читали, він має. Ви кодуєте іншим чином, ніж BUGS / JAGS або Stan, і це все в R, але часто це настільки ефективно, що є конкурентоспроможним.