Тестування статистичного програмного забезпечення


10

Які методи / підходи корисні при тестуванні статистичного програмного забезпечення? Мене особливо цікавлять програми, які параметрично оцінюють з максимальною ймовірністю.

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

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

Відповіді:


8

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

  • O(N log N)O(N2)

  • n>pp>n

В обох цих випадках я впроваджував відносно відомі методи в мові програмування D (для якої не існувало жодної реалізації), тому я також перевірив кілька результатів проти Р. Тим не менш, тестування Монте Карло виявило помилок, яких я ніколи б не спіймав .

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

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


5

Не впевнений, чи справді це відповідь на ваше запитання, але це, принаймні, дотично.

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

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

    with(Statistics):
    infolevel[Statistics] := 1:
    distribution := CauchyDistribution(2, 3):
    sample := Sample(distribution, 10^6):
    ChiSquareSuitableModelTest(sample, distribution, 'bins' = 100, 'level' = 0.001);
    

    α

  2. Для розподілів з кінцевими моментами я обчислюю, з одного боку, декілька зразкових моментів, а з іншого - символічно обчислюю відповідні моменти розподілу та їх стандартну помилку. Так, наприклад, для бета-розподілу:

    with(Statistics):
    distribution := BetaDistribution(2, 3):
    distributionMoments := Moment~(distribution, [seq(1 .. 10)]);
    standardErrors := StandardError[10^6]~(Moment, distribution, [seq(1..10)]);
    evalf(distributionMoments /~ standardErrors);
    

    106

    with(Statistics):
    sample := Sample(BetaDistribution(2, 3), 10^6):
    sampleMoments := map2(Moment, sample, [seq(1 .. 10)]);
    distributionMoments := [2/5, 1/5, 4/35, 1/14, 1/21, 1/30, 4/165, 1/55, 2/143, 1/91];
    standardErrors := 
      [1/5000, 1/70000*154^(1/2), 1/210000*894^(1/2), 1/770000*7755^(1/2), 
       1/54600*26^(1/2), 1/210000*266^(1/2), 7/5610000*2771^(1/2), 
       1/1567500*7809^(1/2), 3/5005000*6685^(1/2), 1/9209200*157366^(1/2)];
    deviations := abs~(sampleMoments - distributionMoments) /~ standardErrors;
    

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

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


Дякую за вашу відповідь. Я “приймаю” іншу відповідь, оскільки мені дозволяється вибрати лише одну, і це, здавалося, трохи краще відповідає моїй ситуації. Але і ваша відповідь була дуже корисною.
Jyotirmoy Bhattacharya

2

Брюс Маккалло мав дещо котеджну галузь у оцінці статистичного програмного забезпечення (в широкому сенсі; він також перевіряв Microsoft Excel. І вважав, що це хоче). Тут і тут два документи, що ілюструють частину його підходу .


2

У цій статті Stata Journal багато деталей розповідає президент StataCorp Вільям Гулд. 1 Це дуже цікава стаття про контроль якості статистичного програмного забезпечення.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.