Scikit-learn: Предложение: удалите прогноз из plot_confusion_matrix и просто передайте прогнозируемые метки

Мы определенно должны оставаться обратно совместимыми, но добавление аргумента ключевого слова y_pred кажется мне разумным. Мы должны выдать ошибку, если y_pred передан, но X или оценка также переданы.

Вы бы хотели отправить PR @jhennrich ?

Я отправил PR, но я думаю, что в настоящее время существует проблема с CI, поэтому она еще не прошла.

Я согласен с тем, что мы должны поддерживать plot_XXX(y_true, y_pred) чтобы избежать многократного вычисления прогноза.
У нас также есть похожие проблемы в plot_roc_curve и plot_precision_recall_curve.
Добавление y_pred кажется приемлемым, но, честно говоря, я не думаю, что это хорошее решение.
Для тех функций, которые принимают ** kwargs (например, plot_precision_recall_curve), кажется, что невозможно сохранить обратную совместимость?

Почему невозможно сохранить обратную совместимость? Мне кажется, что предложение в № 15883 в порядке

Почему невозможно сохранить обратную совместимость? Мне кажется, что предложение в № 15883 в порядке

потому что мы не поддерживаем ** kwargs в plot_confusion_matrix. @NicolasHug

Почему кваргс - проблема?

Хм, есть еще одна неприятная вещь, мы поддерживаем ** kwargs в plot_roc_curve и plot_precision_recall_curve (и plot_partial_dependence), но мы не поддерживаем это в plot_confusion_matrix

Почему кваргс - проблема?

если мы добавим новый параметр перед ** kwargs, мы сможем сохранить обратную совместимость, не так ли?

Изменения в моем PR обратно совместимы, и ** kwargs все еще можно добавить. Но я согласен с @ qinhanmin2014 , гораздо более чистым решением было бы выбросить estimator и X и использовать позиционные аргументы (y_true, y_pred, ...), которые согласуются с большинством другой склеарн.

если мы добавим новый параметр перед ** kwargs, мы сможем сохранить обратную совместимость, не так ли?

да

гораздо более чистое решение ....

К сожалению, это потребует цикла устаревания (если мы не сделаем это очень быстро в выпуске исправлений, но я сомневаюсь в этом ...)

@thomasjpfan , есть ли причина передавать оценщик в качестве входных данных вместо прогнозов?

Спасибо, давайте сначала добавим y_pred, ** kwags - еще одна проблема.

К сожалению, это потребует цикла устаревания (если мы не сделаем это очень быстро в выпуске исправлений, но я сомневаюсь в этом ...)

Это кажется невозможным, вздох

@thomasjpfan , есть ли причина передавать оценщик в качестве входных данных вместо прогнозов?

Я согласен с тем, что нам необходимо пересмотреть дизайн нашего API. также попробуйте пинговать @amueller

Если пользователь хочет предоставить свою собственную графическую часть и предоставить свою собственную матрицу путаницы:

from sklearn.metrics import ConfusionMatrixDisplay
confusion_matrix = confusion_matrix(...)
display_labels = [...]

disp = ConfusionMatrixDisplay(confusion_matrix=confusion_matrix,
                              display_labels=display_labels)
disp.plot(...)

То же самое можно сделать и для других функций построения метрик.

plot_confusion_matrix спроектирован как счетчики, которые могут хорошо обрабатывать выходные данные оценщиков. Другими словами, это удобная оболочка для взаимодействия с ConfusionMatrixDisplay и оценщиком.

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

Тем не менее, я открыт для использования «быстрого пути», позволяющего передавать y_pred в функции построения графиков, связанных с метриками, которые будут переданы непосредственно в confusion_matrix и позволят ему заняться проверкой.

Расчет прогнозов, необходимых для построения PDP, довольно сложен. Кроме того, эти прогнозы обычно неприменимы, например, в счетчике или метрике. Они полезны только для построения PDP. Поэтому в этом случае имеет смысл принимать оценщик только в plot_partial_dependence.

OTOH для матрицы путаницы, прогнозы на самом деле просто est.predict(X) .

Не думаю, что нам нужен единый интерфейс. Это 2 очень разных варианта использования ввода.

РЕДАКТИРОВАТЬ: Кроме того, PDP на основе дерева вообще не нуждаются в прогнозах

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

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

Если мы примем y_pred, y_true , то теперь возникает вопрос: "Как эта метрика ведет себя с этими данными?" Эти данные могут быть созданы или не созданы моделью.

