<p>El sesgo predeterminado de numpy.cov () y numpy.var () son inconsistentes (numpy 1.9.2)</p>

Creado en 4 may. 2015 · 5Comentarios · Fuente: numpy/numpy

cov () usa un sesgo de 1 por defecto.
var () usa un sesgo de 0 por defecto.

Tal que

import numpy as np

x = np.random.rand(100)

if np.isclose(np.cov([x,x])[0,0], np.var(x)):
    print("Consistent by default.")

if np.isclose(np.cov([x,x],ddof=0)[0,0], np.var(x,ddof=0))
    print("Consistent.")

solo imprimirá la segunda línea.

00 - Bug numpy.lib

Fuente

jg-you

👍1

Comentario más útil

@rgommers Sí, "nunca romper un código válido" es una regla bastante buena.

¿Qué tal una advertencia si llama a cov sin bias o ddof , y luego nunca cambia el comportamiento?

AllenDowney en 23 sept. 2020

👍3 ❤2

Todos 5 comentarios

Si. No sé qué podemos hacer al respecto en este momento. Probablemente, este tema se debata mejor en la lista de correo.

charris en 14 may. 2015

Me gustaría sugerir que vale la pena arreglar esto, por doloroso que sea.

Creo que el mejor valor predeterminado para ambos es ddof=0 , que calcula una estadística de resumen que describe los datos, en contraste con un estimador.

Si alguien quiere un estimador imparcial en su lugar, debe solicitarlo proporcionando ddof=1 .

Eso significa cambiar el comportamiento de cov , que supongo que se usa menos de var , así que eso es bueno.

Como primer paso, ¿qué tal si se agrega una advertencia futura a cov si no se proporciona bias ni ddof ?

Al mismo tiempo, ¿puedo sugerir la desaprobación de bias ? El concepto de sesgo solo es aplicable si pensamos en la varianza y la covarianza como estimadores. Pero, de nuevo, creo que lo mejor por defecto es pensar en estas funciones como estadísticas descriptivas, a menos que nos digan lo contrario.

Dicho lo mismo de otra manera, si lo que quiero es una estadística descriptiva simple, es extraño pedir un estimador sesgado.

AllenDowney en 23 sept. 2020

... de cov , que supongo que se usa menos de var , así que eso es bueno.

Eso parece ser cierto (datos de uso resumidos de aquí ):

def cov(
    m: object,
    y: object = ...,
    rowvar: Union[float, bool, int] = ...,
    bias: Union[float, int, bool] = ...,
    aweights: numpy.ndarray = ...,
):
    """
    usage.dask: 11
    usage.matplotlib: 3
    usage.pandas: 7
    usage.scipy: 21
    usage.sklearn: 24
    """

def var(
    a: object,
    axis: Union[int, None, Tuple[Union[int, None], ...]] = ...,
    out: Union[dask.dataframe.core.Scalar, dask.dataframe.core.Series] = ...,
    keepdims: bool = ...,
    dtype: Union[Literal["i8", "f8"], Type[float], None] = ...,
    ddof: int = ...,
):
    """
    usage.dask: 59
    usage.pandas: 13
    usage.scipy: 19
    usage.sklearn: 55
    usage.xarray: 31
    """

Eso significa cambiar el comportamiento de cov

Desafortunadamente, no creo que podamos hacer eso. Podríamos desaprobar la función y agregar una nueva (lo cual sería doloroso), pero definitivamente no deberíamos cambiar el comportamiento de la función actual, eso cambiaría silenciosamente los resultados numéricos y haría que el código válido actualmente sea incorrecto. Tratamos de nunca hacer eso; un FutureWarning no es suficiente para garantizar que la gente vea el problema.

rgommers en 23 sept. 2020

@rgommers Sí, "nunca romper un código válido" es una regla bastante buena.

¿Qué tal una advertencia si llama a cov sin bias o ddof , y luego nunca cambia el comportamiento?

AllenDowney en 23 sept. 2020

👍3 ❤2

¿Qué tal una advertencia si llama a cov sin bias o ddof , y luego nunca cambia el comportamiento?

Eso sí parece algo razonable. Mejor que depreciar cov . Tener que agregar ddof=0/1 es una pequeña molestia pero hace que el código sea más comprensible, así que me gusta la idea.

rgommers en 23 sept. 2020

¿Fue útil esta página

0 / 5 - 0 calificaciones