Test di software statistico

10

Quali tecniche / approcci sono utili nel test di software statistico? Sono particolarmente interessato ai programmi che eseguono stime parametriche utilizzando la massima probabilità.

Confrontare i risultati con quelli di altri programmi o fonti pubblicate non è sempre possibile poiché la maggior parte delle volte quando scrivo un mio programma è perché il calcolo di cui ho bisogno non è già implementato in un sistema esistente.

Non insisto su metodi che possano garantire la correttezza. Sarei felice con le tecniche che possono rilevare una piccola parte degli errori.

software computing computational-statistics

— Jyotirmoy Bhattacharya
fonte

8

Una tecnica utile è il test Monte Carlo. Se ci sono due algoritmi che fanno la stessa cosa, implementano entrambi, forniscono loro dati casuali e controllano che (entro una piccola tolleranza per il fuzz numerico) producano la stessa risposta. L'ho già fatto più volte:

Ho scritto un'implementazione efficiente ma difficile da implementare del Tau B. di Kendall Per testarla ho scritto un'implementazione a 50 righe semplicissima che correva in . $O(N\ log\ N)$ $O(N^2)$
Ho scritto del codice per eseguire la regressione della cresta. L'algoritmo migliore per farlo dipende dal fatto che tu sia nel caso o , quindi avevo bisogno di due algoritmi comunque. $n > p$ $p > n$

In entrambi i casi stavo implementando tecniche relativamente conosciute nel linguaggio di programmazione D (per il quale non esisteva alcuna implementazione), quindi ho anche verificato alcuni risultati contro R. Tuttavia, il test Monte Carlo ha rilevato bug che non avrei mai scoperto altrimenti .

Un altro buon test è afferma . Potresti non sapere esattamente quali dovrebbero essere i risultati corretti del tuo calcolo, ma ciò non significa che non puoi eseguire controlli di integrità nelle varie fasi del calcolo. In pratica se ne hai molti nel tuo codice e tutti passano, allora il codice è di solito giusto.

Modifica: un terzo metodo è quello di alimentare i dati dell'algoritmo (sintetici o reali) in cui si conosce almeno approssimativamente qual è la risposta giusta, anche se non si conosce esattamente, e vedere dall'ispezione se la risposta è ragionevole. Ad esempio, potresti non sapere esattamente quali sono le stime dei tuoi parametri, ma potresti sapere quali dovrebbero essere "grandi" e quali dovrebbero essere "piccoli".

— dsimcha
fonte

5

Non sono sicuro che questa sia davvero una risposta alla tua domanda, ma è almeno tangenzialmente correlata.

Mantengo il pacchetto di statistiche in Maple . Un esempio interessante di codice difficile da testare è la generazione casuale di campioni in base a diverse distribuzioni; è facile verificare che non vengano generati errori, ma è più difficile determinare se i campioni generati sono conformi alla distribuzione richiesta "abbastanza bene". Poiché Maple ha sia caratteristiche simboliche che numeriche, puoi usare alcune delle caratteristiche simboliche per testare la generazione (puramente numerica) del campione:

Abbiamo implementato alcuni tipi di test statistici di ipotesi, uno dei quali è il test del modello adatto del chi quadrato - un test del chi quadrato del numero di campioni in contenitori determinati dal CDF inverso della distribuzione di probabilità data. Quindi, per esempio, per testare la generazione del campione di distribuzione di Cauchy, eseguo qualcosa del genere
```
with(Statistics):
infolevel[Statistics] := 1:
distribution := CauchyDistribution(2, 3):
sample := Sample(distribution, 10^6):
ChiSquareSuitableModelTest(sample, distribution, 'bins' = 100, 'level' = 0.001);
```
Dato che posso generare un campione grande quanto mi pare, posso rendere piuttosto piccolo. $\alpha$
Per le distribuzioni con momenti finiti, computo da un lato un numero di momenti campione e, dall'altro, calcolo simbolicamente i corrispondenti momenti di distribuzione e il loro errore standard. Ad esempio, per la distribuzione 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);
```
Questo mostra un elenco decrescente di numeri, l'ultimo dei quali è 255.1085766. Quindi, anche per il decimo momento, il valore del momento è più di 250 volte il valore dell'errore standard del momento del campione per un campione di dimensioni . Ciò significa che posso implementare un test che viene eseguito più o meno come segue: $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;
```
I numeri entrano distributionMomentse standardErrorsvengono dalla prima corsa sopra. Ora, se la generazione del campione è corretta, i numeri nelle deviazioni dovrebbero essere relativamente piccoli. Presumo che siano approssimativamente distribuiti normalmente (cosa che non sono realmente, ma si avvicina abbastanza - ricordo che si tratta di versioni ridimensionate di momenti campione, non dei campioni stessi) e quindi posso, ad esempio, contrassegnare un caso in cui si trova una deviazione maggiore di 4 - corrispondente a un momento del campione che devia più di quattro volte l'errore standard dal momento della distribuzione. È molto improbabile che ciò accada a caso se la generazione del campione è buona. D'altra parte, se i primi 10 momenti di campionamento corrispondono a quelli di distribuzione entro meno del mezzo percento, abbiamo una buona approssimazione della distribuzione.

La chiave del perché entrambi questi metodi funzionano è che il codice di generazione del campione e il codice simbolico sono quasi completamente disgiunti. Se ci fosse una sovrapposizione tra i due, un errore in quella sovrapposizione potrebbe manifestarsi sia nella generazione del campione che nella sua verifica, e quindi non essere colto.

— Erik P.
fonte

Grazie per la tua risposta. Sto "accettando" l'altra risposta dato che mi è permesso sceglierne solo una e che sembrava adattarsi leggermente meglio alla mia situazione attuale. Ma anche la tua risposta è stata molto utile.

— Jyotirmoy Bhattacharya,

2

Bruce McCullough aveva un po 'un settore industriale nella valutazione del software statistico (nel senso più ampio; ha anche testato Microsoft Excel. E l'ha trovato carente). Due articoli che illustrano parte del suo approccio sono qui e qui.

— Stephan Kolassa
fonte

2

Molti dettagli sono forniti dal presidente di StataCorp, William Gould, in questo articolo dello Stata Journal. 1 È un articolo molto interessante sul controllo di qualità del software statistico.

— pmgjones
fonte