Это правда, что в этом конкретном случае @jhennrich вы могли бы напрямую использовать ConfusionMatrixDisplay.

Один из недостатков заключается в том, что вам нужно указать display_labels поскольку он не имеет значения по умолчанию.

@thomasjpfan, как вы думаете, мы могли бы в целом предоставить разумные значения по умолчанию для объектов Display, тем самым по-прежнему делая практичным прямое использование объектов Display?

Для некоторых параметров, таких как display_labels , есть разумное значение по умолчанию. Другие параметры объекта Display могут иметь разумные значения по умолчанию. Некоторые параметры должны быть указаны. Например, confusion_matrix необходимо указать для ConfusionMatrixDisplay или precision и recall для PrecisionRecallDisplay .

Один из классических паттернов для такого рода вещей - определение:

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

но это не очень идиоматично для scikit-learn.

Я начинаю путаться. Цель текущего API - избежать многократного вычисления, если пользователи хотят строить график несколько раз, но если мы принимаем y_true и y_pred, пользователям все равно не нужно вычислять многократно? (Я знаю, что в PDP все иначе)

@jnothman Этот API довольно симпатичный!

@ qinhanmin2014 Передача estimator, X, y или y_true, y_pred работает в соответствии с API "не вычислять несколько раз". В обоих случаях матрица неточностей вычисляется и сохраняется в объекте Display .

Разница между ними в том, где начинается вычисление матрицы путаницы. Можно думать о передаче y_pred как о «предварительно вычисленном» значении оценщика.

Поэтому я думаю, что y_true, y_pred лучше, чем estimator, X, y (конечно, не в PDP), потому что иногда (часто?) Пользователи хотят не только строить прогнозы, они также хотят анализировать прогнозы. С текущим API им нужно будет рассчитывать прогнозы несколько раз.

Что касается показателей, я вижу, что предпочтение отдается использованию y_true, y_pred вместо estimator, X, y . Представьте, что график для показателей поддерживает только y_true, y_pred

est = # fit estimator

plot_partial_dependence(est, X, ...)

# if plot_confusion_matrix accepts `y_true, y_pred`
y_pred = est.predict(X)
plot_confusion_matrix(y_true, y_pred, ...)

# if plot_roc_curve supports `y_true, y_score`
y_score = est.predict_proba(X)[: , 1]
plot_roc_curve(y_true, y_score, ...)
plot_precision_recall_curve(y_true, y_score, ...)

В настоящее время API выглядит так:

est = # fit estimator
plot_partial_dependence(est, X, ...)
plot_confusion_matrix(est, X, y, ...)
plot_roc_curve(est, X, y, ...)

# this will call `predict_proba` again
plot_precision_recall_curve(est, X, y, ...)

Я бы предпочел иметь API, который поддерживает оба варианта (так или иначе).

Что касается показателей, я вижу, что предпочтение отдается использованию y_true, y_pred по сравнению с оценкой, X, y. Представьте, если построение метрик поддерживает только y_true, y_pred

Да, это то, что я имел в виду.

Я бы предпочел иметь API, который поддерживает оба варианта (так или иначе).

Думаю, это практическое решение. Раздражает то, что мы можем добавить y_pred только в конце (т.е. plot_confusion_matrix (Estimator, X, y_true, ..., y_pred))

Да, это будет в конце, и API будет выглядеть так:

plot_confusion_matrix(y_true=y_true, y_pred=y_pred, ...)

что, я думаю, меня устраивает. По сути, это PR https://github.com/scikit-learn/scikit-learn/pull/15883

Да, это будет в конце, и API будет выглядеть так: plot_confusion_matrix (y_true = y_true, y_pred = y_pred, ...)

Я думаю, вы имеете в виду, что мы должны добавить y_true и удалить est & X, верно? Я думаю, это невозможно? (потому что мы можем добавить y_pred только в конце)

Хотим ли мы решить эту проблему в 0.22.1? @NicolasHug @thomasjfox Я думаю, что стоит добавить это в 0.22.1, но в то же время кажется, что это новая функция.

Нет, не добавляйте его в 0.22.1. это явное нарушение семвера

@ qinhanmin2014 Добавление y_pred в конце или удаление est, X кажется новой функцией, которая будет включена в следующий выпуск.

Я думаю, вы имеете в виду, что мы должны добавить y_true и удалить est & X, верно? Я думаю, это невозможно?

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

