Scikit-learn: MSE ist negativ, wenn es von cross_val_score zurückgegeben wird

Erstellt am 12. Sept. 2013  ·  58Kommentare  ·  Quelle: scikit-learn/scikit-learn

Der von sklearn.cross_validation.cross_val_score zurückgegebene mittlere quadratische Fehler ist immer negativ. Obwohl dies eine geplante Entscheidung ist, mit der die Ausgabe dieser Funktion bei bestimmten Hyperparametern zur Maximierung verwendet werden kann, ist es äußerst verwirrend, wenn cross_val_score direkt verwendet wird. Zumindest habe ich mich gefragt, wie der Mittelwert eines Quadrats möglicherweise negativ sein kann, und dachte, dass cross_val_score nicht richtig funktioniert oder die angegebene Metrik nicht verwendet. Erst nachdem ich den sklearn-Quellcode eingegraben hatte, stellte ich fest, dass das Zeichen umgedreht war.

Dieses Verhalten wird in make_scorer in scorer.py erwähnt, jedoch nicht in cross_val_score, und ich denke, es sollte so sein, da die Leute sonst denken, dass cross_val_score nicht richtig funktioniert.

API Bug Documentation

Hilfreichster Kommentar

Vielleicht würde Negmse das Problem lösen

Alle 58 Kommentare

Sie beziehen sich auf

greater_is_better : boolean, default=True

Whether score_func is a score function (default), meaning high is good, 
or a loss function, meaning low is good. In the latter case, the scorer 
object will sign-flip the outcome of the score_func.

in http://scikit-learn.org/stable/modules/generated/sklearn.metrics.make_scorer.html
? (nur als Referenz)

Ich bin damit einverstanden, dass dies in cross_val_score-Dokumenten klarer sein kann

Vielen Dank für die Berichterstattung

In der Tat haben wir dieses Problem beim Refactoring des Scorers übersehen. Folgendes ist sehr kontraintuitiv:

>>> import numpy as np
>>> from sklearn.datasets import load_boston
>>> from sklearn.linear_model import RidgeCV
>>> from sklearn.cross_validation import cross_val_score

>>> boston = load_boston()
>>> np.mean(cross_val_score(RidgeCV(), boston.data, boston.target, scoring='mean_squared_error'))
-154.53681864311497

/ cc @larsmans

Übrigens stimme ich nicht zu, dass es sich um ein Dokumentationsproblem handelt. Es ist cross_val_score sollte den Wert mit dem Vorzeichen zurückgeben, das dem Scoring-Namen entspricht. Idealerweise sollte auch GridSearchCV(*params).fit(X, y).best_score_ konsistent sein. Ansonsten ist die API sehr verwirrend.

Ich stimme auch zu, dass eine Änderung zur Rückgabe der tatsächlichen MSE ohne umgeschaltetes Vorzeichen die bessere Option wäre.

Das Scorer-Objekt könnte nur das greater_is_better -Flag speichern, und wenn der Scorer verwendet wird, könnte das Zeichen umgedreht werden, falls es benötigt wird, z. B. in GridSearchCV .

Ich bin damit einverstanden, dass wir hier ein Usability-Problem haben, aber ich stimme der Lösung von @ogrisel , die wir sollten, nicht vollständig zu

Geben Sie den Wert mit dem Vorzeichen zurück, das dem Bewertungsnamen entspricht

denn das ist auf lange Sicht ein unzuverlässiger Hack. Was ist, wenn jemand einen benutzerdefinierten Scorer mit einem Namen wie mse ? Was ist, wenn sie dem Namensmuster folgen, den Scorer jedoch in einen Dekorateur einwickeln, der den Namen ändert?

Das Scorer-Objekt könnte einfach das Flag "Greater_is_better" speichern, und wenn der Scorer verwendet wird, kann das Zeichen bei Bedarf umgedreht werden, z. B. in GridSearchCV.

Dies ist, was Scorer ursprünglich während der Entwicklung zwischen den Versionen 0.13 und 0.14 getan haben, und es hat ihre Definition viel schwieriger gemacht. Es machte es auch schwierig, dem Code zu folgen, da das Attribut greater_is_better im Scorer-Code zu verschwinden schien und nur in der Mitte des Rastersuchcodes wieder angezeigt wurde. Eine spezielle Scorer -Klasse wurde benötigt, um etwas zu tun, was im Idealfall eine einfache Funktion tun würde.

