Obrigado por abrir este problema, ping @jnothman @amueller @GaelVaroquaux de acordo com gitter

8425 não está relacionado às regiões de decisão dos classificadores ,?

Eu prefiro mover plot_tree e plot_partial_dependence para sklearn.plot e resolver # 13335 em 0.21 (talvez introduzir uma função para plotar o limite de decisão, uma vez que é importante e não é fácil para iniciantes IMO). O que os outros pensam?

Para ajudar a controlar o escopo de sklearn.plot, proponho que façamos a plotagem apenas no nível dos eixos e não no nível da figura. O usuário passaria os eixos como uma palavra-chave. Por conveniência, o padrão dos eixos será Nenhum. Somente neste caso, a função de plotagem gerará um eixo / figura para plotar.

Boa ideia, mas não consistente com as funções existentes (plot_tree e plot_partial_dependence), certo?

Há casos em que você precisa produzir / modificar uma figura, como com
múltiplos subplots (veja os gráficos de faceta do nativo do mar etc, e upsetplot para
exemplo). Você pode dar razões pelas quais deseja limitá-lo aos eixos?

Na sexta-feira, 15 de março de 2019, 2h19, Hanmin Qin, [email protected] escreveu:

Obrigado por abrir este problema, ping @jnothman
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquaux de acordo com gitter

8425 https://github.com/scikit-learn/scikit-learn/issues/8425 não é

relacionado às regiões de decisão dos classificadores ,?
Eu prefiro mover plot_tree e plot_partial_dependence para sklearn.plot e
resolve # 13335 https://github.com/scikit-learn/scikit-learn/issues/13335
em 0,21 (talvez introduzir uma função para traçar o limite de decisão, uma vez que
é importante e não é fácil para iniciantes (IMO). O que os outros pensam?

Para ajudar a controlar o escopo de sklearn.plot, proponho que façamos apenas plotagem
no nível dos eixos e não no nível da figura. O usuário passaria nos eixos
como uma palavra-chave. Por conveniência, o padrão dos eixos será Nenhum. Apenas em
neste caso, a função de plotagem gerará eixos / figura para plotar.

Boa ideia, mas não consistente com as funções existentes (plot_tree e
plot_partial_dependence), certo?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

Boa ideia, mas não consistente com as funções existentes (plot_tree e plot_partial_dependence), certo?

@ qinhanmin2014 plot_tree não parece ajustar a figura. plot_partial_dependence faz plotagens múltiplas com base em features . Embora, ele possa ser refatorado em um gráfico de nível de eixos. Um usuário precisaria chamar plot_partial_dependence várias vezes, fornecendo diferentes eixos (e recursos).

Você pode dar razões pelas quais deseja limitá-lo aos eixos?

@jnothman Seaborn tem uma documentação que separa claramente o gráfico "no nível da figura" e o gráfico no "nível dos eixos". Se pudermos documentar adequadamente esse comportamento no scikit-learn, é possível ter esses gráficos de "nível de figura". Minha maior preocupação com os gráficos de "nível de figura" é que eles são mais difíceis de manter e testar. Haverá elementos de um eixo que podem se sobrepor a outros eixos. No entanto, podemos contornar isso estruturando as figuras de forma que a sobreposição aconteça com menos frequência.

Em termos de teste, podemos seguir o caminho do mar e testar objetos matplotlib diretamente ou o caminho de tijolos amarelos, onde fazemos testes de nível de pixel. Eu tendo a favorecer o teste de objetos matplotlib.

Meus 2 centavos:

• +1 para conter as funções que acessam matplotlib em um subpacote comum, ou, em um módulo em cada subpacote (sklearn.linear_models.plot, sklearn.ensemble.plot).

• Conforme mencionado por @thomasjpfan , apenas acessar os eixos torna mais fácil o teste.

  Além disso, há muito tempo, havia uma discussão no ecossistema para dar a outros back-ends de plotagem um objeto semelhante a "Machados" para compatibilidade. Eu não sei para onde isso foi. Uma rápida pesquisa no Google não mostra muito. O mais próximo é plotly.tools.mpl_to_plotly, que realmente não precisa dessa restrição, então acho que esse argumento é vão.

talvez introduza uma função para traçar o limite de decisão, uma vez que é importante e não é fácil para iniciantes IMO

Eu concordo, mas também acho que mostrar aos usuários como traçar resultados, como limites de decisão, é um dos objetivos dos exemplos.

Se eu quiser uma plotagem rápida de um resultado, as funções de plotagem são ótimas, especialmente para plotagens complicadas como plotar uma árvore, mas muitas vezes gosto de ajustar a plotagem de acordo com minhas necessidades e, por esse motivo, prefiro confiar em exemplos existentes e modificar o código.

Quanto ao nome do módulo, IMO inspect é mais versátil do que plot :

• Não consigo pensar em nenhum enredo que não seja algum tipo de inspeção
• # 12599 (Dependência parcial) já apresenta inspect

IMO inspect é mais versátil do que plot

sem opinião forte, votará +1 para ambos os nomes. Talvez o enredo seja mais direto?

Novamente, estou interessado em criar o novo módulo antes de 0.21 e mover plot_tree e plot_partial_dependence para lá. Idealmente, devemos também chegar a um consenso sobre o API (por exemplo, nível de eixos / nível de figura).

Outro ponto a favor de inspect :

Podemos querer inspecionar ferramentas que oferecem plotagem como uma opção. Por exemplo, imprima as características de uma árvore (número de nós, folhas, pontos de divisão, etc.) e, opcionalmente, plote-as com matplotlib.

Eu seria a favor do uso de eixos em vez de figuras, como sugerido (suspiro, vou precisar alterar os PDPs novamente). É mais fácil para nós apoiar e testar. É um pouco mais trabalhoso para os usuários, mas também permite mais controle.

IMO inspect é mais versátil do que plot

sem opinião forte, votará +1 para ambos os nomes. Talvez o enredo seja mais direto?

"inspect" é carregado no Python (é um módulo na biblioteca padrão). eu
evitaria usar o mesmo nome.

Novamente, estou interessado em criar o novo módulo antes de 0.21 e mover plot_tree e plot_partial_dependence para lá. Idealmente, devemos também chegar a um consenso sobre o API (por exemplo, nível de eixos / nível de figura).

Isso não deve atrasar 0,21. Nosso objetivo é lançar o mais cedo possível, e esperançosamente
libere mais cedo novamente.

"inspect" é carregado no Python (é um módulo na biblioteca padrão). eu
evitaria usar o mesmo nome.

Proponho model_inspection . Vai bem com o nosso nome model_selection .

Podemos querer inspecionar algo que não seja um modelo (codificador, pré-processador, resultados de pesquisa de grade ...)

inspection então?

Essas coisas também são modelos :)