1. est, X проще провести быстрый анализ, потому что функция обрабатывает выбор функции ответа, срезание результата и передачу его метрике.
2. y_true, y_pred предназначен для пользователей, которые понимают, как работать с базовой метрикой и имеют уже сохраненные прогнозы.

В чем проблема с https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -565489619?

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

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

Может работать, но это в основном сделало бы plot_confusion_matrix избыточным, и поэтому мы бы снова удалили функции и изменили обязанности между классом и функцией (мы сказали, что класс не выполняет вычисления).

Если мы хотим добавить from_predictions к plot_roc_curve он должен в основном полностью отражать интерфейс roc_curve . Поэтому я не думаю, что это плохо, если пользователь вызывает функцию roc_curve напрямую, а затем передает результаты объекту Display.

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

@amueller Технически вы правы, текущее решение моей проблемы - просто использовать ConfusionMatrixDisplay . Однако использовать действительно неуклюже:

• вы должны явно передать метки
• вы должны сначала вычислить матрицу путаницы
• вам нужно создать объект класса, а затем по-прежнему вызывать метод plot

Для всех приложений, которые я могу придумать, подпись plot_confusion_matrix с (y_true, y_pred, ...) была бы намного удобнее, чем то, что мы имеем сейчас. На мой взгляд, существует гораздо больше вариантов использования, в которых вы хотите явно рассчитать прогнозы (хотя я уверен, что мое мнение необъективно).

Если у вас есть подпись plot_confusion_matrix(y_true, y_pred) и вы действительно хотите использовать ее для данных estimator , x , y , то нужно написать очень мало дополнительного кода : plot_confusion_matrix(y, estimator.predict(x)) .
Для сравнения, если у вас есть текущая подпись и вы хотите построить график из y_true и y_pred , вам придется написать намного больше кода.

На мой взгляд, подпись plot_confusion_matrix(y_true, y_pred) должна быть по умолчанию, а другая функция, которая принимает estimator , x , y должна быть построена поверх.

И последнее, но не менее важное: я, честно говоря, не совсем понимаю идею класса ConfusionMatrixDisplay . Функция имеет только один конструктор и ровно один метод, поэтому всякий раз, когда вы ее используете, вы создаете экземпляр и вызываете функцию plot . Я не понимаю, почему это должен быть класс, а не просто функция. Также существуют другие классы *Display (PrecisionRecall, ROC, ...), но их сигнатуры конструктора и plot() совершенно разные, поэтому их все равно нельзя заменить.
Возможно, это выходит за рамки данной проблемы.

@jhennrich

Если у вас есть подпись plot_confusion_matrix (y_true, y_pred) и вы действительно хотите использовать ее для оценки, данных x, y, нужно написать очень мало дополнительного кода: plot_confusion_matrix (y, Estimator.predict (x)).

Для случая матрицы путаницы просто передать estimator.predict если бы у нас был интерфейс y_true, y_pred . С другой стороны, для plot_roc_auc пользователю потребуется выполнить нарезку:

y_pred = est.predict_proba(X)
plot_roc_curve(y_true, y_pred[:, 1])

# or
y_pred = est.decision_function(X)
plot_roc_curve(y_true, y_pred[:, 1])

И последнее, но не менее важное: я, честно говоря, не совсем понимаю идею класса ConfusionMatrixDisplay. Функция имеет только один конструктор и ровно один метод, поэтому всякий раз, когда вы ее используете, вы создаете экземпляр и вызываете функцию построения графика. Я не понимаю, почему это должен быть класс, а не просто функция.

Цель объектов Display - хранить вычисленные значения, позволяя пользователям многократно вызывать plot без повторных вычислений. Это можно увидеть, используя plot_partial_dependence :

# Does expensive computation
disp = plot_partial_dependence(est, ...)

# change line color without needing to recompute partial dependence
disp.plot(line_kw={"c": "red"})

Честно говоря, я настороженно отношусь к этому вопросу. Я +0,1 к переходу к копированию интерфейса метрик для построения метрик и удаления интерфейса est, X, y . : /

Для случая с матрицей неточностей просто передать Estimator.predict, если бы у нас был интерфейс y_true, y_pred. С другой стороны, для plot_roc_auc пользователю нужно будет выполнить нарезку:

Да, но тем самым мы избегаем многократного вычисления прогноза (хотя прогнозирование часто обходится не так дорого).

Возможно, практическое решение - поддержка y_true, y_pred в plot_XXX (если применимо) в 0.23.

