12 votos

Pruebas de software estadístico

¿Qué técnicas/enfoques son útiles en las pruebas de software estadístico? Estoy particularmente interesado en los programas que no paramétrico de estimación usando máxima verosimilitud.

Comparando los resultados con los de otros programas o fuentes publicadas no siempre es posible, ya que la mayoría de las veces cuando escribo un programa propio de mi es porque el cálculo que necesito no está ya implementado en un sistema existente.

Yo no soy de insistir en los métodos que se puede garantizar la exactitud. Yo sería feliz con técnicas que pueden detectar algunas fracción de errores.

8voto

Carl Russmann Puntos 1560

Una técnica útil es de monte carlo de la prueba. Si hay dos algoritmos que hacen lo mismo, implementar tanto, darles de datos aleatorios, y comprobar que (dentro de una pequeña tolerancia numérica fuzz) que producen la misma respuesta. He hecho esto varias veces antes de:

  • Escribí un eficiente pero difícil de poner en práctica $O(N\ log\ N)$ aplicación de la Tau de Kendall B. prueba en la Que escribí un muerto-50-la línea de la aplicación que corre en $O(N^2)$.

  • Escribí algo de código para hacer la regresión ridge. El mejor algoritmo para hacer esto depende de si usted está en el $n > p$ o $p > n$ de los casos, por lo que necesitaba dos algoritmos de todos modos.

En ambos casos, me estaba llevando a cabo relativamente técnicas bien conocidas en el lenguaje de programación D (para los que no la implementación existía), por lo que también se comprueba un par de resultados en contra de R. sin Embargo, el monte carlo pruebas atrapado errores que yo nunca habría cogido de otra manera.

Otra buena prueba se afirma. Usted no puede saber exactamente lo que los resultados correctos de su cálculo debe ser, pero eso no significa que usted no puede realizar las comprobaciones de estado en las distintas etapas de la computación. En la práctica, si usted tiene un montón de estos en el código y todos ellos pasan, a continuación, el código es generalmente a la derecha.

Edit: Un tercer método es alimentar el algoritmo de datos (sintético o real) donde se sabe que al menos aproximadamente lo que la respuesta correcta es, incluso si usted no sabe exactamente, y ver por inspección si la respuesta es razonable. Por ejemplo, usted no puede saber exactamente lo que las estimaciones de los parámetros son, pero usted puede saber cuáles se supone que son "grandes" y que se supone que debe ser "pequeño".

6voto

No estoy seguro si esto es realmente una respuesta a su pregunta, pero al menos tangencialmente relacionados.

I mantener las Estadísticas de paquetes de Maple. Un interesante ejemplo de la difícil prueba de código se muestra aleatoria de generación de acuerdo a las diferentes distribuciones; es fácil probar que no se generan errores, pero es más complicado de determinar si las muestras que se generan conforme a la solicitud de distribución "suficientemente bien". Desde el Arce tiene simbólico y numérico de las características, puede utilizar algunas de las características simbólicos para probar la (puramente numérico) de la muestra de la generación:

  1. Hemos implementado un par de tipos de pruebas de hipótesis estadísticas, uno de los cuales es el de la chi cuadrado modelo adecuado de la prueba - una prueba de la chi cuadrado de los números de las muestras en recipientes de determina a partir de la inversa de la CDF de la distribución de probabilidad. Así, por ejemplo, a prueba de Cauchy distribución de la muestra de la generación, me encuentro con algo como

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

    Porque me puede llegar a generar una gran muestra de como me gusta, puedo hacer de $\alpha$ muy pequeño.

  2. Para distribuciones finito momentos, calculo, por un lado, un número de muestra momentos, y por otro lado, me simbólicamente calcular el correspondiente distribución de momentos y su error estándar. Así, por ejemplo, la distribución 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);
    

    Esto muestra una disminución en la lista de los números, el último de los cuales es 255.1085766. Así que, incluso para el 10 de momento, el valor del momento es de más de 250 veces el valor del error estándar de la muestra momento para una muestra de tamaño $10^6$. Esto significa que se puede aplicar una prueba de que funciona más o menos como sigue:

    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;
    

    Los números en distributionMoments y standardErrors provienen de la primera ejecución por encima. Ahora bien, si la muestra de generación es correcta, los números de las desviaciones deben ser relativamente pequeños. Supongo que son aproximadamente distribuidos normalmente (que realmente no son, pero es lo suficiente - recordar estas son versiones a escala de la muestra momentos, no se la muestras a sí mismos) y por lo tanto, puedo, por ejemplo, la bandera de un caso en el que una desviación es mayor de 4 - correspondiente a una muestra momento en que se desvía más de cuatro veces el error estándar de la distribución momento. Esto es muy poco probable que ocurra al azar si la muestra de generación es bueno. Por otro lado, si los 10 primeros de la muestra momentos coinciden con la distribución de momentos para dentro de menos de la mitad de un por ciento, tenemos una aproximación bastante buena de la distribución.

La clave de por qué ambos de estos métodos de trabajo es que la muestra de generación de código y el código simbólico son casi completamente distinto. Si no hay solapamiento entre los dos, luego de un error en el que se superponen podría manifestarse tanto en la muestra de la generación y en su verificación, y por lo tanto no ser atrapado.

3voto

icelava Puntos 548

Bruce McCullough tenía un poco de una industria artesanal en la evaluación de software estadístico (en el sentido más amplio; también probado de Microsoft Excel. Y pareció querer). Dos documentos que ilustran parte de su enfoque están aquí y aquí.

2voto

pmgjones Puntos 2372

Una gran cantidad de detalles, está dado por el Presidente de StataCorp, William Gould, en este Stata artículo de Revista.1 es un artículo muy interesante sobre el control de calidad de software estadístico.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X