Merci d'avoir ouvert ce numéro, ping @jnothman @amueller @GaelVaroquaux selon gitter

8425 n'est pas lié aux régions de décision des classificateurs ?

Je préfère déplacer plot_tree et plot_partial_dependence vers sklearn.plot et résoudre #13335 en 0.21 (peut-être introduire une fonction pour tracer la limite de décision, car c'est important et pas facile pour les débutants IMO). Qu'en pensent les autres ?

Pour aider à contrôler la portée de sklearn.plot, je propose de ne tracer qu'au niveau des axes et non au niveau de la figure. L'utilisateur passerait dans les axes comme mot-clé. Pour plus de commodité, la valeur par défaut des axes sera Aucun. Ce n'est que dans ce cas que la fonction de traçage générera un axe/une figure sur lequel tracer.

Bonne idée, mais pas cohérente avec les fonctions existantes (plot_tree et plot_partial_dependence), non ?

Il y a des cas où vous devez sortir/modifier un chiffre, comme avec
plusieurs sous-parcelles (voir les parcelles de facette de Seaborn, etc., et upsetplot pour
Exemple). Pouvez-vous donner les raisons pour lesquelles vous souhaitez le limiter aux axes ?

Le vendredi 15 mars 2019, à 2 h 19, Hanmin Qin, [email protected] a écrit :

Merci d'avoir ouvert ce problème, ping @jnothman
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquaux selon gitter

8425 https://github.com/scikit-learn/scikit-learn/issues/8425 n'est pas

liés aux régions de décision des classificateurs ?
Je préfère déplacer plot_tree et plot_partial_dependence vers sklearn.plot et
résoudre #13335 https://github.com/scikit-learn/scikit-learn/issues/13335
en 0.21 (peut-être introduire une fonction pour tracer la frontière de décision, puisque
c'est important et pas facile pour les débutants IMO). Qu'en pensent les autres ?

Pour aider à contrôler la portée de sklearn.plot, je propose que nous ne fassions que le traçage
au niveau des axes et non au niveau de la figure. L'utilisateur passerait dans les axes
comme mot-clé. Pour plus de commodité, la valeur par défaut des axes sera Aucun. Seulement dans
dans ce cas, la fonction de traçage générera-t-elle un axe/une figure sur lequel tracer.

Bonne idée, mais pas cohérente avec les fonctions existantes (plot_tree et
plot_partial_dependence), n'est-ce pas ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

Bonne idée, mais pas cohérente avec les fonctions existantes (plot_tree et plot_partial_dependence), non ?

@qinhanmin2014 plot_tree ne semble pas ajuster le chiffre. plot_partial_dependence fait plusieurs tracés basés sur features . Cependant, il peut être refactorisé dans un tracé de niveau d'axes. Un utilisateur aurait besoin d'appeler plot_partial_dependence plusieurs fois en lui donnant différents axes (et fonctionnalités).

Pouvez-vous donner les raisons pour lesquelles vous souhaitez le limiter aux axes ?

@jnothman Seaborn possède une documentation qui sépare clairement les tracés "au niveau de la figure" et les tracés "au niveau des axes". Si nous pouvons correctement documenter ce comportement dans scikit-learn, il est possible d'avoir ces tracés "au niveau de la figure". Ma plus grande préoccupation avec les tracés "au niveau de la figure", c'est qu'ils sont plus difficiles à entretenir et à tester. Il y aura des éléments d'un axe qui peuvent se chevaucher avec d'autres axes. Cependant, nous pouvons contourner ce problème en structurant les figures de manière à ce que les chevauchements se produisent moins souvent.

En termes de tests, nous pouvons suivre la voie de Seaborn et tester directement les objets matplotlib ou la manière yellowbrick où nous effectuons des tests au niveau des pixels. J'ai tendance à privilégier le test des objets matplotlib.

Mes 2 centimes :

• +1 pour contenir les fonctions accédant à matplotlib dans un sous-paquet commun, ou, sur un module dans chaque sous-paquet (sklearn.linear_models.plot, sklearn.ensemble.plot).

• Comme mentionné par @thomasjpfan , seul l'accès aux axes facilite le test.

  De plus, il y a longtemps, il y a eu des discussions dans l'écosystème pour donner aux autres backends de traçage un objet de type "Axes" pour la compatibilité. Je ne sais pas où ça s'est passé. Une recherche rapide sur Google ne montre pas grand-chose. Le plus proche est plotly.tools.mpl_to_plotly, qui n'a pas vraiment besoin de cette restriction, donc je pense que cet argument est vain.

peut-être introduire une fonction pour tracer la limite de décision, car c'est important et pas facile pour les débutants IMO

Je suis d'accord mais je pense aussi que montrer aux utilisateurs comment tracer des résultats tels que les limites de décision est l'un des objectifs des exemples.

Si je veux un premier tracé rapide d'un résultat, les fonctions de traçage sont excellentes, en particulier pour les tracés compliqués tels que le tracé d'un arbre, mais j'aime très souvent adapter le tracé à mes besoins et pour cette raison, je préfère m'appuyer sur des exemples existants et modifier le code.

Concernant le nom du module, IMO inspect est plus polyvalent que plot :

• Je ne peux pas penser à un complot qui ne soit pas une sorte d' inspection
• #12599 (Dépendance partielle) introduit déjà inspect

IMO inspect est plus polyvalent que plot

pas d'opinion forte, votera +1 pour les deux noms. Peut-être que l'intrigue est plus simple ?

Encore une fois, je suis intéressé par la création du nouveau module avant 0.21 et par y déplacer plot_tree et plot_partial_dependence. Idéalement, nous devrions également parvenir à un consensus sur l'API (par exemple, niveau des axes/niveau de la figure).

Autre point en faveur de inspect :

Nous pouvons vouloir inspecter des outils qui offrent le traçage en option. Par exemple, imprimez les caractéristiques d'un arbre (nombre de nœuds, feuilles, points de division, etc.) et tracez-le éventuellement avec matplotlib.

Je serais favorable à l'utilisation d'axes au lieu de chiffres, comme suggéré (soupir, je devrai à nouveau changer de PDP). Il est plus facile pour nous de soutenir et de tester. C'est un peu plus de travail pour les utilisateurs, mais cela permet aussi plus de contrôle.

IMO inspect est plus polyvalent que plot

pas d'opinion forte, votera +1 pour les deux noms. Peut-être que l'intrigue est plus simple ?

"inspect" est chargé en Python (c'est un module de la bibliothèque standard). je
éviterait d'utiliser le même nom.

Encore une fois, je suis intéressé par la création du nouveau module avant 0.21 et par y déplacer plot_tree et plot_partial_dependence. Idéalement, nous devrions également parvenir à un consensus sur l'API (par exemple, niveau des axes/niveau de la figure).

Cela ne devrait pas retarder 0,21. Notre objectif est de sortir tôt et, espérons-le,
libérer à nouveau plus tôt.

"inspect" est chargé en Python (c'est un module de la bibliothèque standard). je
éviterait d'utiliser le même nom.

Je propose model_inspection . Cela va bien avec notre nom model_selection .

Nous pourrions vouloir inspecter quelque chose qui n'est pas un modèle (encodeur, préprocesseur, résultats de recherche de grille...)

inspection alors ?

Ces choses sont aussi des modèles :)

La suggestion de Gael d'un sous-module d'intrigue publique sur chaque sous-paquet vaut
considérant.

FWIW, je préférerais également plot à inspect , car il est plus intuitif pour la plupart des utilisateurs de le trouver. Les gens essaient plus de _tracer_ leurs modèles que d'_inspecter_ leurs modèles (lors de la recherche sur les moteurs de recherche par exemple, ou en regardant les options de saisie semi-automatique possibles sur leur IDE).

La suggestion de Gael d'un sous-module d'intrigue publique sur chaque sous-paquet mérite d'être considérée.

Si oui, où mettre plot_decision_boundary ?

Concernant #12599, @NicolasHug, je doute que partial_dependence doive être dans le nouveau module. (c'est-à-dire ensemble.partial_dependence + plot.plot_partial_dependence)

Si oui, où devons-nous mettre plot_decision_boundary ?

sklearn.plot ?

Je ne veux pas trop insister pour cette solution. Cependant, je suis d'accord avec
le sentiment que "l'intrigue" peut être plus facile à découvrir pour les utilisateurs finaux.

Concernant #12599, @NicolasHug, je doute que partial_dependence doive être dans le nouveau module. (c'est-à-dire ensemble.partial_dependence + plot.plot_partial_dependence)

Je ne comprends pas ce que tu veux dire. #12599 désapprouve ensemble.partial_dependence en faveur de inspect.partial_dependence (bien sûr, inspect est sujet à changement en fonction de cette discussion). L'API diffère également entre les 2 implémentations.

Je suis d' plot avec

un sous-module public plot sur chaque sous-paquet mérite d'être envisagé.

Mais jusqu'à présent, tous les outils de traçage proposés (PDP, Calibration, Matrice de confusion et région de décision) ne sont pas spécifiques à un seul module.

Je ne comprends pas ce que tu veux dire. #12599 désapprouve ensemble.partial_dependence en faveur de inspect.partial_dependence (bien sûr, inspect est sujet à changement en fonction de cette discussion). L'API diffère également entre les 2 implémentations.

Mes excuses, je n'ai pas regardé ce PR en détail. Peut-être inspect.partial_dependence + plot.plot_partial_dependence ?

Peut-être inspect.partial_dependence + plot.plot_partial_dependence ?

J'aime une séparation claire entre le calcul des valeurs et leur tracé.
C'est un modèle/une vue comme la séparation, et cela devrait aider à augmenter la
réutilisabilité.

Gaël n'a-t-il pas proposé plus tôt sklearn.inspect.partial_dependence et
sklearn.inspect.plot.plot_partial_dependence (Remplacez un autre nom
pour inspecter le cas échéant) ? Cela ne me dérange pas.

Gaël n'a-t-il pas proposé plus tôt sklearn.inspect.partial_dependence et sklearn.inspect.plot.plot_partial_dependence (Substituez un autre nom pour inspect si nécessaire) ?

Oui, mais je lui ai demandé où mettre plot_decision_boundary et il semble qu'il ait changé d'avis ?

Pour info, j'ai mis à jour le PDP PR https://github.com/scikit-learn/scikit-learn/pull/12599 en suivant les recommandations ci-dessus :

• partial_dependence est dans sklearn.model_inspection
• plot_partial_dependence est dans skearn.plot

Les docs sont ici https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

Notez que le guide de l'utilisateur ne comprend pour l'instant que le module plot . Je ne pense pas qu'il soit logique d'avoir une section de guide de l'utilisateur qui ne parlerait que de model_inspection.partial_dependence , car ses contraintes / son comportement sont les mêmes que ceux de plot_partial_dependence .

(C'est le genre de chevauchement qui m'inquiétait)

Bien sûr, si vous pensez qu'il est toujours préférable d'avoir des guides d'utilisation séparés pour partial_dependence et plot_partial_dependence , je le ferai.

Pour info, j'ai mis à jour le PDP PR #12599 en suivant les recommandations ci-dessus :
partial_dependence est dans sklearn.model_inspection
plot_partial_dependence est dans skearn.plot

+1

Notez que le guide de l'utilisateur ne comprend pour l'instant que le module de tracé. Je ne pense pas qu'il soit logique d'avoir une section de guide de l'utilisateur qui ne parlerait que de model_inspection.partial_dependence, puisque ses contraintes/comportement sont les mêmes que ceux de plot_partial_dependence.

+1

Nous avons donc décidé d'utiliser le nom sklearn.plot ?

Je trouve que sklearn.plot importe des dépendances à travers sklearn un peu bizarre quand nous avons évité de mettre tout le monde dans l'espace de noms racine.

Vous préférez donc sklearn.model_inspection.plot et y mettre plot_partial_dependence() ?

Pas plot module

Je pense que je préférerais ça. Pas encore certain de la façon dont il se généralise.

Je pense que je préférerais ça. Pas encore certain de la façon dont il se généralise.

Tant que nous pouvons trouver un endroit approprié pour mettre des choses comme plot_decision_boundary , je voterai +1 pour sklearn.XXX.plot .

Est-ce que cela a besoin d'un sommeil? nous ne semblons pas faire beaucoup de progrès

EDIT ugh, endormi, lis le commentaire de Joel car je ne pense , désolé

Est-ce que cela a besoin d'un sommeil? nous ne semblons pas faire beaucoup de progrès

Je suis d' sklearn.plot avec l'une ou l'autre solution ( sklearn.XXX.plot ). Le principal problème ici IMO est que personne ne me dit où devons-nous mettre des choses comme plot_decision_boundary si nous utilisons sklearn.XXX.plot :)

sklearn.model_inspection.plot ?

sklearn.model_inspection.plot?

Idée intéressante, je voterai +1. Peut-être que ce n'est pas si bon de tout jeter sur sklearn.plot (https://github.com/rasbt/mlxtend met toutes les fonctions de traçage dans un seul module).

Alors nous allons supporter from sklearn.XXX.plot import plot_XXX ? Allons-nous soutenir from sklearn.XXX import plot_XXX ?

Je pense que l'exigence explicite de .plot dans l'importation est quelque chose
d'autres ici ont cherché.

Il y a aussi l'inversé de sklearn.plot.XXX import plot_YYY

Je pense que l'exigence explicite de .plot dans l'importation est quelque chose que d'autres ici ont recherché.

Nous sommes donc parvenus à un consensus pour utiliser sklearn.XXX.plot (uniquement le support de sklearn.XXX.plot import plot_XXX ) ?

Il y a aussi l'inversé de sklearn.plot.XXX import plot_YYY

Je ne peux pas comprendre.

Il y a aussi l'inversé de sklearn.plot.XXX import plot_YYY

Je voulais dire que nous aurions pu
sklearn.plot.model_inspection.plot_partial_dependence plutôt que
sklearn.model_inspection.plot.plot_partial_dependence. Je ne sais pas si cela
fournit tout avantage/clarté.

Je voulais dire que nous aurions pu
sklearn.plot.model_inspection.plot_partial_dependence plutôt que
sklearn.model_inspection.plot.plot_partial_dependence. Je ne sais pas si cela
fournit tout avantage/clarté.

Alors maintenant, nous avons 3 options:
(1) sklearn.plot.plot_YYY (par exemple, sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (par exemple, sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (par exemple, sklearn.tree.plot.plot_tree, ne prend pas en charge l'importation de sklearn.XXX plot_YYY)
Je voterai +1 pour toutes ces solutions.
Je préfère prendre la décision avant 0.21 pour éviter de déprécier sklearn.tree.plot_tree

Pas sûr qu'il ait besoin de dormir, mais cela pourrait valoir la peine d'inviter des opinions sur le
liste de diffusion

Je ne suis pas sûr qu'il ait besoin de dormir, mais cela pourrait valoir la peine d'inviter des opinions sur la liste de diffusion

+1. Il ne rentre pas dans les critères des SLEP, semble-t-il.

Comme je l'ai dit sur la liste de diffusion, je pense que nous devrions également considérer "où le travail se passe" ou à quoi ressemblera l'interface. C'était déjà assez flou pour la dépendance partielle.
plot_partial_dependence appeler partial_dependence ou obtenir la sortie de partial_dependence en entrée ? Cette question est une question valable pour pratiquement toutes les fonctions de tracé.
La principale considération dont je discute avec @NicolasHug est qu'avoir plot_X appeler compute_X est pratique pour l'utilisateur - tant qu'il ne veut tracer la chose qu'une seule fois. S'ils n'aiment pas l'intrigue et veulent changer quelque chose, ils doivent à nouveau compute_X , ce qui est potentiellement un gaspillage.

Donc on pourrait soit

• prenez toujours le résultat de compute_X . inconvénient : peu pratique et sujet aux erreurs : quel était l'ordre de précision, de rappel et de seuils à nouveau dans precision_recall_curve ?

• toujours prendre l'entrée à compute_X et appeler compute_X partir de plot_X . inconvénient : il faut recalculer pour chaque parcelle.

• autoriser les deux, donc plot_X peut prendre l'entrée à compute_X et appeler à compute_X ou prendre la sortie de compute_X si l'utilisateur l'a déjà créé. Cela a l'inconvénient de compliquer la signature (et peut-être compliquer la documentation). De plus, si l'utilisateur appelle plot_X pour qu'il fasse compute_X interne et qu'il souhaite ensuite un autre tracé, il doit à nouveau compute_X . Vous devez donc prévoir que vous voulez plus d'un tracé avant d' appeler plot_X la première fois. Ou vous devez exposer le résultat de compute_X lors de l'appel de plot_X , mais je ne sais pas comment le faire sans une conception orientée objet

• prendre la décision en fonction du coût de compute_X, comme pour les matrices de confusion et les diagrammes de dépendance partielle et les diagrammes d'étalonnage, nous ne nous soucions pas du coût du recalcul, mais pour les diagrammes de dépendance partielle, nous le faisons. bémol : interface incohérente.

La principale considération dont je discute avec @NicolasHug est que l'appel de plot_X à compute_X est pratique pour l'utilisateur - tant qu'il ne veut tracer la chose qu'une seule fois. S'ils n'aiment pas l'intrigue et veulent changer quelque chose, ils doivent à nouveau calculer_X, ce qui est potentiellement un gaspillage.

+1000. C'est un problème courant que je vois dans le code de recherche.

D'un problème de conception, il viole une séparation MVC (légèrement pédant,
Pardon).

Dans les différentes solutions que vous proposez, envisageriez-vous de prendre une
modèle ajusté comme approche? Je pense que cela atténuerait le problème de
mémoriser l'ordre des paramètres. Mais peut-être y a-t-il d'autres
problèmes.

Je ne sais pas ce que vous entendez par modèle ajusté. Souvent, le résultat du calcul n'est pas un modèle ajusté. Nous pourrions définir des objets pour tous les résultats de calcul, de sorte que partial_dependence renvoie un objet PartialDependence . Ou un tas. Mais il ne renvoie pas d'estimateur.

Oh, la raison pour laquelle j'en parle maintenant : sans cette décision, je n'ai aucune idée à quoi ressemblera le code utilisateur, et je n'aime pas prendre des décisions de nommage / API sans pouvoir écrire des exemples ;)

retourner un objet serait assez peu similaire à sklearn, à mon humble avis. Mais cela pourrait résoudre le problème de localisation : il pourrait avoir une méthode plot ;)

Souvent, le résultat du calcul n'est pas un modèle ajusté. Nous pourrions définir des objets pour tous les résultats de calcul, de sorte que partial_dependence renvoie un objet PartialDependence. Ou un tas. Mais il ne renvoie pas d'estimateur.

Point pris.

Une option (sans dire que c'est la meilleure) serait d'avoir tous les
les fonctions de calcul renvoient des tuples nommés et tous les calculs correspondants
les fonctions prennent ceci. Ce serait un peu conforme à la modernité
ajouts à la bibliothèque standard Python.

et je n'aime pas prendre des décisions de nommage / API sans pouvoir écrire des exemples ;)

Je suis comme vous.

Donc, si le calcul est coûteux, nous pouvons faire le calcul en dehors de la fonction. Si c'est le cas, nous retournons un objet et la fonction de traçage prend cet objet en entrée, n'est-ce pas ? Je voterai +1.

Et peut-être que nous avons besoin d'un autre problème pour en discuter :)

L'avantage de la suggestion de confusion_matrix . Là, un tuple ne serait pas strictement nécessaire mais alors l'interface devient légèrement incohérente.

@qinhanmin2014 si nous retournons des objets arbitraires, nous devons déprécier le type de retour d'une fonction à chaque fois que nous créons un assistant de traçage. Cela ressemble à un gâchis.

J'ai eu une idée, puis une deuxième meilleure idée :
1) créer une seconde interface orientée objet qui appelle la fonction existante, stocke l'objet et possède une méthode de tracé, comme

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

Cela résoudrait le problème, mais dupliquerait certaines interfaces et ce serait un peu flou. En fait, le même principe peut être fait d'une manière que je pense plus intuitive:
2) que la fonction plot_ fasse toujours le travail, utilisez le résultat pour instancier un objet qui stocke le résultat et le trace :

plot_confusion_matrix(y, y_pred)

serait donc simplement tracé et renverrait un objet ConfusionMatrixPlotter , qui stocke le résultat, et a une méthode plot .
Ainsi, dans le cas simple d'un seul tracé, il ne s'agit que d'un seul appel de fonction. Si vous souhaitez ensuite que les résultats en fassent autre chose, ils sont stockés dans l'objet. Si vous souhaitez tracer à nouveau, vous pouvez simplement appeler à nouveau plot sur l'objet. Si vous avez déjà calculé les résultats et que vous décidez ensuite de tracer, vous pouvez instancier directement ConfusionMatrixPlotter .

Bien que cela expose une classe supplémentaire pour les cas d'utilisation les plus complexes, je pense que c'est un compromis raisonnable car il a une bonne réponse à toutes les situations.

serait donc simplement tracé et renverrait un objet ConfusionMatrixPlotter, qui stocke le résultat et possède une méthode de tracé.

Pourquoi les utilisateurs doivent-ils à nouveau tracer les mêmes données ? @amueller ajuster le format ?

@qinhanmin2014 oui,

@qinhanmin2014 oui,

Je doute qu'il soit utile d'examiner ces problèmes de formatage ici. Les utilisateurs peuvent commencer avec une petite partie de l'ensemble de données ?

Et @amueller, nous prendrons en charge les axes de passage, afin que les utilisateurs puissent facilement ajuster le tracé après avoir appelé les fonctions de traçage ?

@qinhanmin2014 non, beaucoup de choses ne peuvent pas être facilement modifiées par la suite, et nous n'avons pas besoin de penser à tout le formatage nécessairement nous-mêmes, mais nous devrions permettre aux utilisateurs de tracer quelque chose à nouveau. Cela se produira à chaque fois que vous ferez un complot. Et devoir sous-échantillonner des ensembles de données à chaque fois que je veux faire un tracé est un peu ennuyeux. Et si je change d'avis plus tard, je devrai toujours recalculer.
Fondamentalement, le fait est que vous ne pouvez généralement pas anticiper exactement ce que vous voulez dans votre analyse exploratoire, et devoir tout recalculer pour changer une visualisation ne semble pas génial.

@qinhanmin2014 non, beaucoup de choses ne peuvent pas être facilement modifiées par la suite, et nous n'avons pas besoin de penser à tout le formatage nécessairement nous-mêmes, mais nous devrions permettre aux utilisateurs de tracer quelque chose à nouveau. Cela se produira à chaque fois que vous ferez un complot. Et devoir sous-échantillonner des ensembles de données à chaque fois que je veux faire un tracé est un peu ennuyeux. Et si je change d'avis plus tard, je devrai toujours recalculer.

Oui, je sais que cela peut être utile, mais le problème principal ici est que nous n'avons pas de moyen propre de prendre en charge cette fonctionnalité, et je suppose que la plupart des fonctions de traçage ne nécessitent pas beaucoup de calculs ?

J'aime que nous discutions de cela avec un peu plus de terrain, mais je suis
toujours pas tout à fait convaincu que nous avons même besoin d'avoir un complot dans l'importation
chemin du tout. Après tout, nous semblons avoir plot_ comme préfixe pour le
les fonctions. La question concerne également plot_tree : pourquoi devrait- il être
séparé des autres codes d'exportation et de visualisation textuelle ?

@qinhanmin2014 Je ne pense pas que "nous n'avons pas encore une bonne API" soit une bonne raison.
Et la dépendance partielle, l'importance de la permutation, les courbes d'apprentissage, les courbes de validation et les résultats de GridSearchCV et RandomizedSearchCV sont tous des exemples courants qui nécessitent beaucoup de calculs. Bien que pour gridsearchcv et randomizedsearchcv la chose évidente serait de passer soit l'objet soit le cv_results_ , faire le travail à l'intérieur de la fonction de traçage dans ces cas semble absurde. Je ne suis pas tout à fait sûr des courbes d'apprentissage et des courbes de validation.

@jnothman Je pense que @GaelVaroquaux voulait garder la dépendance matplotlib confinée à un module et c'était l'une des principales motivations ? Je n'ai pas encore d'idées très cohérentes à ce sujet.

Et la dépendance partielle, l'importance de la permutation, les courbes d'apprentissage, les courbes de validation et les résultats de GridSearchCV et RandomizedSearchCV sont tous des exemples courants qui nécessitent beaucoup de calculs.

Merci, je réalise maintenant que je me trompe :)
Bien que je ne parvienne toujours pas à comprendre pourquoi il est important de fournir aux utilisateurs un moyen de tracer sans recalculer. Mais si d'autres le pensent et qu'il y a un bon moyen, je voterai +1.

J'aime que nous discutions de cela avec un peu plus de terrain, mais je suis
toujours pas tout à fait convaincu que nous avons même besoin d'avoir un complot dans l'importation
chemin du tout. Après tout, nous semblons avoir plot_ comme préfixe pour le
les fonctions. La question concerne également plot_tree : pourquoi devrait- il être
séparé des autres codes d'exportation et de visualisation textuelle ?

Oui, cela peut aussi être une option. Si c'est le cas, nous pouvons mentionner que toutes les fonctions qui commencent par plot_ nécessitent matplotlib. Un autre avantage de cette option est que nous n'avons pas besoin de déplacer des fonctions existantes.

En parcourant cette discussion, je suis d'accord pour ne pas ajouter sklearn.plot module plot_ pour signaler une exigence matplotlib .

Par exemple, dans https://github.com/scikit-learn/scikit-learn/pull/12599 , partial_dependence et plot_partial_dependence seront placés dans inspection .

D'accord, à moins que quelqu'un ne soit en désaccord avec cela dans les jours suivants, je vais mettre à jour le PR PDP et :

• mettre à la fois partial_dependence et plot_partial_dependence dans sklearn.inspection
• faites en sorte que plot_partial_dependence retourne un tas avec les objets fig et ax comme attributs (en ce moment, il les retourne dans un tuple). De cette façon, nous pourrons garder ces 2 fonctions rétrocompatibles lorsque nous implémenterons la deuxième option de https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520

Pouvons-nous prendre la décision finale ici?
Proposition acceptée par @jnothman , @NicolasHug et moi (excuses si je me trompe) : sklearn.XXX.plot_YYY (support de sklearn.XXX import plot_YYY). Nous mentionnerons que toutes les fonctions qui commencent par plot_ nécessitent matplotlib.
Un avantage majeur de cette proposition est que nous n'avons pas besoin de déplacer des fonctions existantes.

Dormir dessus, je pense que c'est assez simple à expliquer et cela évite la difficulté de penser à une API de traçage partagée entre différents modules.

Oui, faisons-le. Créez une fonction d'assistance pour fournir un
Erreur d'importation

Pour info, j'ajoute sklearn.utils.check_matplotlib_support dans #12599

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

Pour info, j'ajoute sklearn.utils.check_matplotlib_support dans #12599

C'est génial! Merci.