@jhennrich Как вы собираетесь это сделать, не передавая ярлыки явно? Если метки могут быть выведены из того, что дано, confusion_matrix сделает это за вас.

Но вы действительно правы, это три строчки вместо одной.

В случае confusion_matrix я склонен согласиться с тем, что более распространенным случаем может быть передача y_true и y_pred .
Причина, по которой интерфейс в настоящее время таков, состоит в том, чтобы соответствовать другим функциям построения метрик. Как сказал @thomasjpfan , кривая

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

Вопрос в том, лучше ли в этом случае иметь последовательные интерфейсы или иметь простой интерфейс.
@jhennrich Для меня реальный вопрос заключается в том, какой интерфейс подходит для plot_roc_curve . У вас есть мысли по этому поводу?

@thomasjpfan , ты y_store за построение roc auc?

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

@ qinhanmin2014
Думаю, было бы неплохо добавить y_pred к plot_confusion_matrix . Вопрос в том, хотим ли мы добавить y_score к plot_roc_curve и plot_precision_recall_curve . Если мы это сделаем, мы также должны добавить pos_label как я сказал выше, и все станет более сложным.

Я вижу три выхода из этого:
a) Добавляйте только y_pred к plot_confusion_matrix , но не добавляйте y_score к plot_roc_curve и т. д. Обратная сторона: проблема вызова predict_proba несколько раз продолжает существовать для этих показателей.
б) Упростите использование объекта Display напрямую (хотя я действительно не знаю как).
c) Добавьте другой метод или функцию, которая отражает метрический интерфейс. Оборотная сторона: большая поверхность API.

Я не думаю, что наличие функции plot_X одновременно отражающей интерфейс счетчика и метрики, в целом является хорошей идеей.

Я думаю, было бы здорово решить эту проблему каким-то образом @adrinjalali, может быть, вы хотите обсудить это на следующей встрече?

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

result = confusion_matrix(...)
ConfusionMatrixDisplay.from_metric(result).plot()

Для кривой roc:

result = roc_curve(...)
RocCurveDisplay.from_metric(*result).plot()

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

Иногда мне снятся кошмары по этому поводу.

О нет :(

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

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

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

Привет, я только что проголосовал за проблему - как давний пользователь sklearn, я обнаружил, что текущий API для plot_confusion_matrix очень ... ну, сбивает с толку. Мне очень нравится его добавление (меньше копирования и вставки), но функции метрик всегда использовали схему (y_true, y_pred), которая просто более гибкая и к которой я уже привык.

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

В моем случае нет смысла передавать оценщик, так как это очень медленная модель, и я бы предпочел загрузить прогнозы.

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

Самая большая проблема, которую мы испытываем при использовании интерфейса метрик, заключается в следующем:

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

@pzelasko Что вы думаете по этому поводу?

@thomasjpfan Я понимаю проблему, это сложный вопрос. Может быть, разумным компромиссом было бы разрешить только ключевые аргументы для этой функции (теперь, когда вам больше не нужно поддерживать Python 2)? Нравится: def plot_confusion_matrix(*, y_true, y_pred, ...) . Он по-прежнему отличается от остальных показателей, но 1) у него есть веская причина для этого, 2) он, по крайней мере, использует тот же тип входных данных, что и другие функции.

В любом случае, я знаю, почему вы не решаетесь вносить какие-либо изменения в API, поэтому я предложил хотя бы упомянуть обходной путь в документации. (На самом деле я их много раз читал и очень ценю!)

Текущий способ использования y_true и y_pred показан здесь: https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_display_object_visualization.html#create -confusionmatrixdisplay

Я знаю, что растягиваюсь здесь, но как насчет этого:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ...)

где вторая позиция принимает y_true качестве прогнозов, если estimator='precomputed .

если вы хотите растянуть еще больше, я бы предпочел plot_confusion_matrix((estimator, X, y), ...) или plot_confusion_matrix((y_true, y_pred), ...) но я не уверен, что это решает проблемы, поднятые @amueller относительно метрического API

Есть несколько новых утилит для построения графиков, для которых действительно имеет смысл разрешить metric API:

• plot_prediction_error в https://github.com/scikit-learn/scikit-learn/pull/18020
• plot_calibration_curve в https://github.com/scikit-learn/scikit-learn/pull/17443 (CC @lucyleeow )

