<p>Les biais par défaut de numpy.cov () et numpy.var () sont incohérents (numpy 1.9.2)</p>

Créé le 4 mai 2015 · 5Commentaires · Source: numpy/numpy

cov () utilise un biais de 1 par défaut.
var () utilise un biais de 0 par défaut.

Tel 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.")

n'imprimera que la deuxième ligne.

00 - Bug numpy.lib

Source

jg-you

👍1

Commentaire le plus utile

@rgommers Oui, "ne jamais casser le code valide" est une très bonne règle.

Que diriez-vous d'un avertissement si vous appelez cov sans bias ou ddof , puis ne changez jamais le comportement?

AllenDowney le 23 sept. 2020

👍3 ❤2

Tous les 5 commentaires

Oui. Je ne sais pas ce que nous pouvons faire à ce sujet pour le moment. Ce problème est probablement mieux discuté sur la liste de diffusion.

charris le 14 mai 2015

Je voudrais suggérer que cela vaut la peine d'être corrigé, aussi douloureux que cela puisse être.

Je pense que le meilleur défaut pour les deux est ddof=0 , qui calcule une statistique récapitulative qui décrit les données, par opposition à un estimateur.

Si quelqu'un veut plutôt un estimateur non biaisé, il devrait le demander en fournissant ddof=1 .

Cela signifie changer le comportement de cov , qui, je suppose, est utilisé moins de var , donc c'est bien.

Dans un premier temps, que diriez-vous d'ajouter un futur avertissement à cov si ni bias ni ddof n'est fourni?

En même temps, puis-je suggérer de déprécier bias ? Le concept de biais n'est applicable que si nous considérons la variance et la covariance comme des estimateurs. Mais encore une fois, je pense que le meilleur défaut est de considérer ces fonctions comme des statistiques descriptives, sauf indication contraire.

En disant la même chose d'une manière différente, si je veux une simple statistique descriptive, il est étrange de demander un estimateur biaisé.

AllenDowney le 23 sept. 2020

... de cov , qui, je suppose, est utilisé moins de var , donc c'est bien.

Cela semble être vrai (données d'utilisation résumées d' ici ):

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

Cela signifie changer le comportement de cov

Malheureusement, je ne pense pas que nous puissions faire cela. Nous pourrions désapprouver la fonction et en ajouter une nouvelle (ce qui serait pénible), mais nous ne devrions certainement pas changer le comportement de la fonction actuelle - cela changerait silencieusement les résultats numériques et rendrait le code actuellement valide erroné. Nous essayons de ne jamais faire cela; un FutureWarning n'est pas suffisant pour garantir que les gens voient le problème.

rgommers le 23 sept. 2020

@rgommers Oui, "ne jamais casser le code valide" est une très bonne règle.

Que diriez-vous d'un avertissement si vous appelez cov sans bias ou ddof , puis ne changez jamais le comportement?

AllenDowney le 23 sept. 2020

👍3 ❤2

Que diriez-vous d'un avertissement si vous appelez cov sans bias ou ddof , puis ne changez jamais le comportement?

Cela semble être une chose raisonnable à faire. Mieux que déprécier cov . Avoir à ajouter ddof=0/1 est un léger ennui mais rend le code plus compréhensible, donc j'aime l'idée.

rgommers le 23 sept. 2020

Cette page vous a été utile?

0 / 5 - 0 notes