A sugestão de Gael de um submódulo de enredo público em cada subpacote vale
considerando.

FWIW, eu também prefiro plot a inspect , já que é mais intuitivo para a maioria dos usuários encontrá-lo. As pessoas estão mais propensas a tentar _plot_ seus modelos do que a _inspectar_ seus modelos (ao pesquisar em mecanismos de pesquisa, por exemplo, ou olhando as possíveis opções de preenchimento automático em seu IDE).

A sugestão de Gael de um submódulo de enredo público em cada subpacote vale a pena considerar.

Em caso afirmativo, onde devemos colocar plot_decision_boundary ?

Em relação ao # 12599, @NicolasHug , duvido que partial_dependence deva estar no novo módulo. (ou seja, ensemble.partial_dependence + plot.plot_partial_dependence)

Em caso afirmativo, onde devemos colocar plot_decision_boundary?

sklearn.plot?

Não quero forçar muito por essa solução. No entanto, eu concordo com
a sensação de que o "enredo" pode ser mais fácil de descobrir para os usuários finais.

Em relação ao # 12599, @NicolasHug , duvido que o partial_dependence deva estar no novo módulo. (ou seja, ensemble.partial_dependence + plot.plot_partial_dependence)

Eu não entendo o que você quer dizer. # 12599 desaprova ensemble.partial_dependence em favor de inspect.partial_dependence (é claro que inspect está sujeito a alterações com base nesta discussão). A API também difere entre as 2 implementações.

Estou bem com plot , estou apenas preocupado com uma possível alta sobreposição com um eventual módulo de inspeção, mas não vou insistir nisso :)

vale a pena considerar um submódulo de enredo público em cada subpacote.

Mas até agora todas as ferramentas de plotagem propostas (PDPs, calibração, matriz de confusão e região de decisão) não são específicas para um único módulo.

Eu não entendo o que você quer dizer. # 12599 descontinua ensemble.partial_dependence em favor de inspect.partial_dependence (é claro que inspect está sujeito a alterações com base nesta discussão). A API também difere entre as 2 implementações.

Desculpas, não olhei para esse PR em detalhes. Talvez inspect.partial_dependence + plot.plot_partial_dependence ?

Talvez inspect.partial_dependence + plot.plot_partial_dependence?

Gosto de uma separação clara entre calcular os valores e traçá-los.
É um modelo / visão como a separação e deve ajudar a aumentar o
reutilização.

Gaël não estava propondo sklearn.inspect.partial_dependence e
sklearn.inspect.plot.plot_partial_dependence (Substitua algum outro nome
para inspecionar, se apropriado)? Eu não me importo com isso.

Gaël não estava propondo sklearn.inspect.partial_dependence e sklearn.inspect.plot.plot_partial_dependence (substitua algum outro nome por inspecionar, se apropriado)?

Sim, mas perguntei a ele onde devemos colocar plot_decision_boundary e parece que ele mudou de ideia?

Para sua informação, atualizei o PDP PR https://github.com/scikit-learn/scikit-learn/pull/12599 seguindo as recomendações acima:

• partial_dependence está em sklearn.model_inspection
• plot_partial_dependence está em skearn.plot

Os documentos estão aqui https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

Observe que o guia do usuário inclui apenas o módulo plot por enquanto. Não acho que faça sentido ter uma seção de guia do usuário que fale apenas sobre model_inspection.partial_dependence , uma vez que suas restrições / comportamento são as mesmas de plot_partial_dependence .

(Este é o tipo de sobreposição que me preocupou)

Claro, se você acha que ainda é melhor ter guias do usuário separados para partial_dependence e plot_partial_dependence , eu farei isso.

Para sua informação, atualizei o PDP PR # 12599 seguindo as recomendações acima:
parcial_dependência está em sklearn.model_inspection
plot_partial_dependence está em skearn.plot

+1

Observe que o guia do usuário inclui apenas o módulo de plotagem por enquanto. Não acho que faça sentido ter uma seção de guia do usuário que fale apenas sobre model_inspection.partial_dependence, uma vez que suas restrições / comportamento é o mesmo de plot_partial_dependence.

+1

Então, decidimos usar o nome sklearn.plot?

Acho que sklearn.plot importar dependências de sklearn é um pouco estranho quando evitamos colocar todos no namespace raiz.

Então você prefere sklearn.model_inspection.plot e coloca plot_partial_dependence() lá?

Sem módulo plot , estou bem com isso

Acho que prefiro assim. Ainda não tenho certeza de como ele se generaliza.

Acho que prefiro assim. Ainda não tenho certeza de como ele se generaliza.

Contanto que possamos descobrir um lugar apropriado para colocar coisas como plot_decision_boundary , votarei +1 para sklearn.XXX.plot .

Isso precisa de um slep? não parecemos estar fazendo muito progresso

EDIT ugh, estou com sono, leio o comentário de Joel, pois não acho que prefiro isso , desculpe

Isso precisa de um slep? não parecemos estar fazendo muito progresso

Estou bem com qualquer solução ( sklearn.plot / sklearn.XXX.plot ). O principal problema aqui, IMO, é que ninguém me diz onde colocaremos coisas como plot_decision_boundary se usarmos sklearn.XXX.plot :)

sklearn.model_inspection.plot ?

sklearn.model_inspection.plot?

Ideia interessante, vou votar +1. Talvez não seja tão bom jogar tudo em sklearn.plot (https://github.com/rasbt/mlxtend coloque todas as funções de plotagem em um único módulo).

Portanto, apoiaremos from sklearn.XXX.plot import plot_XXX ? Vamos apoiar from sklearn.XXX import plot_XXX ?

Acho que o requisito explícito de .plot na importação é algo
outros aqui procuraram.

Há também o invertido de sklearn.plot.XXX import plot_YYY

Acho que o requisito explícito de .plot na importação é algo que outros aqui buscaram.

Então, chegamos a um consenso para usar sklearn.XXX.plot (suporte apenas de sklearn.XXX.plot import plot_XXX )?

Há também o invertido de sklearn.plot.XXX import plot_YYY

Eu não consigo entender.

Há também o invertido de sklearn.plot.XXX import plot_YYY

Eu quis dizer que poderíamos ter
sklearn.plot.model_inspection.plot_partial_dependence em vez de
sklearn.model_inspection.plot.plot_partial_dependence. Não tenho certeza se isso
fornece qualquer benefício / clareza.

Eu quis dizer que poderíamos ter
sklearn.plot.model_inspection.plot_partial_dependence em vez de
sklearn.model_inspection.plot.plot_partial_dependence. Não tenho certeza se isso
fornece qualquer benefício / clareza.

Portanto, agora temos 3 opções:
(1) sklearn.plot.plot_YYY (por exemplo, sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (por exemplo, sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (por exemplo, sklearn.tree.plot.plot_tree, não suporta sklearn.XXX import plot_YYY)
Vou votar +1 para todas essas soluções.
Eu prefiro tomar a decisão antes de 0,21 para evitar o uso de sklearn.tree.plot_tree

Não tenho certeza se precisa de um sono, mas pode valer a pena convidar opiniões sobre o
lista de correio

Não tenho certeza se precisa de um sono, mas pode valer a pena convidar opiniões na lista de e-mails

+1. Não se enquadra nos critérios de SLEPs, ao que parece.

Como eu disse na lista de discussão, acho que deveríamos realmente considerar "onde o trabalho acontece" ou como será a interface. Isso já não estava claro para dependência parcial.
plot_partial_dependence chamar partial_dependence ou obter a saída de partial_dependence como entrada? Esta questão é válida para basicamente todas as funções do enredo.
A principal consideração que discuto com plot_X call compute_X é conveniente para o usuário - contanto que ele só queira traçar a coisa uma vez. Se eles não gostarem da trama e quiserem mudar algo, eles precisam compute_X novamente, o que é potencialmente um desperdício.

Então nós poderíamos

• sempre pegue o resultado de compute_X . desvantagem: inconveniente e sujeito a erros: qual era a ordem de precisão, recuperação e limites novamente em precision_recall_curve?

• sempre pegue a entrada para compute_X e chame compute_X de plot_X . desvantagem: você precisa recalcular para cada plotagem.

• permitir ambos, então plot_X pode levar a entrada para compute_X e chamar compute_X ou pegar a saída de compute_X se o usuário já a criou. Isso tem a desvantagem de complicar a assinatura (e possivelmente complicar sua documentação). Além disso, se o usuário chamar plot_X para que ele faça compute_X internamente e depois quiser outro gráfico, ele precisará compute_X novamente. Portanto, você precisa antecipar que deseja mais de um gráfico antes de chamar plot_X pela primeira vez. Ou você precisa expor o resultado de compute_X ao chamar plot_X , mas não está claro para mim como fazer isso sem um design orientado a objetos

• tomar a decisão dependendo de quão caro compute_X é, pois para a matriz de confusão e gráficos de dependência parcial e gráficos de calibração não nos importamos com o custo de recomputação, mas sim para gráficos de dependência parcial. desvantagem: interface inconsistente.

A principal consideração que discuto com

+1000. É um problema comum que vejo no código de pesquisa.

De um problema de design, ele viola uma separação MVC (um pouco pedante,
desculpa).

Nas várias soluções que você propõe, você consideraria tomar um
modelo ajustado como uma abordagem? Eu sinto que isso iria mitigar o problema de
lembrando a ordem dos parâmetros. Mas talvez existam
problemas.

Não tenho certeza do que você entende por modelo ajustado. Freqüentemente, a saída da computação não é um modelo ajustado. Poderíamos definir objetos para todos os resultados de computação, de forma que partial_dependence retornasse um objeto PartialDependence . Ou um monte. Mas não retorna um estimador.

Ah, o motivo pelo qual trago isso agora: sem essa decisão, não tenho ideia de como será o código do usuário e não gosto de tomar decisões de nomenclatura / API sem ser capaz de escrever exemplos;)

retornar um objeto seria muito diferente do sklearn, imho. Mas pode resolver o problema de localização: pode ter plot métodos;)

Freqüentemente, a saída da computação não é um modelo ajustado. Poderíamos definir objetos para todos os resultados de computação, de forma que partial_dependence retornasse um objeto PartialDependence. Ou um monte. Mas não retorna um estimador.

Ponto tomado.

Uma opção (não dizendo que é a melhor) seria ter todos os
funções de computação retornam tuplas nomeadas e todos os cálculos correspondentes
funções levam isso. Seria um pouco consistente com o moderno
adições à biblioteca padrão do Python.

e não gosto de tomar decisões de nomenclatura / API sem ser capaz de escrever exemplos;)

Eu sou como você.

Portanto, se o cálculo for caro, podemos fazer o cálculo fora da função. Em caso afirmativo, retornamos um objeto e a função de plotagem pega esse objeto como sua entrada, certo? Vou votar +1.

E talvez precisemos de outro problema para discutir isso :)

O benefício da sugestão de confusion_matrix . Nesse caso, uma tupla não seria estritamente necessária, mas a interface se tornaria ligeiramente inconsistente.

@ qinhanmin2014 se retornarmos objetos arbitrários, teremos que descontinuar o tipo de retorno de uma função toda vez que criarmos um auxiliar de plotagem. Isso parece uma bagunça.

Tive uma ideia, e depois uma segunda ideia melhor:
1) criar uma segunda interface orientada a objetos que chama a função existente, armazena o objeto e tem um método de plotagem, como

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

Isso resolveria o problema, mas duplicaria alguma interface e ficaria um pouco confuso. Na verdade, o mesmo princípio pode ser feito de uma forma que eu acho mais intuitiva:
2) fazer com que a função plot_ sempre faça o trabalho, use o resultado para instanciar um objeto que armazena o resultado e o plota:

plot_confusion_matrix(y, y_pred)

por isso, apenas plotaria e retornaria um objeto ConfusionMatrixPlotter , que armazena o resultado e tem um método plot .
Portanto, no caso simples de traçar apenas uma vez, é apenas uma única chamada de função. Se você quiser que os resultados façam algo mais com eles, eles serão armazenados no objeto. Se você quiser plotar novamente, você pode simplesmente chamar plot no objeto novamente. Se você já computou os resultados e depois decidiu que deseja plotar, você pode instanciar ConfusionMatrixPlotter diretamente.

Embora isso exponha uma classe adicional para os casos de uso mais complexos, acho que é uma troca razoável porque tem uma boa resposta para todas as situações.

seria, portanto, apenas plotar e retornar um objeto ConfusionMatrixPlotter, que armazena o resultado e tem um método de plotagem.

Por que os usuários precisam traçar os mesmos dados novamente? @amueller ajustar o formato?

@ qinhanmin2014 sim,

@ qinhanmin2014 sim,

Duvido que valha a pena considerar essas questões de formatação aqui. Os usuários podem iniciar uma pequena parte do conjunto de dados?

E @amueller ofereceremos suporte para a passagem de eixos, para que os usuários possam ajustar facilmente o gráfico depois de chamar as funções de plotagem?

@ qinhanmin2014 não, muitas coisas não podem ser alteradas facilmente depois, e não precisamos necessariamente pensar em toda a formatação, mas devemos permitir que os usuários traçam algo novamente. Basicamente, isso acontecerá a qualquer momento que você fizer um enredo. E ter que subamostrar conjuntos de dados toda vez que quero fazer um gráfico é um pouco chato. E se eu mudar de ideia posteriormente, ainda terei de refazer o cálculo.
Basicamente, a questão é que geralmente você não pode antecipar exatamente o que deseja em sua análise exploratória, e ter que recalcular tudo para alterar uma visualização não parece ótimo.

@ qinhanmin2014 não, muitas coisas não podem ser alteradas facilmente depois, e não precisamos necessariamente pensar em toda a formatação, mas devemos permitir que os usuários traçam algo novamente. Basicamente, isso acontecerá a qualquer momento que você fizer um enredo. E ter que subamostrar conjuntos de dados toda vez que quero fazer um gráfico é um pouco chato. E se eu mudar de ideia posteriormente, ainda terei de refazer o cálculo.

Sim, eu sei que pode ser útil, mas o principal problema aqui é que não temos uma maneira limpa de oferecer suporte a essa funcionalidade e acho que a maioria das funções de plotagem não exige muitos cálculos.

Eu gosto de estarmos discutindo isso com um pouco mais de aterramento, mas tbh estou
ainda não totalmente convencido de que ainda precisamos ter enredo na importação
caminho em tudo. Afinal, parece que temos plot_ como um prefixo para o
funções. A questão também se relaciona com plot_tree: por que deveria ser
separado de outro código de exportação e visualização textual?

@ qinhanmin2014 Não acho que "ainda não temos uma boa API" seja um bom motivo.
E dependência parcial, importância de permutação, curvas de aprendizado, curvas de validação e resultados de GridSearchCV e RandomizedSearchCV são exemplos comuns que exigem muito cálculo. Embora para gridsearchcv e randomizedsearchcv a coisa óbvia seria passar o objeto ou cv_results_ , fazer o trabalho dentro da função de plotagem nesses casos parece absurdo. Não estou totalmente certo sobre curvas de aprendizado e curvas de validação tbh.

@jnothman Acho que @GaelVaroquaux queria manter a dependência de matplotlib confinada a um módulo e essa foi uma das principais motivações? Eu realmente não tenho pensamentos muito coerentes sobre isso ainda.

E dependência parcial, importância de permutação, curvas de aprendizado, curvas de validação e resultados de GridSearchCV e RandomizedSearchCV são exemplos comuns que exigem muito cálculo.

Obrigado, agora percebi que estou errado :)
Embora eu ainda não consiga entender por que é importante fornecer aos usuários uma maneira de plotar sem recomputar. Mas se outros acharem que sim e houver uma boa maneira, votarei +1.

Eu gosto de estarmos discutindo isso com um pouco mais de aterramento, mas tbh estou
ainda não totalmente convencido de que ainda precisamos ter enredo na importação
caminho em tudo. Afinal, parece que temos plot_ como um prefixo para o
funções. A questão também se relaciona com plot_tree: por que deveria ser
separado de outro código de exportação e visualização textual?

Sim, isso também pode ser uma opção. Nesse caso, podemos mencionar que todas as funções que começam com plot_ requerem matplotlib. Outra vantagem dessa opção é que não precisamos mover as funções existentes.

Repassando esta discussão, concordo em não adicionar um módulo sklearn.plot e usar o prefixo plot_ para sinalizar um requisito matplotlib .

Por exemplo, em https://github.com/scikit-learn/scikit-learn/pull/12599 , partial_dependence e plot_partial_dependence serão colocados em inspection .

Ok, a menos que alguém discorde disso nos próximos dias, vou atualizar o PDP PR e:

• coloque partial_dependence e plot_partial_dependence em sklearn.inspection
• fazer plot_partial_dependence retornar um monte com os objetos fig e ax como atributos (agora ele os retorna em uma tupla). Dessa forma, poderemos manter essas 2 funções compatíveis com versões anteriores quando implementarmos a segunda opção de https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520

Podemos tomar a decisão final aqui?
Proposta acordada por @jnothman , @NicolasHug e eu (desculpas se eu estiver errado): sklearn.XXX.plot_YYY (suporte de sklearn.XXX import plot_YYY). Mencionaremos que todas as funções que começam com plot_ requerem matplotlib.
Uma grande vantagem desta proposta é que não precisamos mover as funções existentes.

Pensando nisso, acho que é simples de explicar e evita a dificuldade de pensar em uma API de plotagem compartilhada entre diferentes módulos.

Sim, vamos fazer isso. Faça uma função auxiliar para fornecer uma função mais útil
ImportError

Para sua informação, estou adicionando sklearn.utils.check_matplotlib_support em # 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

Para sua informação, estou adicionando sklearn.utils.check_matplotlib_support em # 12599

Isso é ótimo! Obrigado.