Я понимаю проблему, которую @amueller упомянул о необходимости передать pos_label и т. Д., Но это не проблема ни для одной из вышеупомянутых функций.

Готовы ли мы поддерживать для этих двоих API и функцию скоринга, и API метрик? Здесь нам не нужно беспокоиться об обратной совместимости.

Я по-прежнему за свое предложение использовать precomputed , который мы обычно используем в наших оценках. В этом случае подпись будет:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ..., metric_kwargs=None)

Я соберу PR, чтобы посмотреть, как это выглядит.

Я пока не совсем обсуждаю API, я только спрашиваю, согласны ли мы поддерживать оба варианта для новых PR.

(Но что касается API, я не думаю, что `` предварительное вычисление '' сильно помогает: что нам делать с X ? Я думаю, мы должны просто сохранить (y_pred) и (оценка, X) взаимоисключающими, правильно допустив ошибки . И что означает предварительное вычисление оценщика?)

Или estimator='none' , estimator='predictions' , estimator='precomputed_predictions' , а затем X становится y_pred или y_score . Это почти похоже на то, как мы обрабатываем предварительно вычисленные расстояния с помощью X в оценщиках.

Готовы ли мы поддерживать для этих двоих API и функцию скоринга, и API метрик?

Как мы будем поддерживать оба варианта? С двумя функциями?

Еще бы понравилось:

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

это будет два метода.

Предложение Гийома об использовании кортежей https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -670590882 является одним из вариантов. Я думаю, что это был бы лучший вариант, если бы мы начали с этого с самого начала. Но я боюсь, что использование кортежей нарушит согласованность с существующими утилитами.

plot_XYZ(estimator=None, X=None, y=None, y_pred=None) с взаимным исключением - еще один вариант, и на данный момент я выступаю за него.

Мне нравится CalibrationDisplay.from_estimator(...) , но, как заметил Энди, тогда нам нужно удалить функции plot_XYZ . Возможно, стоит подумать.

Я думаю, мы можем перейти к кортежам и отказаться от текущего поведения. (Пока мы соглашаемся использовать кортежи)

Это похоже на обсуждение пространств имен, не так ли?
Независимо от того, есть ли у нас одна функция и один конструктор, два метода классов или две функции, это точно такая же функциональность и в основном один и тот же код.

@pzelasko @jhennrich как вы относитесь к двум методам классов или двум функциям? Или вы бы предпочли одну функцию, что в python немного беспорядочно.

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

Можно ли добавить сюда ярлык блокировщика? Похоже, это мешает прогрессу на # 18020 и # 17443 (cc @cmarmo)

Этикетка-блокировщик предназначена для блокировщиков релиза (вещи, которые абсолютно необходимо исправить перед релизом), а не для блокировщиков PR.

Ах, хорошо знать.

@pzelasko @jhennrich как вы относитесь к двум методам классов или двум функциям? Или вы бы предпочли одну функцию, что в python немного беспорядочно.

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

Мне больше всего нравится подход с двумя классами, особенно шаблон from_xxx - что-то вроде предложенного @thomasjpfan :

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

Похоже, что нет сильных возражений против использования двух методов класса, так что давайте сделаем это. Нам потребуется:

• Представьте методы класса для существующих в настоящее время графиков:

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay . Для этого мы не хотим вводить метод from_predictions class, потому что он не имеет смысла, нам нужен только from_estimator .

• Для всех перечисленных выше Display отказаться от соответствующей функции plot_... . Нам не нужно исключать plot_det_curve потому что он еще не выпущен, мы можем просто удалить его.

• для новых PR, таких как # 17443 и # 18020, мы можем реализовать методы класса сразу, вместо того, чтобы вводить функцию plot .

Это небольшая работа, но я думаю, что мы сможем сделать это до версии 0.24, так что # 17443 и # 18020 уже могут двигаться вперед.

Есть возражения @thomasjpfan @jnothman @amueller @glemaitre ?

@jhennrich @pzelasko , не могли бы вы подать PR, чтобы представить методы класса в одном из объектов Display?

Спасибо, что приняли решение, @NicolasHug! Я перейду на # 17443 (дождавшись возражений)

У меня нет возражений.

И возражений нет.

Тогда я позабочусь о других занятиях и продвину свой застопорившийся пиар.
@lucyleeow на случай, если я не все это сделал, а вы ищете

Я бы хотел внести свой вклад, но в настоящее время я участвую в слишком большом количестве проектов. Спасибо, что выслушали предложения!

Звучит отлично :)