Правило великого пальця для кількості проб завантаження

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

Мій досвід полягає в тому, що статистики не будуть сприймати моделювання чи завантажувальні програми серйозно, якщо кількість повторень не перевищить 1000. Помилка MC - це велика проблема, яку мало цінують. Наприклад, цей документ використовується Niter=50для демонстрації LASSO як інструменту вибору функцій. Моя теза зайняла б набагато менше часу для запуску, якби 50 ітерацій було визнано прийнятними! Я рекомендую завжди оглядати гістограму зразків завантажувальної програми . Їх розподіл має виглядати досить регулярно. Я не думаю, що будь-якого простого числового правила буде недостатньо, і було б зайвим виконувати, скажімо, подвійний завантажувальний інструмент для оцінки помилки MC.

Припустимо, ви оцінювали середнє значення за співвідношенням двох незалежних стандартних нормальних випадкових величин, деякі статистики можуть рекомендувати завантажувати його, оскільки інтеграл важко обчислити. Якщо у вас під поясом є основна теорія ймовірностей, ви визнаєте, що це відношення утворює випадкову змінну Коші з неіснуючим середнім. Будь-який інший лептокуртичний розподіл потребує декількох додаткових ітерацій завантаження у порівнянні з більш регулярним аналогом щільності Гаусса. У такому випадку 1000, 100000 або 10000000 завантажувальних зразків було б недостатньо для оцінки того, чого не існує. Гістограма цих завантажувальних програм буде виглядати нерегулярно і неправильно.

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

Коротше кажучи, оцінка завантажувальної статистики статистики та її стандартна помилка виправдані лише тоді, коли гістограма завантажених зразків здається регулярною поза розумним сумнівом і коли завантажувальна виправдана.

редагувати:

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

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

В особистому записі я схильний запускати 10 000 зразків, коли оцінюю "для себе" і 100 000 зразків, коли оцінюю щось, передане іншим (але це швидко, коли я працюю з невеликими наборами даних).

Довідково

Wilcox, RR (2010). Основи сучасних статистичних методів: Значне вдосконалення потужності та точності. Спрингер.

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

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

• Очевидно, якщо у вас вкрай мало випадків (скажімо, комітет з етики дозволив 5 щурів), вам не потрібно думати про десятки тисяч ітерацій. Можливо, було б краще переглянути всі можливі нічиї. І, можливо, було б навіть краще зупинитися і подумати, як певний будь-який висновок може (не) базуватися на 5 щурах.

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

• Пов’язана (хоча і не зовсім однакова) проблема виникає під час завантаження або перехресної перевірки моделей: у вас є два джерела невизначеності: кінцева (а в моєму випадку зазвичай дуже мала кількість незалежних випадків) і (в) стабільність завантажених моделей. Залежно від налаштування валідації переупорядкування, у вас може бути лише один із них, що сприяє оцінці перекомпонування. У такому випадку ви можете використовувати оцінку іншого джерела дисперсії, щоб оцінити, яку впевненість слід досягти при переустановці та коли вона припиняється, щоб допомогти остаточному результату.

• Нарешті, поки що мої думки стосувалися того, як зробити меншу кількість ітерацій, ось практичний розгляд на користь того, щоб зробити більше :
  На практиці моя робота не виконується після запуску завантажувальної програми. Вихідні дані завантажувальної програми повинні бути узагальнені у підсумкові статистичні дані та / або цифри. Результати повинні бути інтерпретовані папером або звітом, який потрібно скласти. Багато з них уже можна зробити за попередніми результатами декількох ітерацій завантажувальної програми (якщо результати ясні, вони показуються вже після декількох ітерацій, якщо вони є прикордонними, вони залишаться прикордонними). Тому я часто налаштовую завантажувальну систему таким чином, що дозволяє мені отримувати попередні результати, щоб я міг продовжувати працювати, поки комп'ютер обчислює. Таким чином, це мене не сильно турбує, якщо завантажувальний процес триватиме ще кілька днів.

TLDR. 10 000, здається, є хорошим правилом, наприклад, значення p з цієї великої або більшої кількості зразків завантажувальної програми будуть знаходитись в межах 0,01 від "справжнього p-значення" для методу приблизно в 95% часу.

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

Трохи перефрамуючи. Це може бути корисно для обчислення невизначеності, пов'язаної з результатами завантажувального інструменту, щоб отримати відчуття невизначеності, що виникає в результаті використання завантажувальної програми. Зауважте, що це не стосується можливих недоліків завантажувальної програми (наприклад, дивіться посилання вище), але це допомагає оцінити, чи є "достатньо" зразків завантажувальної програми у певному додатку. Як правило, помилка, пов’язана з розміром вибірки завантажувальної програми, n переходить до нуля, як і nдо нескінченності, і питання задає, наскільки великою повинна nбути помилка, пов’язана з малим розміром вибірки завантажувальної програми?

Невизначеність завантажувальної установки в p-значенні. Неточність оціненого p-значення, скажімо, pv_est - це р-значення, оцінене з завантажувальної програми, є приблизно 2 x sqrt(pv_est * (1 - pv_est) / N), де Nкількість зразків завантажувальної програми. Це дійсно, якщо pv_est * Nі (1 - pv_est) * Nобидва >= 10. Якщо одна з них менша за 10, то вона менш точна, але дуже приблизно в тому ж мікрорайоні, що і ця оцінка.

Помилка завантаження в довірчому інтервалі. Якщо ви використовуєте довірчий інтервал 95%, то подивіться, як мінливість квантилів розподілу завантажувальної системи біля 2,5% та 97,5% шляхом перевірки відсотків на (для 2,5-го перцентиля) 2.5 +/- 2 * 100 * sqrt(0.025 * 0.975 / n). Ця формула повідомляє про невизначеність нижнього кінця довірчого інтервалу 95%, виходячи з кількості взятих зразків завантаження. Аналогічну розвідку слід провести у верхньому кінці. Якщо ця оцінка дещо мінлива, то обов'язково беріть більше проб завантаження!

$599$

$\alpha$$B$

$\alpha_1 = 0.1$$\alpha_2 = 0.05$

Ми маємо

$599$

Наступну інформацію я взяв від Davidson, R. та MacKinnon, JG (2000). Тести завантаження: скільки завантажувальних? Економетричні огляди, 19 (1), 55-68. (версія робочого паперу безкоштовно завантажується).

$0.05$$399$$0.01$$1499$

$B$

"Неважко зрозуміти, чому процедура попереднього тестування працює добре. Коли гіпотеза про нуль відповідає дійсності, B можна сміливо бути малим, оскільки нас взагалі не хвилює влада. Так само, коли нуль помилковий, а потужність тесту надзвичайно висока, B не потрібно бути великим, тому що втрата електроенергії не є серйозною проблемою. Однак, коли нуль помилковий, а потужність тесту помірно висока, B має бути великим, щоб уникнути втрати потужності. Б малий, коли він може бути безпечно малим, і великий, коли йому потрібно бути великим ".

$B$

Більшість застосувань для завантаження, які я бачив, повідомили про від 2 000 до 100 000 ітерацій. У сучасній практиці з належним програмним забезпеченням найбільш важливими проблемами завантажувальної програми є статистичні, більше ніж час та обчислювальна потужність. Для початківців користувачів з Excel можна було виконати лише кілька сотень, перш ніж вимагати використання розширеного програмування Visual Basic. Однак R набагато простіший у використанні та робить покоління тисяч завантажених значень легкими та простими.