Ich glaube, wenn wir die Ergebnisse optimieren wollen, sollten sie maximiert werden. Aus Gründen der Benutzerfreundlichkeit denke ich, dass wir einen Parameter score_is_loss["auto", True, False] einführen könnten, der nur die Anzeige der Ergebnisse ändert und eine Heuristik verwenden kann, die auf den integrierten Namen basiert.

Das war eine eilige Antwort, weil ich aus dem Zug steigen musste. Was ich mit "Anzeige" gemeint habe, ist wirklich der Rückgabewert von cross_val_score . Ich denke, die Torschützen sollten einfach und einheitlich sein und die Algorithmen sollten immer maximiert werden.

Dies führt zu einer Asymmetrie zwischen integrierten und benutzerdefinierten Scorern.

Ping @GaelVaroquaux.

Ich mag die score_is_loss-Lösung oder etwas in diesem Sinne. Der Vorzeichenwechsel, der mit dem Scoring-Namen übereinstimmt, scheint schwer zu pflegen zu sein, könnte Probleme verursachen, wie @larsmans erwähnte

Was ist die Schlussfolgerung, für welche Lösung sollten wir uns entscheiden? :) :)

@tdomhan @jaquesgrobler @larsmans Wissen Sie, ob dies auch für r2 ? Ich stelle fest, dass die von GridSearchCV r2 Scores auch für ElasticNet , Lasso und Ridge meistens negativ sind.

R² kann entweder positiv oder negativ sein, und negativ bedeutet einfach, dass Ihr Modell eine sehr schlechte Leistung erbringt.

IIRC, @GaelVaroquaux war ein Befürworter der Rückgabe einer negativen Zahl, wenn greater_is_better=False .

r2 ist eine Bewertungsfunktion (größer ist besser), die positiv sein sollte, wenn Ihr Modell gut ist - aber es ist eine der wenigen Leistungsmetriken, die tatsächlich negativ sein können, dh schlechter als 0.

Was ist der Konsens zu diesem Thema? Meiner Meinung nach ist cross_val_score ein Bewertungswerkzeug, kein Modellauswahlwerkzeug. Es sollte daher die ursprünglichen Werte zurückgeben.

Ich kann es in meinem PR # 2759 beheben, da die von mir vorgenommenen Änderungen die Behebung sehr einfach machen. Der Trick besteht darin, das Zeichen nicht im Voraus umzudrehen, sondern greater_is_better Rastersuche auf das Attribut

Was ist der Konsens zu diesem Thema? Meiner Meinung nach ist cross_val_score
ein Bewertungswerkzeug, kein Modellauswahlwerkzeug. Es sollte also zurückkehren
die ursprünglichen Werte.

Sonderfälle sind unterschiedliche Verhaltensweisen, die zu Problemen in der Software führen.

Ich denke einfach, dass wir "mse" in "negated_mse" in der Liste umbenennen sollten
von akzeptablen Scoring-Saiten.

Was ist, wenn jemand einen benutzerdefinierten Scorer mit einem Namen wie mse definiert? Was ist, wenn sie dem Namensmuster folgen, den Scorer jedoch in einen Dekorateur einwickeln, der den Namen ändert?

Ich glaube nicht, dass @ogrisel vorgeschlagen hat , übereinzustimmen . Korrigieren Sie mich, wenn ich falsch liege @ogrisel.

Ich denke einfach, dass wir "mse" in "negated_mse" in der Liste der akzeptablen Bewertungszeichenfolgen umbenennen sollten.

Das ist völlig unintuitiv, wenn Sie die Interna von Scikit-Learn nicht kennen. Wenn Sie das System so biegen müssen, ist dies meiner Meinung nach ein Zeichen dafür, dass ein Designproblem vorliegt.

Das ist völlig unintuitiv, wenn Sie die Interna von Scikit-Learn nicht kennen.
Wenn Sie das System so biegen müssen, denke ich, dass es ein Zeichen dafür ist, dass es ein gibt
Designproblem.

Ich stimme dir nicht zu. Menschen verstehen Dinge mit viel Vorwissen und
Kontext. Sie sind alles andere als systematisch. Der Versuch, dies in Software einzubetten
gibt Einkaufslisten wie eine Reihe von Sonderfällen. Das macht es nicht nur
Software schwer zu warten, aber es bedeutet auch, dass Menschen, die nicht haben
Denken Sie daran, dass diese Ausnahmen auf überraschende Verhaltensweisen stoßen und fehlerhaft schreiben
Code über die Bibliothek.

