Testowanie oprogramowania statystycznego

Jakie techniki / podejścia są przydatne w testowaniu oprogramowania statystycznego? Szczególnie interesują mnie programy wykonujące estymację parametryczną z maksymalnym prawdopodobieństwem.

Porównywanie wyników z wynikami z innych programów lub opublikowanych źródeł nie zawsze jest możliwe, ponieważ przez większość czasu, gdy piszę własny program, jest tak, ponieważ obliczenia, których potrzebuję, nie są jeszcze zaimplementowane w istniejącym systemie.

Nie nalegam na metody, które mogą zagwarantować poprawność. Byłbym zadowolony z technik, które mogą wykryć ułamek błędów.

Jedną z przydatnych technik są testy Monte Carlo. Jeśli istnieją dwa algorytmy, które robią to samo, zaimplementuj oba, podaj im losowe dane i sprawdź, czy (w ramach małej tolerancji dla numerycznego fuzz) dają one tę samą odpowiedź. Zrobiłem to już kilka razy:

• Napisałem wydajną, ale trudną do wdrożenia implementację Kaula Tau B. Aby to przetestować, napisałem niewiarygodnie prostą implementację 50-liniową, która działała w . O ( N 2$O(N\ log\ N)$$O(N^2)$

• Napisałem kod do regresji grzbietu. Najlepszy algorytm do zrobienia tego zależy od tego, czy jesteś w przypadku czy , więc i tak potrzebowałem dwóch algorytmów. p > $n > p$$p > n$

W obu tych przypadkach wdrażałem stosunkowo dobrze znane techniki w języku programowania D (dla których nie istniała żadna implementacja), więc sprawdziłem też kilka wyników w stosunku do R. Niemniej jednak testy Monte Carlo wykryły błędy, których inaczej nigdy nie złapałbym .

Kolejnym dobrym testem jest stwierdzenie . Być może nie wiesz dokładnie, jakie powinny być poprawne wyniki obliczeń, ale to nie znaczy, że nie możesz wykonywać kontroli poczytalności na różnych etapach obliczeń. W praktyce, jeśli masz ich wiele w kodzie i wszystkie one przechodzą, to zwykle kod jest poprawny.

Edycja: Trzecią metodą jest podawanie danych algorytmu (syntetycznych lub rzeczywistych), w których wiesz przynajmniej w przybliżeniu, jaka jest prawidłowa odpowiedź, nawet jeśli nie wiesz dokładnie, i sprawdzanie przez sprawdzenie, czy odpowiedź jest rozsądna. Na przykład możesz nie wiedzieć dokładnie, jakie są szacunkowe parametry, ale możesz wiedzieć, które powinny być „duże”, a które „małe”.

Nie jestem pewien, czy to naprawdę jest odpowiedź na twoje pytanie, ale jest przynajmniej stycznie powiązana.

Utrzymuję pakiet statystyk w Maple . Ciekawym przykładem trudnego do przetestowania kodu jest losowe generowanie próbek według różnych rozkładów; łatwo jest sprawdzić, czy nie są generowane żadne błędy, ale trudniej jest ustalić, czy generowane próbki są zgodne z żądanym rozkładem „wystarczająco dobrze”. Ponieważ klon ma zarówno funkcje symboliczne, jak i numeryczne, możesz użyć niektórych funkcji symbolicznych do testowania (czysto numerycznego) generowania próbek:

1. Wdrożyliśmy kilka rodzajów statystycznego testowania hipotez, z których jednym jest test odpowiedniego modelu chi kwadrat - test chi kwadrat liczby próbek w przedziałach wyznaczonych z odwrotnego CDF o danym rozkładzie prawdopodobieństwa. Na przykład, aby przetestować generowanie próbki dystrybucji Cauchy'ego, uruchamiam coś takiego

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

   Ponieważ mogę wygenerować tak dużą próbkę, jak mi się podoba, mogę uczynić dość małą.$\alpha$

2. Dla rozkładów z momentami skończonymi obliczam z jednej strony liczbę przykładowych momentów, az drugiej symbolicznie obliczam odpowiednie momenty rozkładu i ich błąd standardowy. Na przykład dla dystrybucji beta:

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

   To pokazuje malejącą listę liczb, z których ostatnia to 255.1085766. A więc nawet dla 10. momentu wartość tego momentu jest ponad 250 razy większa niż wartość błędu standardowego przykładowego momentu dla próbki o wielkości . Oznacza to, że mogę zaimplementować test, który działa mniej więcej w następujący sposób:$10^6$

   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;
   

   Liczby distributionMomentsi standardErrorspochodzą z pierwszego biegu powyżej. Teraz, jeśli generowanie próbki jest prawidłowe, liczby w odchyleniach powinny być względnie małe. Zakładam, że są one w przybliżeniu normalnie rozłożone (które tak naprawdę nie są, ale zbliżają się wystarczająco - przypominam, że są to wyskalowane wersje chwil próbek, a nie same próbki), a zatem mogę na przykład oznaczyć przypadek, w którym odchylenie jest większy niż 4 - odpowiadający momentowi próbkowemu, który odbiega ponad czterokrotność błędu standardowego od momentu rozkładu. Jest mało prawdopodobne, aby zdarzyło się to losowo, jeśli generowanie próbki jest dobre. Z drugiej strony, jeśli pierwsze 10 przykładowych momentów pasuje do momentów rozkładu z dokładnością do mniej niż pół procenta, mamy dość dobre przybliżenie rozkładu.

Kluczem do tego, dlaczego obie te metody działają, jest to, że przykładowy kod generujący i kod symboliczny są prawie całkowicie rozłączne. Jeżeli zachodziłyby na siebie nakładanie się tych dwóch elementów, wówczas błąd w tym nakładaniu się mógłby objawiać się zarówno w generowaniu próbki, jak i w jej weryfikacji, a zatem nie zostałby złapany.

Bruce McCullough miał trochę chałupniczą branżę w ocenie oprogramowania statystycznego (w najszerszym tego słowa znaczeniu; testował także Microsoft Excel. I uznał to za konieczne). Dwa artykuły ilustrujące część jego podejścia znajdują się tutaj i tutaj.

Wiele szczegółów podaje Prezydent StataCorp, William Gould, w tym artykule Stata Journal. 1 To bardzo interesujący artykuł na temat kontroli jakości oprogramowania statystycznego.