Спасибо за открытие этого выпуска, пингуйте @jnothman @amueller @GaelVaroquaux согласно gitter

8425 не имеет отношения к областям принятия решений классификаторов ,?

Я предпочитаю переместить plot_tree и plot_partial_dependence в sklearn.plot и решить # 13335 в 0.21 (возможно, ввести функцию для построения границы решения, так как это важно и непросто для начинающих IMO). Что думают другие?

Чтобы помочь контролировать объем sklearn.plot, я предлагаю рисовать только на уровне осей, а не на уровне фигуры. Пользователь будет передавать оси в качестве ключевого слова. Для удобства осями по умолчанию будет None. Только в этом случае функция построения графика сгенерирует оси / фигуру для построения графика.

Хорошая идея, но несовместимая с существующими функциями (plot_tree и plot_partial_dependence), верно?

Есть случаи, когда вам нужно вывести / изменить фигуру, например, с помощью
несколько подзаголовков (см. фасетные графики seaborn и т. д., а также расстроенный график для
пример). Можете ли вы назвать причины, по которым вы хотите ограничиться осями?

Пт, 15 марта 2019 г., 2:19, Ханмин Цинь, [email protected] написал:

Спасибо, что открыли этот выпуск, ping @jnothman
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquaux согласно gitter

8425 https://github.com/scikit-learn/scikit-learn/issues/8425 не является

связанные с областями принятия решений классификаторов ,?
Я предпочитаю переместить plot_tree и plot_partial_dependence в sklearn.plot и
решить # 13335 https://github.com/scikit-learn/scikit-learn/issues/13335
в 0.21 (можно ввести функцию для построения границы решения, поскольку
это важно и непросто для новичков ИМО). Что думают другие?

Чтобы помочь контролировать объем sklearn.plot, я предлагаю нам только строить графики
на уровне осей, а не на уровне фигуры. Пользователь будет передавать оси
как ключевое слово. Для удобства осями по умолчанию будет None. Только в
в этом случае будет ли функция построения графика генерировать оси / фигуру для построения графика.

Хорошая идея, но несовместимая с существующими функциями (plot_tree и
plot_partial_dependence), верно?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

Хорошая идея, но несовместимая с существующими функциями (plot_tree и plot_partial_dependence), верно?

@ qinhanmin2014 plot_tree , похоже, не корректирует цифру. plot_partial_dependence действительно создает несколько графиков на основе features . Хотя, его можно реорганизовать в график уровня осей. Пользователю нужно будет вызвать plot_partial_dependence несколько раз, задав ему разные оси (и функции).

Можете ли вы назвать причины, по которым вы хотите ограничиться осями?

@jnothman Seaborn имеет документацию, в которой четко разделяются графики "на уровне фигуры" и "на уровне осей". Если мы сможем должным образом задокументировать это поведение в scikit-learn, можно будет получить эти графики «на уровне рисунка». Меня больше всего беспокоят графики "фигурного уровня", потому что их сложнее поддерживать и тестировать. Будут элементы одной оси, которые могут перекрываться с другой осью. Хотя мы можем обойти это, структурируя фигуры таким образом, чтобы перекрытия происходили реже.

Что касается тестирования, мы можем пойти путем морского исследования и напрямую протестировать объекты matplotlib или методом желтого кирпича, где мы проводим тестирование на уровне пикселей. Я предпочитаю тестирование объектов matplotlib.

Мои 2 цента:

• +1 для содержания функций, обращающихся к matplotlib в общем подпакете, или в модуле в каждом подпакете (sklearn.linear_models.plot, sklearn.ensemble.plot).

• Как упоминал @thomasjpfan , только доступ к осям упрощает тестирование.

  Кроме того, давным-давно в экосистеме обсуждалась возможность предоставления другим серверным модулям построения графиков объекта типа «Axes» для совместимости. Я не знаю, куда это делось. Быстрый поиск в Google мало что показывает. Ближайшим из них является plotly.tools.mpl_to_plotly, которому на самом деле не нужно это ограничение, поэтому я считаю этот аргумент напрасным.

возможно, ввести функцию для построения границы решения, так как это важно и непросто для новичков. ИМО.

Я согласен, но я также считаю, что одна из целей примеров - показать пользователям, как наносить на график результаты, такие как границы решений.

Если мне нужен быстрый первый график результата, функции построения отлично подходят, особенно для сложных графиков, таких как построение дерева, но мне очень часто нравится настраивать график в соответствии со своими потребностями, и по этой причине я предпочитаю полагаться на существующие примеры и изменить код.

Что касается имени модуля, IMO inspect более универсален, чем plot :

• Я не могу придумать ни одного сюжета, кроме инспекции
• # 12599 (Частичная зависимость) уже представляет inspect

IMO inspect более универсален, чем сюжет

нет твердого мнения, проголосую +1 за оба имени. Может сюжет попроще?

Я снова хочу создать новый модуль до версии 0.21 и переместить туда plot_tree и plot_partial_dependence. В идеале мы также должны достичь консенсуса по API (например, уровень осей / уровень фигуры).

Другой аргумент в пользу inspect :

Мы можем захотеть проверить инструменты, которые предлагают построение графиков в качестве опции. Например, распечатайте характеристики дерева (количество узлов, листьев, точек разделения и т. Д.) И, при желании, нанесите его на график с помощью matplotlib.

Я был бы за использование осей вместо цифр, как это было предложено (вздох, мне нужно снова поменять PDP). Нам проще поддерживать и тестировать. Это немного больше для пользователей, но также дает больше контроля.

IMO inspect более универсален, чем сюжет

нет твердого мнения, проголосую +1 за оба имени. Может сюжет попроще?

"inspect" загружен в Python (это модуль в стандартной библиотеке). я
не использовал бы одно и то же имя.

Я снова хочу создать новый модуль до версии 0.21 и переместить туда plot_tree и plot_partial_dependence. В идеале мы также должны достичь консенсуса по API (например, уровень осей / уровень фигуры).

Это не должно задерживать 0,21. Наша цель - выпустить раньше, и, надеюсь,
выпустить снова рано.

"inspect" загружен в Python (это модуль в стандартной библиотеке). я
не использовал бы одно и то же имя.

Предлагаю model_inspection . Он хорошо сочетается с нашим именем model_selection .

Возможно, мы захотим проверить что-то, что не является моделью (кодировщик, препроцессор, результаты поиска по сетке ...)

inspection тогда?

Это тоже модели :)

Предложение Гаэля о подмодуле публичного сюжета в каждом пакете стоит
учитывая.

FWIW, я бы также предпочел plot inspect , поскольку для большинства пользователей это более интуитивно понятно. Люди чаще пытаются строить свои модели, чем проверять их (например, при поиске в поисковых системах или при просмотре возможных вариантов автозаполнения в своей среде IDE).

Стоит рассмотреть предложение Гаэля о подмодуле публичного сюжета для каждого подпакета.

Если да, то где положить plot_decision_boundary ?

Что касается # 12599, @NicolasHug, я сомневаюсь, что partial_dependence должно быть в новом модуле. (т.е. ensemble.partial_dependence + plot.plot_partial_dependence)

Если да, то где мы должны поместить plot_decision_boundary?

sklearn.plot?

Я не хочу слишком сильно настаивать на этом решении. Однако я согласен с
ощущение, что конечным пользователям легче обнаружить «заговор».

Что касается # 12599, @NicolasHug, я сомневаюсь, что partial_dependence должно быть в новом модуле. (т.е. ensemble.partial_dependence + plot.plot_partial_dependence)

Я не понимаю о чем ты. # 12599 заменяет ensemble.partial_dependence на inspect.partial_dependence (конечно, inspect может быть изменен на основе этого обсуждения). API также различается между двумя реализациями.

Я в порядке с plot , меня просто беспокоит возможное перекрытие с возможным модулем проверки, но я не буду вдаваться в подробности :)

стоит рассмотреть подмодуль общедоступного сюжета в каждом подпакете.

Но пока все предлагаемые инструменты построения графиков (PDP, калибровка, матрица неточностей и область принятия решений) не относятся к одному модулю.

Я не понимаю о чем ты. # 12599 заменяет ensemble.partial_dependence на inspect.partial_dependence (конечно, inspect может быть изменен на основе этого обсуждения). API также различается между двумя реализациями.

Извините, я не смотрел подробно на этот пиар. Может быть, inspect.partial_dependence + plot.plot_partial_dependence ?

Может быть, inspect.partial_dependence + plot.plot_partial_dependence?

Мне нравится четкое разделение между вычислением значений и их построением.
Это такое разделение, как модель / представление, и оно должно помочь увеличить
возможность многократного использования.

Разве Гаэль раньше не предлагал sklearn.inspect.partial_dependence и
sklearn.inspect.plot.plot_partial_dependence (Замените другое имя
для осмотра, если необходимо)? Я не против этого.

Разве Гаэль раньше не предлагал sklearn.inspect.partial_dependence и sklearn.inspect.plot.plot_partial_dependence (при необходимости замените имя inspect на другое)?

Да, но я спросил его, куда положить plot_decision_boundary и, кажется, он передумал?

К вашему сведению, я обновил PR PDP https://github.com/scikit-learn/scikit-learn/pull/12599, следуя рекомендациям выше:

• partial_dependence находится в sklearn.model_inspection
• plot_partial_dependence находится в skearn.plot

Документы находятся здесь https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html.

Обратите внимание, что руководство пользователя пока включает только модуль plot . Я не думаю, что имеет смысл иметь раздел руководства, в котором говорилось бы только о model_inspection.partial_dependence , поскольку его ограничения / поведение такие же, как у plot_partial_dependence .

(Это то совпадение, о котором я беспокоился)

Конечно, если вы считаете, что все же лучше иметь отдельные руководства для partial_dependence и plot_partial_dependence , я сделаю это.

К вашему сведению, я обновил PDP PR № 12599, следуя приведенным выше рекомендациям:
partial_dependence находится в sklearn.model_inspection
plot_partial_dependence находится в skearn.plot

+1

Обратите внимание, что руководство пользователя пока включает только модуль построения графика. Я не думаю, что имеет смысл иметь раздел руководства пользователя, в котором говорилось бы только о model_inspection.partial_dependence, поскольку его ограничения / поведение такие же, как и у plot_partial_dependence.

+1

Итак, мы решили использовать имя sklearn.plot?

Я считаю, что sklearn.plot, импортирующий зависимости из разных sklearn, немного странно, когда мы избегаем помещать всех в корневое пространство имен.

Итак, вы бы предпочли sklearn.model_inspection.plot и поместили туда plot_partial_dependence() ?

Нет модуля plot , меня это устраивает

Думаю, я бы предпочел это. Пока не знаю, как это обобщить.

Думаю, я бы предпочел это. Пока не знаю, как это обобщить.

Пока мы можем найти подходящее место для размещения таких вещей, как plot_decision_boundary , я буду голосовать +1 за sklearn.XXX.plot .

Это нужно спать? мы, кажется, не добились большого прогресса

РЕДАКТИРОВАТЬ тьфу, сонный, я прочитал комментарий Джоэла, так как я не думаю, что предпочел бы это , извините

Это нужно спать? мы, кажется, не добились большого прогресса

Меня устраивает любое решение ( sklearn.plot / sklearn.XXX.plot ). Основная проблема здесь, ИМО, заключается в том, что никто не говорит мне, куда мы будем помещать такие вещи, как plot_decision_boundary если мы используем sklearn.XXX.plot :)

sklearn.model_inspection.plot ?

sklearn.model_inspection.plot?

Интересная идея, проголосую +1. Может быть, не так хорошо все бросать в sklearn.plot (https://github.com/rasbt/mlxtend поместил все функции построения графиков в один модуль).

Значит, мы поддержим from sklearn.XXX.plot import plot_XXX ? Поддержим ли мы from sklearn.XXX import plot_XXX ?

Я думаю, что явное требование .plot в импорте - это что-то
другие здесь искали.

Также есть инвертированный из sklearn.plot.XXX import plot_YYY

Я думаю, что явное требование .plot при импорте - это то, что здесь искали.

Итак, мы достигли консенсуса по использованию sklearn.XXX.plot (только поддержка от sklearn.XXX.plot import plot_XXX )?

Также есть инвертированный из sklearn.plot.XXX import plot_YYY

Я не понимаю.

Также есть инвертированный из sklearn.plot.XXX import plot_YYY

Я имел в виду, что мы могли бы
sklearn.plot.model_inspection.plot_partial_dependence, а не
sklearn.model_inspection.plot.plot_partial_dependence. Не уверен, что это
дает какую-либо пользу / ясность.

Я имел в виду, что мы могли бы
sklearn.plot.model_inspection.plot_partial_dependence, а не
sklearn.model_inspection.plot.plot_partial_dependence. Не уверен, что это
дает какую-либо пользу / ясность.

Итак, теперь у нас есть 3 варианта:
(1) sklearn.plot.plot_YYY (например, sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (например, sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (например, sklearn.tree.plot.plot_tree, не поддерживается из sklearn.XXX import plot_YYY)
Я проголосую +1 за все эти решения.
Я предпочитаю принимать решение до версии 0.21, чтобы избежать устаревания sklearn.tree.plot_tree

Не уверен, что ему нужен сон, но, возможно, стоит узнать мнение о
список рассылки

Не уверен, что это нужно, но, возможно, стоит запросить мнения в списке рассылки

+1. Похоже, он не подпадает под критерии СЛЭ.

Как я сказал в списке рассылки, я думаю, что нам действительно следует подумать о том, «где происходит работа» или на что будет похож интерфейс. Для частичной зависимости это уже было совершенно непонятно.
Должен ли plot_partial_dependence вызывать partial_dependence или получать вывод partial_dependence качестве ввода? Этот вопрос подходит практически для всех функций построения графиков.
Основное соображение, которое я обсуждаю с @NicolasHug, заключается в том, что наличие plot_X call compute_X удобно для пользователя - до тех пор, пока он хочет построить график только один раз. Если им не нравится сюжет и они хотят что-то изменить, им нужно снова compute_X , что потенциально является пустой тратой.

Так что мы могли либо

• всегда брать результат compute_X . обратная сторона: неудобно и подвержено ошибкам: каков был порядок точности, отзыва и пороговых значений снова в precision_recall_curve?

• всегда принимать вход в compute_X и вызывать compute_X из plot_X . обратная сторона: вам нужно пересчитывать для каждого участка.

• разрешить и то, и другое, поэтому plot_X может либо принимать входные данные в compute_X и вызывать compute_X либо принимать выходные данные compute_X если пользователь уже создал его. Обратной стороной этого является усложнение подписи (и, возможно, затруднение ее документирования). Кроме того, если пользователь вызывает plot_X чтобы он внутри выполнял compute_X а затем хочет другой сюжет, ему снова нужно compute_X . Поэтому вам нужно предвидеть, что вам нужно более одного графика, прежде чем вызывать plot_X в первый раз. Или вам нужно показать результат compute_X при вызове plot_X , но мне непонятно, как это сделать без объектно-ориентированного дизайна.

• принимайте решение в зависимости от того, насколько дорого обходится compute_X, поскольку для графиков матрицы путаницы, графиков частичных зависимостей и калибровочных графиков нас не волнует стоимость пересчета, а для графиков частичных зависимостей мы это делаем. обратная сторона: непоследовательный интерфейс.

Основное соображение, которое я обсуждаю с @NicolasHug, заключается в том, что наличие вызова plot_X compute_X удобно для пользователя - до тех пор, пока они хотят построить график только один раз. Если им не нравится сюжет и они хотят что-то изменить, им нужно снова вычислить compute_X, что потенциально является пустой тратой.

+1000. Это обычная проблема, которую я вижу в исследовательском коде.

С точки зрения дизайна, это нарушает разделение MVC (немного педантично,
извиняюсь).

Из различных предлагаемых вами решений не могли бы вы
подогнанная модель как подход? Я чувствую, что это смягчит проблему
запоминание порядка параметров. Но, возможно, есть дополнительные
проблемы.

Я не уверен, что вы имеете в виду под подогнанной моделью. Часто результат вычислений не соответствует модели. Мы могли бы определить объекты для всех результатов вычислений, так что partial_dependence возвращает объект PartialDependence . Или кучу. Но он не возвращает оценку.

О причина, по которой я поднимаю это сейчас: без этого решения я понятия не имею, как будет выглядеть пользовательский код, и мне не нравится принимать решения об именах / API, не имея возможности записывать примеры;)

возвращение объекта было бы довольно непонятным, imho. Но это может решить проблему местоположения: у него могут быть методы plot ;)

Часто результат вычислений не соответствует модели. Мы могли бы определить объекты для всех результатов вычислений, так что partial_dependence возвращает объект PartialDependence. Или кучу. Но он не возвращает оценку.

Дело принято.

Один из вариантов (не говоря уже о том, что он лучший) - это иметь все
вычислительные функции возвращают именованные кортежи и все соответствующие вычислительные
функции берут это. Это несколько соответствовало бы современным
дополнения к стандартной библиотеке Python.

и мне не нравится принимать решения об именах / API без возможности записывать примеры;)

Я, как и вы.

Поэтому, если вычисление является дорогостоящим, мы можем выполнить вычисление вне функции. Если это так, мы возвращаем объект, и функция построения графика принимает этот объект в качестве входных данных, верно? Я проголосую +1.

И, возможно, нам понадобится еще одна тема, чтобы обсудить это :)

Преимущество предложения @GaelVaroquaux заключается в том, что оно может не потребовать от пользователей изменения своего кода из-за распаковки кортежа. Но это не сработает, если будет возвращен единственный объект, как в confusion_matrix . Там кортеж не был бы строго необходим, но тогда интерфейс становится немного несовместимым.

@ qinhanmin2014, если мы возвращаем произвольные объекты, мы должны

У меня была одна идея, а затем вторая идея получше:
1) создать второй объектно-ориентированный интерфейс, который вызывает существующую функцию, сохраняет объект и имеет метод построения графика, например

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

Это решило бы проблему, но дублировало бы какой-то интерфейс, и это было бы немного непонятно. На самом деле тот же принцип может быть реализован более интуитивно понятным способом:
2) пусть функция plot_ всегда выполняет свою работу, используйте результат для создания экземпляра объекта, который хранит результат и отображает его:

plot_confusion_matrix(y, y_pred)

для этого просто построит график и вернет объект ConfusionMatrixPlotter , который хранит результат и имеет метод plot .
Итак, в простом случае всего лишь одного построения графика - это всего лишь один вызов функции. Если вы хотите, чтобы результаты выполняли с ним что-то еще, они сохраняются в объекте. Если вы хотите снова построить график, вы можете просто снова вызвать plot для объекта. Если вы уже вычислили результаты, а затем решили, что хотите построить график, вы можете напрямую создать экземпляр ConfusionMatrixPlotter .

Хотя это предоставляет дополнительный класс для более сложных случаев использования, я думаю, что это разумный компромисс, потому что он дает хороший ответ на все ситуации.

для этого просто построит график и вернет объект ConfusionMatrixPlotter, который хранит результат и имеет метод построения графика.

Почему пользователям нужно снова строить те же данные? @amueller настроить формат?

@ qinhanmin2014 да, сделайте шрифт больше, измените цвета,

@ qinhanmin2014 да, сделайте шрифт больше, измените цвета,

Сомневаюсь, стоит ли здесь рассматривать эти вопросы форматирования. Пользователи могут начать небольшую часть набора данных?

А @amueller мы будем поддерживать проходящие оси, чтобы пользователи могли легко настраивать график после вызова функций построения?

@ qinhanmin2014 нет, многие вещи не могут быть легко изменены впоследствии, и нам не обязательно думать обо всем форматировании самостоятельно, но мы должны позволить пользователям что-то строить заново. По сути, это будет происходить каждый раз, когда вы создаете сюжет. И необходимость подвыборки наборов данных каждый раз, когда я хочу построить график, немного раздражает. И если я позже передумаю, мне все равно придется пересчитывать.
По сути, дело в том, что вы обычно не можете предугадать, что именно вы хотите в своем исследовательском анализе, и необходимость пересчитывать все, чтобы изменить визуализацию, не кажется прекрасным.

@ qinhanmin2014 нет, многие вещи не могут быть легко изменены впоследствии, и нам не обязательно думать обо всем форматировании самостоятельно, но мы должны позволить пользователям что-то строить заново. По сути, это будет происходить каждый раз, когда вы создаете сюжет. И необходимость подвыборки наборов данных каждый раз, когда я хочу построить график, немного раздражает. И если я позже передумаю, мне все равно придется пересчитывать.

Да, я знаю, что это может быть полезно, но основная проблема здесь в том, что у нас нет чистого способа поддержки этой функции, и я думаю, что большинство функций построения графиков не требуют больших вычислений?

Мне нравится, что мы обсуждаем это немного более основательно, но, черт возьми, я
все еще не совсем уверен, что нам даже нужен сюжет в импорте
путь вообще. В конце концов, у нас, кажется, есть plot_ в качестве префикса для
функции. Вопрос также относится к plot_tree: почему это должно быть
отделен от другого кода экспорта и текстовой визуализации?

@ qinhanmin2014 Я не думаю, что «у нас пока нет хорошего API» - это веская причина.
Частичная зависимость, важность перестановки, кривые обучения, кривые проверки и результаты GridSearchCV и RandomizedSearchCV - все это распространенные примеры, которые требуют большого количества вычислений. Хотя для gridsearchcv и randomizedsearchcv очевидной вещью было бы передать либо объект, либо cv_results_ , выполнение работы внутри функции построения графика в этих случаях кажется бессмысленным. Я не совсем уверен в кривых обучения и кривых проверки.

@jnothman Я думаю, @GaelVaroquaux хотел, чтобы зависимость matplotlib была ограничена модулем, и это было одним из основных мотивов? У меня пока нет очень внятных мыслей по этому поводу.

Частичная зависимость, важность перестановки, кривые обучения, кривые проверки и результаты GridSearchCV и RandomizedSearchCV - все это распространенные примеры, которые требуют большого количества вычислений.

Спасибо, теперь понял, что ошибаюсь :)
Хотя я до сих пор не могу понять, почему важно предоставить пользователям возможность строить графики без пересчета. Но если так думают другие и есть хороший способ, я проголосую +1.

Мне нравится, что мы обсуждаем это немного более основательно, но, черт возьми, я
все еще не совсем уверен, что нам даже нужен сюжет в импорте
путь вообще. В конце концов, у нас, кажется, есть plot_ в качестве префикса для
функции. Вопрос также относится к plot_tree: почему это должно быть
отделен от другого кода экспорта и текстовой визуализации?

Да, это тоже может быть вариант. Если это так, мы можем упомянуть, что все функции, начинающиеся с plot_ требуют matplotlib. Еще одно преимущество этого варианта в том, что нам не нужно перемещать существующие функции.

Продолжая это обсуждение, я согласен не добавлять модуль sklearn.plot и использовать префикс plot_ для обозначения требования matplotlib .

Например, в https://github.com/scikit-learn/scikit-learn/pull/12599 partial_dependence и plot_partial_dependence будут помещены в inspection .

Хорошо, если в следующие дни кто-то не согласится с этим, я собираюсь обновить PR PDP и:

• поместите partial_dependence и plot_partial_dependence в sklearn.inspection
• make plot_partial_dependence возвращает группу с объектами fig и ax качестве атрибутов (прямо сейчас он возвращает их в виде кортежа). Таким образом, мы сможем сохранить эти две функции обратно совместимыми, когда мы реализуем второй вариант из https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520

Можем ли мы принять здесь окончательное решение?
Предложение согласовано @jnothman , @NicolasHug и мной (извиняюсь, если я ошибаюсь): sklearn.XXX.plot_YYY (поддержка sklearn.XXX import plot_YYY). Мы отметим, что для всех функций, которые начинаются с plot_, требуется matplotlib.
Основным преимуществом этого предложения является то, что нам не нужно перемещать существующие функции.

Я думаю, что это достаточно просто для объяснения, и это позволяет избежать трудностей, связанных с представлением общего api построения графиков между разными модулями.

Да, давайте сделаем это. Сделайте вспомогательную функцию, чтобы предоставить более полезную
ImportError

К вашему сведению, я добавляю sklearn.utils.check_matplotlib_support в # 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

К вашему сведению, я добавляю sklearn.utils.check_matplotlib_support в # 12599

Замечательно! Спасибо.