Welchen Sonderfall haben Sie im Sinn?

Um klar zu sein, denke ich, dass die im Objekt GridSearchCV gespeicherten Kreuzvalidierungsergebnisse _auch_ die ursprünglichen Werte sein sollten (nicht mit umgedrehtem Vorzeichen).

AFAIK, das Umdrehen des Zeichens, wurde eingeführt, um die Implementierung der Rastersuche ein wenig zu vereinfachen, sollte aber die Benutzerfreundlichkeit nicht beeinträchtigen.

Welchen Sonderfall haben Sie im Sinn?

Nun, die Tatsache, dass für einige Metriken größer ist, ist besser, während für andere
es ist das Gegenteil.

AFAIK, das Umdrehen des Zeichens wurde eingeführt, um die Rastersuche durchzuführen
Implementierung etwas einfacher, sollte aber nicht beeinflussen
Benutzerfreundlichkeit.

Es geht nicht um die Rastersuche, es geht um die Trennung von Bedenken: Punktzahlen
müssen verwendbar sein, ohne etwas über sie zu wissen, oder Code zu
Der Umgang mit ihren Besonderheiten wird sich auf die gesamte Codebasis ausbreiten. Es gibt
schon viel Scoring-Code.

Aber das verschiebt das Problem etwas auf Benutzercode. Niemand möchte "negierte MSE" zeichnen, daher müssen Benutzer Zeichen in ihrem Code zurückdrehen. Dies ist unpraktisch, insbesondere bei Kreuzvalidierungsberichten mit mehreren Metriken (PR # 2759), da Sie jede Metrik einzeln behandeln müssen. Ich frage mich, ob wir das Beste aus beiden Welten haben können: generischen Code und intuitive Ergebnisse.

Aber das verschiebt das Problem etwas auf Benutzercode. Niemand will
um "negierte MSE" zu zeichnen, müssen Benutzer Zeichen in ihre zurückblättern
Code.

Mit Sicherheit nicht das Ende der Welt. Beachten Sie, dass beim Lesen von Papieren oder
Beim Betrachten von Präsentationen habe ich das gleiche Problem: Wenn das Diagramm nicht ist
Gut gemacht, ich verliere ein bisschen Zeit und mentale Bandbreite, um es zu versuchen
Figur, ob größer besser ist oder nicht.

Dies ist unpraktisch, insbesondere bei der Kreuzvalidierung mit mehreren Metriken
Berichte (PR # 2759), da Sie jede Metrik einzeln behandeln müssen.

Warum. Wenn Sie nur akzeptieren, dass es immer größer ist, ist es besser
alles einfacher, einschließlich der Interpretation der Ergebnisse.

Ich frage mich, ob wir das Beste aus beiden Welten haben können: generischen Code und
intuitive Ergebnisse.

Das Risiko besteht darin, einen sehr komplexen Code zu haben, der uns für die Wartung verlangsamt
und Entwicklung. Scikit-Learn nimmt zu.

Wenn Sie nur akzeptieren, dass es immer größer ist, ist es besser

Das hat sie gesagt :)

Im Ernst, ich denke, ein Grund, warum dies die Leute verwirrt, ist, dass die Ausgabe von cross_val_score nicht mit den Metriken übereinstimmt. Wenn wir Ihrer Logik folgen, sollten alle Metriken in sklearn.metrics "größer ist besser" folgen.

Das hat sie gesagt :)

Schön!

Im Ernst, ich denke, ein Grund, warum dies die Leute verwirrt, ist, dass
Die Ausgabe von cross_val_score stimmt nicht mit den Metriken überein. Wenn wir
Folgen Sie Ihrer Logik, alle Metriken in sklearn.metrics sollten "größer" folgen
ist besser".

Einverstanden. Deshalb gefällt mir die Idee, den Namen zu ändern: Es würde auftauchen
in die Augen der Menschen.

Im Ernst, ich denke, ein Grund, warum dies die Leute verwirrt, ist, dass die Ausgabe von cross_val_score nicht mit den Metriken übereinstimmt.

Und dies wiederum lässt scoring mysteriöser erscheinen als es ist.

Wurde heute in 0.16.1 davon gebissen, als ich versuchte, eine lineare Regression durchzuführen. Während das Vorzeichen der Punktzahl für Klassifikatoren anscheinend nicht mehr umgedreht wird, wird es für die lineare Regression immer noch umgedreht. Um die Verwirrung zu vergrößern, gibt LinearRegression.score () eine nicht gespiegelte Version der Partitur zurück.

Ich würde vorschlagen, alles konsistent zu machen und die Punktzahl ohne Vorzeichen auch für lineare Modelle zurückzugeben.

Beispiel:

from sklearn import linear_model
from sklearn.naive_bayes import GaussianNB
from sklearn import cross_validation
from sklearn import datasets
iris = datasets.load_iris()
nb = GaussianNB()
scores = cross_validation.cross_val_score(nb, iris.data, iris.target)
print("NB score:\t  %0.3f" % scores.mean() )

iris_reg_data = iris.data[:,:3]
iris_reg_target = iris.data[:,3]
lr = linear_model.LinearRegression()
scores = cross_validation.cross_val_score(lr, iris_reg_data, iris_reg_target)
print("LR score:\t %0.3f" % scores.mean() )

lrf = lr.fit(iris_reg_data, iris_reg_target)
score = lrf.score(iris_reg_data, iris_reg_target)
print("LR.score():\t  %0.3f" % score )

Das gibt:

NB score:     0.934    # sign is not flipped
LR score:    -0.755    # sign is flipped
LR.score():   0.938    # sign is not flipped

Durch die Kreuzvalidierung werden alle Anzeichen von Modellen umgedreht, bei denen größer besser ist. Ich bin immer noch nicht mit dieser Entscheidung einverstanden. Ich denke, der Hauptbefürworter war @GaelVaroquaux und vielleicht @mblondel [Ich erinnerte mich, dass Sie den Scorer-Code

Oh egal, die ganze Diskussion ist oben.
Ich habe das Gefühl, dass das Vorzeichen in mse standardmäßig umgedreht wird und r2 noch weniger intuitiv ist: - /

@ Huitzilo GaussianNB ist ein Klassifikator und verwendet Genauigkeit als Standard-Scorer. LinearRegression ist ein Regressor und verwendet den r2-Score als Standard-Scorer. Die zweite Punktzahl ist negativ, aber denken Sie daran, dass die r2-Punktzahl negativ sein kann. Außerdem ist Iris ein Datensatz mit mehreren Klassen. Daher sind die Ziele kategorisch. Sie können keinen Regressor verwenden.

richtig, ich war ein bisschen verwirrt darüber, was passiert, r2 wird nicht umgedreht ... nur mse wäre.

Vielleicht besteht eine Lösung für das ganze Problem darin, das Ding negmse umzubenennen?

@mblondel natürlich hast du recht, sorry. Ich habe gerade schnell ein Beispiel für eine Regression zusammengestellt, und in meinem übermäßigen Vertrauen in die Irisdaten dachte ich, dass die Vorhersage von Merkmal Nr. 4 von den anderen funktionieren würde (mit positivem R2). Aber es war daher kein negatives R2. Hier kippt kein Schild. IN ORDNUNG. Mein Fehler.

Trotzdem ist das Zeichen in der MSE umgedreht, die ich von cross_val_score bekomme.

Vielleicht bin ich es nur, aber ich finde diese Inkonsistenz äußerst verwirrend (was mich zu diesem Thema gebracht hat). Warum sollte MSE mit einem Vorzeichen versehen werden, nicht jedoch R2?

Vielleicht bin ich es nur, aber ich finde diese Inkonsistenz äußerst verwirrend (was mich zu diesem Thema gebracht hat). Warum sollte MSE mit einem Vorzeichen versehen werden, nicht jedoch R2?

Weil die Semantik der Punktzahl höher ist, ist sie besser. Hohe MSE ist schlecht.

Vielleicht würde Negmse das Problem lösen

@amueller Ich stimme zu, das explizite

Vielleicht könnte die Dokumentation unter [1] auch noch expliziter darüber sein, wie sich die Zeichen für einige Partituren drehen. In meinem Fall brauchte ich schnell Informationen und schaute nur in die Tabelle unter 3.1.1.1, las aber den Text nicht (was das Prinzip "Größer ist besser" erklärt). IMHO würde das Hinzufügen eines Kommentars für mse, Median und mittleren absoluten Fehler in der Tabelle unter 3.1.1.1, der deren Negation angibt, bereits viel helfen, ohne dass Änderungen am tatsächlichen Code vorgenommen würden.

[1] http://scikit-learn.org/stable/modules/model_evaluation.html#scoring -parameter

Ich bin auf einen sehr interessanten Fall gestoßen:

from sklearn.cross_validation import cross_val_score
model = LinearRegression()
scores = cross_val_score(model, X, target, cv=2, scoring='r2')
scores

Ergebnisse in

array([-0.17026282, -2.21315179])

Für denselben Datensatz den folgenden Code

model = LinearRegression()
model.fit(X, target)
prediction = model.predict(X)
print r2_score(target, prediction)

ergibt einen angemessenen Wert

0.353035789318

AFAIK für lineares Regressionsmodell (mit Achsenabschnitt) kann man nicht R ^ 2> 1 oder R ^ 2 <0 erhalten

Daher sieht das Lebenslaufergebnis nicht wie R ^ 2 mit einem umgedrehten Vorzeichen aus. Liege ich irgendwann falsch

r2 kann negativ sein (für schlechte Modelle). Es kann nicht größer als 1 sein.

Sie sind wahrscheinlich überpassend. Versuchen:

from sklearn.cross_validation import train_test_split

X_train, X_test, y_train, y_test = train_test_split(X, target, test_size=0.2, random_state=0)
model = LinearRegression()
model.fit(X_train, y_train)
pred_train = model.predict(X_train)
print("train r2: %f" % r2_score(y_train, pred_train))

pred_test = model.predict(X_test)
print("test r2: %f" % r2_score(y_test, pred_test))

Versuchen Sie es mit verschiedenen Werten für den random_state Integer-Startwert, der die zufällige Aufteilung steuert.

Vielleicht würde Negmse das Problem lösen

+1 für 'neg_mse' (Ich denke, dieser Unterstrich macht die Dinge besser lesbar).

Löst das alle Probleme? Gibt es andere Punkte, bei denen höhere Werte nicht besser sind?

Es gibt:

  • log_loss
  • mean_absolute_error
  • median_absolute_error

Laut doc/modules/model_evaluation.rst sollten das alle sein.

Und hinge_loss denke ich?

Das Hinzufügen des Präfixes neg_ zu all diesen Verlusten ist unangenehm.

Eine Idee wäre, die ursprünglichen Partituren zurückzugeben (ohne Vorzeichenwechsel), aber anstatt ein ndarray zurückzugeben, geben wir eine Klasse zurück, die ndarray mit Methoden wie best() , arg_best() , best_sorted() . Auf diese Weise sind die Ergebnisse nicht überraschend und wir verfügen über praktische Methoden, um die besten Ergebnisse zu erzielen.

Es gibt keinen Wert für Scharnierverlust (und ich habe noch nie gesehen, dass er zur Bewertung verwendet wird).

Der Scorer gibt kein Numpy-Array zurück, sondern einen Float, oder?
Wir könnten ein Score-Objekt zurückgeben, das ein benutzerdefiniertes ">" hat, aber wie ein Float aussieht.
Das fühlt sich für mich besser an als die vorherige Lösung, bei der der Torschütze mit einem Bool "lower_is_better" versehen wurde, das dann in GridSearchCV verwendet wurde.

cross_val_score gibt ein Array zurück.

Tatsächlich müssen die von cross_val_score Punktzahlen normalerweise nicht sortiert, sondern nur gemittelt werden.

Eine andere Idee ist, _BaseScorer eine sorted -Methode hinzuzufügen.

my_scorer = make_scorer(my_metric, greater_is_better=False)
scores = my_scorer.sorted(scores)  # takes into account my_scorer._sign
best = scores[0]

cross_val_score gibt ein Array zurück, aber die Scorer geben einen Float zurück. Ich halte es für seltsam, eine bestimmte Logik in cross_val_score da Sie in GridSearchCV und in allen anderen CV-Objekten dasselbe Verhalten wünschen.

Sie benötigen außerdem eine Argsort-Methode, da Sie in GridSearchCV die beste Punktzahl und den besten Index erzielen möchten.

Wie kann man durch Scikit-Learn "Schätzen der Mittelwerte und Abweichungen der Fehler der Arbeiter aus den Kontrollfragen und Berechnen des gewichteten Durchschnitts nach Entfernen der geschätzten Verzerrung für die Vorhersagen" implementieren?

IIRC Wir haben dies im Sprint besprochen (letzten Sommer?!) Und beschlossen, mit neg_mse (oder war es neg-mse ) zu gehen und alle Torschützen / Strings, bei denen wir jetzt ein negatives Vorzeichen haben, zu verwerfen.
Ist das noch der Konsens? Wir sollten das dann vor 0.18 machen.
Ping @GaelVaroquaux @agramfort @jnothman @ogrisel @raghavrv

ja wir haben uns auf neg_mse AFAIK geeinigt

Es war neg_mse

Wir brauchen auch:

  • neg_log_loss
  • neg_mean_absolute_error
  • neg_median_absolute_error

model = Sequential ()
keras.layers.Flatten ()
model.add (Dense (11, input_dim = 3, kernel_initializer = keras.initializers.he_normal (seed = 2),
kernel_regularizer = Regularizers.l2 (2)))
keras.layers.LeakyReLU (alpha = 0,1)
model.add (Dense (8, kernel_initializer = keras.initializers.he_normal (seed = 2)))
keras.layers.LeakyReLU (alpha = 0,1)
model.add (Dense (4, kernel_initializer = keras.initializers.he_normal (seed = 2)))
keras.layers.LeakyReLU (alpha = 0,1)
model.add (Dense (1, kernel_initializer = keras.initializers.he_normal (seed = 2)))
keras.layers.LeakyReLU (alpha = 0,2)
adag = RMSprop (lr = 0,0002)
model.compile (loss = loss.mean_squared_error,
Optimierer = Adag
)
history = model.fit (X_train, Y_train, Epochen = 2000,
batch_size = 20, shuffle = True)

Wie kann der obige Code überprüft werden? Ich möchte eine ausgelassene Kreuzvalidierungsmethode weglassen.

@shreyassks Dies ist nicht der richtige Ort für Ihre Frage, aber ich würde dies überprüfen: https://keras.io/scikit-learn-api . Wickeln Sie Ihr Netzwerk in einen scikit-learn Schätzer ein und verwenden Sie dann w / model_selection.cross_val_score

Ja. Ich bin vollkommen einverstanden! Dies ist auch Brier_score_loss passiert. Mit Brier_score_loss funktioniert es einwandfrei, aber es wird verwirrend, wenn es vom GridSearchCV kommt. Der negative Brier_score_loss kehrt zurück. Zumindest wäre es besser, so etwas auszugeben, weil Brier_score_loss ein Verlust ist (je niedriger desto besser), die Bewertungsfunktion hier dreht das Vorzeichen um, um es negativ zu machen.

Die Idee ist, dass cross_val_score sich vollständig auf den absoluten Wert des Ergebnisses konzentrieren sollte. Meines Wissens ist die Bedeutung des negativen Vorzeichens (-) für MSE (mittlerer quadratischer Fehler) in cross_val_score nicht vordefiniert. Warten wir auf die aktualisierte Version von sklearn, in der dieses Problem behoben ist.

Für den Regressionsfall:
model_score = cross_val_score (Modell, df_input, df_target, Scoring = 'neg_mean_squared_error', cv = 3)
Ich erhalte die Werte wie folgt:

SVR:
[-6.20938025 -1.397376 -1.94519]
-3.183982080147279

Lineare Regression:
[-5.94898085 -9.30931808 -1.15760676]
-5.4719685646934275

Lasso:
[-7.22363814 -10.47734135 -2.20807684]
-6.6363521107522345

Grat:
[-5.95990385 -4.17946756 -1.36885809]
-3,8360764993832004

Welches ist das Beste?
SVR?

Für den Regressionsfall:
Ich erhalte unterschiedliche Ergebnisse, wenn ich benutze
(1) "cross_val_score" mit Scoring = 'neg_mean_squared_error'
und
(2) Für die gleichen Eingaben, wenn ich "GridSearchCV" verwende und den 'best_score_' überprüfe.

Welches ist für Regressionsmodelle besser?

  • "cross_val_score" mit Scoring = 'neg_mean_squared_error'
    (ODER)
  • benutze "GridSearchCV" und überprüfe den 'best_score_'

@ Pritishban
Sie stellen eine Verwendungsfrage. Der Issue-Tracker ist hauptsächlich für Fehler und neue Funktionen gedacht. Bei Fragen zur Verwendung wird empfohlen, Stack Overflow oder die Mailingliste zu verwenden .

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen