<p>Die Standardverzerrung von numpy.cov () und numpy.var () ist inkonsistent (numpy 1.9.2).</p>

Erstellt am 4. Mai 2015  ·  5Kommentare  ·  Quelle: numpy/numpy

cov () verwendet standardmäßig einen Bias von 1.
var () verwendet standardmäßig einen Bias von 0.

So dass

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

druckt nur die zweite Zeile.

00 - Bug numpy.lib

Hilfreichster Kommentar

@rgommers Ja, "niemals gültigen Code brechen" ist eine ziemlich gute Regel.

Wie wäre es mit einer Warnung, wenn Sie cov ohne bias oder ddof aufrufen und dann das Verhalten nie ändern?

Alle 5 Kommentare

Ja. Ich weiß derzeit nicht, was wir dagegen tun können. Dieses Problem wird wahrscheinlich am besten auf der Mailingliste besprochen.

Ich möchte vorschlagen, dass es sich lohnt, dies zu beheben, auch wenn es schmerzhaft wäre.

Ich denke, der beste Standard für beide ist ddof=0 , der eine zusammenfassende Statistik berechnet, die die Daten beschreibt, im Gegensatz zu einem Schätzer.

Wenn jemand stattdessen einen unvoreingenommenen Schätzer möchte, sollte er danach fragen, indem er ddof=1 bereitstellt.

Das bedeutet, das Verhalten von cov ändern, das vermutlich weniger als var ist also gut.

Wie wäre es als ersten Schritt, wenn Sie cov eine zukünftige Warnung hinzufügen, wenn weder bias noch ddof bereitgestellt werden?

Kann ich gleichzeitig vorschlagen, bias verwerfen? Das Konzept der Verzerrung ist nur anwendbar, wenn wir Varianz und Kovarianz als Schätzer betrachten. Aber ich denke, die beste Standardeinstellung ist, diese Funktionen als beschreibende Statistiken zu betrachten, sofern uns nichts anderes gesagt wird.

Wenn ich das Gleiche anders sage, wenn ich eine einfache beschreibende Statistik möchte, ist es seltsam, nach einem voreingenommenen Schätzer zu fragen.

... von cov , was meiner Meinung nach weniger als var , also ist das gut.

Das scheint zu stimmen (zusammenfassende Nutzungsdaten von hier ):

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

Das bedeutet, das Verhalten von cov ändern

Leider glaube ich nicht, dass wir das schaffen können. Wir könnten die Funktion verwerfen und eine neue hinzufügen (was schmerzhaft wäre), aber wir sollten das Verhalten der aktuellen Funktion definitiv nicht ändern - das würde die numerischen Ergebnisse stillschweigend ändern und den aktuell gültigen Code falsch machen. Wir versuchen das niemals zu tun; Ein FutureWarning reicht nicht aus, um sicherzustellen, dass die Leute das Problem sehen.

@rgommers Ja, "niemals gültigen Code brechen" ist eine ziemlich gute Regel.

Wie wäre es mit einer Warnung, wenn Sie cov ohne bias oder ddof aufrufen und dann das Verhalten nie ändern?

Wie wäre es mit einer Warnung, wenn Sie cov ohne bias oder ddof aufrufen und dann das Verhalten nie ändern?

Das scheint eine vernünftige Sache zu sein. Besser als cov verwerfen. Das Hinzufügen von ddof=0/1 ist ein wenig ärgerlich, macht den Code jedoch verständlicher, sodass mir die Idee gefällt.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen