Danke für das Öffnen dieser Ausgabe, ping @jnothman @amueller @GaelVaroquaux laut

8425 hat nichts mit Entscheidungsbereichen von Klassifikatoren zu tun,?

Ich ziehe es vor, plot_tree und plot_partial_dependence nach sklearn.plot zu verschieben und #13335 in 0.21 zu lösen (vielleicht eine Funktion zum Plotten der Entscheidungsgrenze einführen, da dies wichtig und für Anfänger nicht einfach ist IMO). Was denken andere?

Um den Umfang von sklearn.plot zu kontrollieren, schlage ich vor, dass wir nur auf Achsenebene und nicht auf Figurenebene zeichnen. Der Benutzer würde die Achsen als Schlüsselwort übergeben. Der Einfachheit halber ist die Standardeinstellung für die Achsen Keine. Nur in diesem Fall generiert die Plotting-Funktion eine Achse/Figur zum Plotten.

Gute Idee, aber nicht konsistent mit bestehenden Funktionen (plot_tree und plot_partial_dependence), oder?

Es gibt Fälle, in denen Sie eine Zahl ausgeben/ändern müssen, z. B. mit
mehrere Subplots (siehe Seaborns Facettenplots usw. und Upsetplot für .)
Beispiel). Können Sie Gründe nennen, warum Sie es auf Achsen beschränken wollen?

Am Fr., 15. März 2019, 02:19 Uhr schrieb Hanmin Qin, [email protected] :

Danke für das Öffnen dieses Problems, ping @jnothman
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquaux nach Gitter

8425 https://github.com/scikit-learn/scikit-learn/issues/8425 ist nicht

im Zusammenhang mit Entscheidungsregionen von Klassifikatoren,?
Ich ziehe es vor, plot_tree und plot_partial_dependence nach sklearn.plot zu verschieben und
#13335 lösen https://github.com/scikit-learn/scikit-learn/issues/13335
in 0.21 (evtl. eine Funktion zur Darstellung der Entscheidungsgrenze einführen, da
es ist wichtig und nicht einfach für Anfänger IMO). Was denken andere?

Um den Umfang von sklearn.plot zu kontrollieren, schlage ich vor, dass wir nur plotten
auf Achsenebene und nicht auf Figurenebene. Der Benutzer würde in die Achsen gehen
als Stichwort. Der Einfachheit halber ist die Standardeinstellung für die Achsen Keine. Nur im
In diesem Fall generiert die Plotting-Funktion eine Achse/Figur zum Plotten.

Gute Idee, aber nicht vereinbar mit bestehenden Funktionen (plot_tree und
plot_partial_dependence), oder?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

Gute Idee, aber nicht konsistent mit bestehenden Funktionen (plot_tree und plot_partial_dependence), oder?

@qinhanmin2014 plot_tree scheint die Zahl nicht anzupassen. plot_partial_dependence mehrere Plots basierend auf features . Es kann jedoch in ein Diagramm auf Achsenebene umgestaltet werden. Ein Benutzer müsste plot_partial_dependence mehrmals aufrufen, um ihm verschiedene Achsen (und Funktionen) zu geben.

Können Sie Gründe nennen, warum Sie es auf Achsen beschränken wollen?

@jnothman Seaborn verfügt über eine Dokumentation , die "Figuren-Level" -Plots und "Achsen-Level"

In Bezug auf das Testen können wir den Weg von Seaborn gehen und direkt Matplotlib-Objekte testen oder den Yellowbrick-Weg, bei dem wir Pixel-Level-Tests durchführen. Ich bevorzuge das Testen der Matplotlib-Objekte.

Meine 2 Cent:

• +1 für die Aufnahme der Funktionen, die auf matplotlib zugreifen, in einem gemeinsamen Unterpaket oder auf einem Modul in jedem Unterpaket (sklearn.linear_models.plot, sklearn.ensemble.plot).

• Wie von @thomasjpfan erwähnt,

  Außerdem wurde vor langer Zeit im Ökosystem diskutiert, anderen Plotting-Backends aus Kompatibilitätsgründen ein "Achsen"-ähnliches Objekt zu geben. Ich weiß nicht, wohin das ging. Ein kurzes Googeln zeigt nicht viel. Das nächste ist plotly.tools.mpl_to_plotly, das diese Einschränkung nicht wirklich benötigt, daher denke ich, dass dieses Argument vergeblich ist.

vielleicht eine Funktion einführen, um die Entscheidungsgrenze zu zeichnen, da es wichtig und für Anfänger nicht einfach ist IMO

Ich stimme zu, aber ich denke auch, dass es eines der Ziele der Beispiele ist, den Benutzern zu zeigen, wie Ergebnisse wie Entscheidungsgrenzen dargestellt werden.

Wenn ich einen schnellen ersten Plot eines Ergebnisses haben möchte, sind Plotfunktionen großartig, insbesondere für komplizierte Plots wie das Plotten eines Baumes, aber ich passe den Plot sehr oft an meine Bedürfnisse an und verlasse mich daher lieber auf vorhandene Beispiele und den Code ändern.

Was den Namen des Moduls betrifft, ist IMO inspect vielseitiger als plot :

• Ich kann mir keine Handlung vorstellen, die nicht eine Art Inspektion ist
• #12599 (Partielle Abhängigkeit) führt bereits inspect

IMO inspect ist vielseitiger als Plot

keine starke Meinung, wird +1 für beide Namen stimmen. Vielleicht ist die Handlung einfacher?

Auch hier bin ich daran interessiert, das neue Modul vor 0.21 zu erstellen und plot_tree und plot_partial_dependence dorthin zu verschieben. Idealerweise sollten wir auch einen Konsens über die API erzielen (zB Achsenebene/Zahlenebene).

Anderer Punkt zugunsten von inspect :

Möglicherweise möchten wir Tools überprüfen, die als Option Plotten anbieten. Drucken Sie beispielsweise die Eigenschaften eines Baums (Anzahl der Knoten, Blätter, Trennpunkte usw.) und zeichnen Sie ihn optional mit matplotlib.

Ich wäre dafür, Achsen anstelle von Zahlen zu verwenden, wie vorgeschlagen (seufz, ich muss die PDPs wieder ändern). Es ist einfacher für uns zu unterstützen und zu testen. Es ist ein wenig mehr Arbeit für die Benutzer, ermöglicht aber auch mehr Kontrolle.

IMO inspect ist vielseitiger als Plot

keine starke Meinung, wird +1 für beide Namen stimmen. Vielleicht ist die Handlung einfacher?

"inspect" wird in Python geladen (es ist ein Modul in der Standardbibliothek). ich
würde es vermeiden, denselben Namen zu verwenden.

Auch hier bin ich daran interessiert, das neue Modul vor 0.21 zu erstellen und plot_tree und plot_partial_dependence dorthin zu verschieben. Idealerweise sollten wir auch einen Konsens über die API erzielen (zB Achsenebene/Zahlenebene).

Dies sollte 0.21 nicht verzögern. Unser Ziel ist es, früh zu veröffentlichen, und hoffentlich
wieder vorzeitig freigeben.

"inspect" wird in Python geladen (es ist ein Modul in der Standardbibliothek). ich
würde es vermeiden, denselben Namen zu verwenden.

Ich schlage model_inspection . Es passt gut zu unserem Namen model_selection .

Wir möchten vielleicht etwas untersuchen, das kein Modell ist (Encoder, Präprozessor, Rastersuchergebnisse...)

inspection dann?

Die Dinger sind auch Modelle :)

Gaels Vorschlag eines öffentlichen Plot-Submoduls für jedes Unterpaket lohnt sich
angesichts.

FWIW, ich würde auch plot inspect vorziehen, da es für die meisten Benutzer intuitiver ist, es zu finden. Die Leute versuchen eher, ihre Modelle _zu zeichnen_ als ihre Modelle zu _prüfen_ (z. B. bei der Suche in Suchmaschinen oder beim Betrachten der möglichen Autovervollständigungsoptionen in ihrer IDE).

Gaels Vorschlag eines öffentlichen Plot-Submoduls für jedes Unterpaket ist eine Überlegung wert.

Wenn ja, wo sollen wir plot_decision_boundary einfügen?

Bezüglich #12599, @NicolasHug bezweifle ich, ob partial_dependence im neuen Modul enthalten sein sollte. (dh ensemble.partial_dependence + plot.plot_partial_dependence)

Wenn ja, wo sollen wir plot_decision_boundary platzieren?

sklearn.plot ?

Ich möchte nicht zu sehr auf diese Lösung drängen. Ich stimme jedoch zu
das Gefühl, dass "Plot" für Endbenutzer leichter zu entdecken ist.

In Bezug auf #12599, @NicolasHug, bezweifle ich, ob partielle_Abhängigkeit im neuen Modul enthalten sein sollte. (dh ensemble.partial_dependence + plot.plot_partial_dependence)

Ich verstehe nicht, was du meinst. #12599 setzt ensemble.partial_dependence zugunsten von inspect.partial_dependence (natürlich kann inspect basierend auf dieser Diskussion geändert werden). Die API unterscheidet sich auch zwischen den beiden Implementierungen.

Mir geht es gut mit plot , ich bin nur besorgt über eine mögliche hohe Überschneidung mit einem eventuellen Inspektionsmodul, aber ich werde es nicht weiter vorantreiben :)

Ein öffentliches Plot-Submodul für jedes Unterpaket ist eine Überlegung wert.

Aber bisher sind alle vorgeschlagenen Plotting-Tools (PDPs, Kalibrierung, Verwirrungsmatrix und Entscheidungsregion) nicht spezifisch für ein einzelnes Modul.

Ich verstehe nicht, was du meinst. #12599 verwirft ensemble.partial_dependence zugunsten von inspect.partial_dependence (natürlich kann sich inspect basierend auf dieser Diskussion ändern). Die API unterscheidet sich auch zwischen den beiden Implementierungen.

Entschuldigung, dass ich mir diese PR nicht im Detail angeschaut habe. Vielleicht inspect.partial_dependence + plot.plot_partial_dependence ?

Vielleicht inspect.partial_dependence + plot.plot_partial_dependence?

Ich mag eine klare Trennung zwischen der Berechnung der Werte und der Darstellung.
Es ist eine modell-/ansichtsähnliche Trennung und sollte dazu beitragen, die
Wiederverwendbarkeit.

Hat Gaël nicht früher sklearn.inspect.partial_dependence vorgeschlagen und
sklearn.inspect.plot.plot_partial_dependence (Ersetzen Sie einen anderen Namen
zur Kontrolle ggf.)? Das stört mich nicht.

Hat Gaël nicht früher sklearn.inspect.partial_dependence und sklearn.inspect.plot.plot_partial_dependence (ggf. ersetzen Sie inspect durch einen anderen Namen) vorgeschlagen?

Ja, aber ich habe ihn gefragt, wo wir plot_decision_boundary hinstellen sollen und es scheint, dass er seine Meinung geändert hat?

Zu Ihrer Information, ich habe die PDP-PR https://github.com/scikit-learn/scikit-learn/pull/12599 gemäß den obigen Empfehlungen aktualisiert:

• partial_dependence ist in sklearn.model_inspection
• plot_partial_dependence ist in skearn.plot

Die Dokumente sind hier https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

Beachten Sie, dass das Benutzerhandbuch derzeit nur das Modul plot . Ich denke nicht, dass es sinnvoll ist, einen Abschnitt des Benutzerhandbuchs zu haben, der nur über model_inspection.partial_dependence spricht, da seine Einschränkungen / sein Verhalten denen von plot_partial_dependence .

(Dies ist die Art von Überlappung, über die ich mir Sorgen gemacht habe)

Natürlich, wenn Sie der Meinung sind, dass es immer noch besser ist, separate Benutzerhandbücher für partial_dependence und plot_partial_dependence , werde ich es tun.

Zu Ihrer Information, ich habe die PDP PR Nr. 12599 gemäß den obigen Empfehlungen aktualisiert:
partielle_abhängigkeit ist in sklearn.model_inspection
plot_partial_dependence ist in skearn.plot

+1

Beachten Sie, dass das Benutzerhandbuch vorerst nur das Plot-Modul enthält. Ich denke nicht, dass es sinnvoll ist, einen Abschnitt des Benutzerhandbuchs zu haben, der nur über model_inspection.partial_dependence spricht, da seine Einschränkungen / sein Verhalten denen von plot_partial_dependence entsprechen.

+1

Also haben wir uns für den Namen sklearn.plot entschieden?

Ich finde das Importieren von Abhängigkeiten von sklearn aus sklearn.plot etwas seltsam, wenn wir es vermieden haben, alle in den Root-Namespace zu setzen.

Also lieber sklearn.model_inspection.plot und plot_partial_dependence() dort hinlegen?

Kein plot Modul, das geht mir gut

Ich glaube, das wäre mir lieber. Noch nicht sicher, wie es verallgemeinert.

Ich glaube, das wäre mir lieber. Noch nicht sicher, wie es verallgemeinert.

Solange wir einen geeigneten Platz für Dinge wie plot_decision_boundary , stimme ich mit +1 für sklearn.XXX.plot .

Braucht das einen Schlaf? Wir scheinen keine großen Fortschritte zu machen

BEARBEITEN ähm, schläfrig habe ich Joels Kommentar gelesen, da ich glaube nicht, dass mir das lieber wäre , sorry

Braucht das einen Schlaf? Wir scheinen keine großen Fortschritte zu machen

Ich bin mit beiden Lösungen in Ordnung ( sklearn.plot / sklearn.XXX.plot ). Das Hauptproblem hier ist IMO, dass mir niemand sagt, wo wir Dinge wie plot_decision_boundary wenn wir sklearn.XXX.plot :)

sklearn.model_inspection.plot ?

sklearn.model_inspection.plot?

Interessante Idee, ich stimme mit +1. Vielleicht ist es nicht so gut, alle Dinge in sklearn.plot zu werfen (https://github.com/rasbt/mlxtend fasst alle Plotfunktionen in einem einzigen Modul zusammen).

Also werden wir from sklearn.XXX.plot import plot_XXX ? Werden wir from sklearn.XXX import plot_XXX ?

Ich denke, die explizite Anforderung von .plot beim Import ist etwas
andere haben hier gesucht.

Es gibt auch den invertierten von sklearn.plot.XXX import plot_YYY

Ich denke, die explizite Anforderung von .plot beim Import ist etwas, das andere hier gesucht haben.

Wir haben uns also darauf geeinigt, sklearn.XXX.plot (nur Unterstützung von sklearn.XXX.plot import plot_XXX )?

Es gibt auch den invertierten von sklearn.plot.XXX import plot_YYY

Ich kann nicht verstehen.

Es gibt auch den invertierten von sklearn.plot.XXX import plot_YYY

Ich meinte, wir könnten haben
sklearn.plot.model_inspection.plot_partial_dependence statt
sklearn.model_inspection.plot.plot_partial_dependence. Nicht sicher, ob das
bietet irgendeinen Nutzen/Klarheit.

Ich meinte, wir könnten haben
sklearn.plot.model_inspection.plot_partial_dependence statt
sklearn.model_inspection.plot.plot_partial_dependence. Nicht sicher, ob das
bietet irgendeinen Nutzen/Klarheit.

Also haben wir jetzt 3 Möglichkeiten:
(1) sklearn.plot.plot_YYY (zB sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (zB sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (z. B. sklearn.tree.plot.plot_tree, unterstützt nicht von sklearn.XXX import plot_YYY)
Ich stimme für alle diese Lösungen mit +1.
Ich ziehe es vor, die Entscheidung vor 0.21 zu treffen, um zu vermeiden, dass sklearn.tree.plot_tree verworfen wird

Ich bin mir nicht sicher, ob es einen Schlaf braucht, aber es könnte sich lohnen, Meinungen dazu einzuladen
Mailingliste

Ich bin mir nicht sicher, ob es einen Schlaf braucht, aber es könnte sich lohnen, Meinungen in die Mailingliste einzuladen

+1. Es scheint nicht unter die Kriterien von SLEPs zu fallen.

Wie ich schon auf der Mailingliste sagte, ich denke, wir sollten uns wirklich auch überlegen, "wo die Arbeit passiert" oder wie die Schnittstelle aussehen wird. Das war für die Teilabhängigkeit schon recht unklar.
Soll plot_partial_dependence partial_dependence plot_partial_dependence aufrufen oder die Ausgabe von partial_dependence als Eingabe erhalten? Diese Frage ist eine gültige Frage für im Grunde alle Plotfunktionen.
Die Hauptüberlegung, die ich mit @NicolasHug bespreche, ist, dass es für den Benutzer plot_X compute_X plot_X aufzurufen - solange er das Ding nur einmal plotten möchte. Wenn ihnen die Handlung nicht gefällt und sie etwas ändern möchten, müssen sie erneut compute_X tun, was möglicherweise eine Verschwendung ist.

Also könnten wir entweder

• Nimm immer das Ergebnis von compute_X . Nachteil: umständlich und fehleranfällig: Wie war die Reihenfolge von Precision, Recall und Thresholds nochmal in precision_recall_curve?

• Nehmen Sie immer die Eingabe zu compute_X und rufen Sie compute_X von plot_X . Nachteil: Sie müssen für jeden Plot neu berechnen.

• Lassen Sie beides zu, also kann plot_X entweder die Eingabe in compute_X und compute_X aufrufen oder die Ausgabe von compute_X wenn der Benutzer sie bereits erstellt hat. Das hat den Nachteil, dass die Signatur kompliziert wird (und möglicherweise die Dokumentation erschwert). Wenn der Benutzer plot_X aufruft, damit er intern compute_X und dann einen anderen Plot möchte, muss er erneut compute_X aufrufen. Sie müssen also voraussehen, dass Sie mehr als einen Plot benötigen, bevor Sie plot_X zum ersten Mal aufrufen. Oder Sie müssen das Ergebnis von compute_X beim Aufrufen von plot_X , aber mir ist unklar, wie das ohne objektorientiertes Design geht

• treffen Sie die Entscheidung abhängig davon, wie teuer compute_X ist, da wir uns bei Konfusionsmatrix- und Partial-Dependency-Plots und Kalibrierungs-Plots nicht um die Kosten der Neuberechnung kümmern, bei Partial-Dependence-Plots jedoch schon. Nachteil: inkonsistente Benutzeroberfläche.

Die Hauptüberlegung, die ich mit @NicolasHug bespreche, ist, dass es für den Benutzer

+1000. Es ist ein häufiges Problem, das ich im Forschungscode sehe.

Aufgrund eines Designproblems verletzt es eine MVC-Trennung (etwas umständlich,
Verzeihung).

Würden Sie bei den verschiedenen von Ihnen vorgeschlagenen Lösungen in Erwägung ziehen,
angepasstes Modell als Ansatz? Ich denke, es würde das Problem der
Erinnern an die Reihenfolge der Parameter. Aber vielleicht gibt es noch weitere
Probleme.

Ich bin mir nicht sicher, was du mit angepasstem Modell meinst. Häufig ist die Ausgabe der Berechnung kein angepasstes Modell. Wir könnten für alle Berechnungsergebnisse Objekte definieren, sodass partial_dependence ein PartialDependence Objekt zurückgibt. Oder ein Haufen. Aber es gibt keinen Schätzer zurück.

Oh, der Grund, warum ich das jetzt anspreche: Ohne diese Entscheidung habe ich keine Ahnung, wie der Benutzercode aussehen wird, und ich treffe keine Namens- / API-Entscheidungen, ohne Beispiele aufschreiben zu können ;)

Ein Objekt zurückzugeben wäre ziemlich un-sklearn-like, imho. Aber es könnte das Standortproblem lösen: Es könnte eine plot Methode haben ;)

Häufig ist die Ausgabe der Berechnung kein angepasstes Modell. Wir könnten für alle Berechnungsergebnisse Objekte definieren, sodass partial_dependence ein PartialDependence-Objekt zurückgibt. Oder ein Haufen. Aber es gibt keinen Schätzer zurück.

Punkt genommen.

Eine Option (ohne zu sagen, dass es die beste ist) wäre, alle
Rechenfunktionen geben benannte Tupel und alle entsprechenden Rechenfunktionen zurück
Funktionen übernehmen dies. Es wäre etwas im Einklang mit der Moderne
Ergänzungen zur Python-Standardbibliothek.

und ich mag es nicht, Namens- / API-Entscheidungen zu treffen, ohne Beispiele aufschreiben zu können ;)

Ich bin wie du.

Wenn die Berechnung also teuer ist, können wir die Berechnung außerhalb der Funktion durchführen. Wenn ja, geben wir ein Objekt zurück und die Plotting-Funktion nimmt dieses Objekt als Eingabe, richtig? Ich stimme mit +1.

Und vielleicht brauchen wir ein anderes Thema, um dies zu diskutieren :)

Der Vorteil des Vorschlags von @GaelVaroquaux besteht darin, dass Benutzer möglicherweise ihren Code aufgrund des Entpackens von confusion_matrix . Dort wäre ein Tupel nicht unbedingt notwendig, aber dann wird die Schnittstelle etwas inkonsistent.

@qinhanmin2014 Wenn wir beliebige Objekte zurückgeben, müssen wir den Rückgabetyp für eine Funktion jedes Mal

Ich hatte eine Idee und dann eine zweite bessere Idee:
1) Erstellen Sie eine zweite, objektorientierte Schnittstelle, die die vorhandene Funktion aufruft, das Objekt speichert und eine Plotmethode hat, wie

cm = ConfusionMatrix(y, y_pred)
cm.plot()

Das würde das Problem lösen, aber einige Schnittstellen duplizieren und es wäre etwas unklar. Tatsächlich kann das gleiche Prinzip auf eine Weise durchgeführt werden, die meiner Meinung nach intuitiver ist:
2) Lassen Sie die Funktion plot_ immer die Arbeit machen, verwenden Sie das Ergebnis, um ein Objekt zu instanziieren, das das Ergebnis speichert und es plottet:

plot_confusion_matrix(y, y_pred)

würde daher nur plotten und ein ConfusionMatrixPlotter Objekt zurückgeben, das das Ergebnis speichert und eine plot Methode hat.
Im einfachen Fall des einmaligen Plottens ist es also nur ein einzelner Funktionsaufruf. Sollen die Ergebnisse dann etwas anderes damit machen, werden sie im Objekt gespeichert. Wenn Sie erneut plotten möchten, rufen Sie einfach erneut plot für das Objekt auf. Wenn Sie die Ergebnisse bereits berechnet haben und sich dann zum Plotten entscheiden, können Sie ConfusionMatrixPlotter direkt instanziieren.

Während dies eine zusätzliche Klasse für die komplexeren Anwendungsfälle bereitstellt, halte ich dies für einen vernünftigen Kompromiss, da sie auf alle Situationen eine gute Antwort bietet.

würde daher nur plotten und ein ConfusionMatrixPlotter-Objekt zurückgeben, das das Ergebnis speichert und eine Plot-Methode hat.

Warum müssen Benutzer dieselben Daten erneut zeichnen? @amueller das Format anpassen?

@qinhanmin2014 ja, plotte sie mit etwas anderem zusammen in derselben Handlung, füge Beschriftungen hinzu, ...

@qinhanmin2014 ja, plotte sie mit etwas anderem zusammen in derselben Handlung, füge Beschriftungen hinzu, ...

Ich bezweifle, dass es sich lohnt, diese Formatierungsprobleme hier zu berücksichtigen. Benutzer können starten wird ein kleiner Teil des Datensatzes?

Und @amueller werden wir das Übergeben von Achsen unterstützen, damit Benutzer den Plot einfach anpassen können, nachdem sie die

@qinhanmin2014 nein, vieles lässt sich nachträglich nicht einfach ändern, und wir müssen uns nicht unbedingt selbst über alle Formatierungen Gedanken machen, aber wir sollten den Benutzern erlauben, wieder etwas zu plotten. Es wird im Grunde jedes Mal passieren, wenn Sie einen Plot erstellen. Und es ist ein bisschen nervig, jedes Mal, wenn ich einen Plot erstellen möchte, Datensätze untersammen zu müssen. Und wenn ich meine Meinung später ändere, muss ich immer noch neu berechnen.
Im Grunde geht es darum, dass Sie normalerweise nicht vorhersehen können, was Sie in Ihrer explorativen Analyse genau wollen, und es scheint nicht gut zu sein, alles neu berechnen zu müssen, um eine Visualisierung zu ändern.

@qinhanmin2014 nein, vieles lässt sich nachträglich nicht einfach ändern, und wir müssen uns nicht unbedingt selbst über alle Formatierungen Gedanken machen, aber wir sollten den Benutzern erlauben, wieder etwas zu plotten. Es wird im Grunde jedes Mal passieren, wenn Sie einen Plot erstellen. Und es ist ein bisschen nervig, jedes Mal, wenn ich einen Plot erstellen möchte, Datensätze untersammen zu müssen. Und wenn ich meine Meinung später ändere, muss ich immer noch neu berechnen.

Ja, ich weiß, es könnte nützlich sein, aber das Hauptproblem hier ist, dass wir keine saubere Möglichkeit haben, diese Funktionalität zu unterstützen, und ich denke, die meisten Plotfunktionen erfordern nicht viel Berechnung?

Ich mag es, dass wir das mit etwas mehr Bodenhaftung besprechen, aber ich bin
immer noch nicht ganz überzeugt, dass wir überhaupt Plot im Import haben müssen
Weg überhaupt. Immerhin scheinen wir plot_ als Präfix für die . zu haben
Funktionen. Die Frage bezieht sich auch auf plot_tree: warum sollte es so sein?
getrennt von anderem Export- und Textvisualisierungscode?

@qinhanmin2014 Ich glaube nicht, dass "wir haben noch keine gute API" ein guter Grund ist.
Und partielle Abhängigkeit, Permutationswichtigkeit, Lernkurven, Validierungskurven und Ergebnisse von GridSearchCV und RandomizedSearchCV sind gängige Beispiele, die viel Rechenaufwand erfordern. Obwohl es für gridsearchcv und randomizedsearchcv offensichtlich wäre, entweder das Objekt oder das cv_results_ , erscheint es in diesen Fällen unsinnig, die Arbeit innerhalb der Plotting-Funktion zu erledigen. Bei Lernkurven und Validierungskurven bin ich mir nicht ganz sicher.

@jnothman Ich denke, @GaelVaroquaux wollte die Matplotlib-Abhängigkeit auf ein Modul beschränken, und das war eine der Hauptmotivationen? Ich habe noch keine wirklich schlüssigen Gedanken dazu.

Und partielle Abhängigkeit, Permutationswichtigkeit, Lernkurven, Validierungskurven und Ergebnisse von GridSearchCV und RandomizedSearchCV sind gängige Beispiele, die viel Rechenaufwand erfordern.

Danke, jetzt habe ich gemerkt, dass ich falsch liege :)
Obwohl ich immer noch nicht verstehen kann, warum es wichtig ist, Benutzern eine Möglichkeit zum Plotten ohne Neuberechnung zu bieten. Aber wenn andere so denken und es einen guten Weg gibt, stimme ich mit +1.

Ich mag es, dass wir das mit etwas mehr Bodenhaftung besprechen, aber ich bin
immer noch nicht ganz überzeugt, dass wir überhaupt Plot im Import haben müssen
Weg überhaupt. Immerhin scheinen wir plot_ als Präfix für die . zu haben
Funktionen. Die Frage bezieht sich auch auf plot_tree: warum sollte es so sein?
getrennt von anderem Export- und Textvisualisierungscode?

Ja, das kann auch eine Option sein. Wenn ja, können wir erwähnen, dass alle Funktionen, die mit plot_ , matplotlib benötigen. Ein weiterer Vorteil dieser Option ist, dass wir vorhandene Funktionen nicht verschieben müssen.

In dieser Diskussion bin ich damit einverstanden, kein sklearn.plot Modul hinzuzufügen und das Präfix plot_ zu verwenden, um eine matplotlib Anforderung zu signalisieren.

Beispielsweise werden in https://github.com/scikit-learn/scikit-learn/pull/12599 partial_dependence und plot_partial_dependence in inspection .

Ok, es sei denn, jemand ist in den folgenden Tagen damit nicht einverstanden, werde ich die PDP-PR aktualisieren und:

• lege sowohl partial_dependence als auch plot_partial_dependence in sklearn.inspection
• Lassen Sie plot_partial_dependence einen Haufen mit den Objekten fig und ax als Attribute zurückgeben (im Moment gibt es sie in einem Tupel zurück). Auf diese Weise können wir diese beiden Funktionen abwärtskompatibel halten, wenn wir die zweite Option von https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520 implementieren

Können wir hier die endgültige Entscheidung treffen?
Vorschlag von @jnothman , @NicolasHug und mir (Entschuldigung, wenn ich falsch liege): sklearn.XXX.plot_YYY (Unterstützung von sklearn.XXX import plot_YYY). Wir werden erwähnen, dass alle Funktionen, die mit plot_ beginnen, matplotlib benötigen.
Ein großer Vorteil dieses Vorschlags besteht darin, dass wir bestehende Funktionen nicht verschieben müssen.

Wenn ich drüber schlafe, denke ich, dass es einfach genug zu erklären ist und es vermeidet die Schwierigkeit, an eine gemeinsame Plotter-API zwischen verschiedenen Modulen zu denken.

Ja, lass uns das machen. Erstellen Sie eine Hilfsfunktion, um eine hilfreichere
Importfehler

Zu Ihrer Information, ich füge sklearn.utils.check_matplotlib_support in #12599 hinzu

def check_matplotlib_support(caller_name):
    try:
        import matplotlib
    except ImportError as e:
        raise ImportError(
            "{} requires matplotlib. You can install matplotlib with "
            "`pip install matplotlib`".format(caller_name)
        ) from e

Zu Ihrer Information, ich füge sklearn.utils.check_matplotlib_support in #12599 hinzu

Das ist großartig! Vielen Dank.