Testowanie oprogramowania statystycznego

10

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.

software computing computational-statistics

— Jyotirmoy Bhattacharya
źródło

8

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\ 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. $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”.

— dsimcha
źródło

5

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:

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$
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.

— Erik P.
źródło

Dzięki za odpowiedź. „Akceptuję” drugą odpowiedź, ponieważ wolno mi wybrać tylko jedną, co wydaje się nieco lepiej pasować do mojej obecnej sytuacji. Ale twoja odpowiedź również była bardzo pomocna.

— Jyotirmoy Bhattacharya

2

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.

— Stephan Kolassa
źródło

2

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.

— pmgjones
źródło