<p>A tendência padrão numpy.cov () e numpy.var () é inconsistente (numpy 1.9.2)</p>

Criado em 4 mai. 2015 · 5Comentários · Fonte: numpy/numpy

cov () usa um bias de 1 por padrão.
var () usa um bias de 0 por padrão.

De tal modo 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.")

imprimirá apenas a segunda linha.

00 - Bug numpy.lib

Fonte

jg-you

👍1

Comentários muito úteis

@rgommers Sim, "nunca quebre um código válido" é uma regra muito boa.

Que tal um aviso se você chamar cov sem bias ou ddof e nunca mudar o comportamento?

AllenDowney em 23 set. 2020

👍3 ❤2

Todos 5 comentários

Sim. Não sei o que podemos fazer sobre isso neste momento. Este assunto é provavelmente melhor discutido na lista de discussão.

charris em 14 mai. 2015

Gostaria de sugerir que vale a pena consertar isso, por mais doloroso que seja.

Acho que o melhor padrão para ambos é ddof=0 , que calcula uma estatística resumida que descreve os dados, em comparação com um estimador.

Se alguém quiser um estimador imparcial, deve solicitá-lo fornecendo ddof=1 .

Isso significa mudar o comportamento de cov , que eu acho que é usado menos de var , então isso é bom.

Como primeiro passo, que tal adicionar um aviso futuro a cov se nem bias nem ddof forem fornecidos?

Ao mesmo tempo, posso sugerir o uso de bias ? O conceito de viés só é aplicável se pensarmos em variância e covariância como estimadores. Mas, novamente, acho que o melhor padrão é pensar nessas funções como estatísticas descritivas, a menos que seja dito o contrário.

Dizendo a mesma coisa de maneira diferente, se o que eu quero é uma estatística descritiva simples, é estranho pedir um estimador enviesado.

AllenDowney em 23 set. 2020

... de cov , que eu acho que é usado menos de var , então isso é bom.

Isso parece ser verdade (dados de uso resumidos aqui ):

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
    """

Isso significa mudar o comportamento de cov

Infelizmente, não acho que podemos fazer isso. Poderíamos descontinuar a função e adicionar uma nova (o que seria doloroso), mas definitivamente não devemos mudar o comportamento da função atual - isso mudaria silenciosamente os resultados numéricos e tornaria o código válido atualmente errado. Tentamos nunca fazer isso; FutureWarning não é suficiente para garantir que as pessoas vejam o problema.

rgommers em 23 set. 2020

@rgommers Sim, "nunca quebre um código válido" é uma regra muito boa.

Que tal um aviso se você chamar cov sem bias ou ddof e nunca mudar o comportamento?

AllenDowney em 23 set. 2020

👍3 ❤2

Que tal um aviso se você chamar cov sem bias ou ddof e nunca mudar o comportamento?

Isso parece uma coisa razoável a se fazer. Melhor do que descontinuar cov . Ter que adicionar ddof=0/1 é um pequeno aborrecimento, mas torna o código mais compreensível, por isso gosto da ideia.

rgommers em 23 set. 2020

Esta página foi útil?

0 / 5 - 0 avaliações