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の提案は大丈夫だと思います

plot_confusion_matrixで** kwargsをサポートしていないためです。 @NicolasHug

kwargsが問題になるのはなぜですか？

うーん、もう1つ厄介なことがあります。私たちは、plot_roc_curveとplot_precision_recall_curve（およびplot_partial_dependence）で** kwargsをサポートしていますが、plot_confusion_matrixではサポートしていません。

kwargsが問題になるのはなぜですか？

** kwargsの前に新しいパラメータを追加すると、下位互換性を維持できますよね？

私のPRの変更には下位互換性があり、** kwargsは引き続き追加できます。 しかし、私は@ qinhanmin2014に同意します。はるかにクリーンな解決策は、 estimatorとXを破棄し、ほとんどの他のsklearnのもの。

** kwargsの前に新しいパラメータを追加すると、下位互換性を維持できますよね？

はい

はるかにクリーンなソリューション....

残念ながら、これには非推奨サイクルが必要になります（バグ修正リリースで非常に高速にした場合を除きますが、疑わしいです...）

@thomasjpfan 、予測の代わりに推定量を入力として渡す理由はありますか？

おかげで、最初にy_predを追加しましょう。** kwagsは別の問題です。

残念ながら、これには非推奨サイクルが必要になります（バグ修正リリースで非常に高速にした場合を除きますが、疑わしいです...）

これは不可能のようです、ため息

@thomasjpfan 、予測の代わりに推定量を入力として渡す理由はありますか？

API設計を再検討する必要があることに同意します。 また、 @ amuellerにpingをください

ユーザーが独自のプロット部分を提供し、独自の混同行列を提供したい場合：

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を直接使用している可能性があるのは

1つの欠点は、デフォルトがないため、 display_labelsを指定する必要があることです。

@thomasjpfan一般に、Displayオブジェクトに

display_labelsなどの一部のパラメータには、適切なデフォルトがあります。 他のDisplayオブジェクトパラメータにも適切なデフォルトを設定できます。 一部のパラメーターを指定する必要があります。 たとえば、 confusion_matrixはConfusionMatrixDisplayまたはprecision 、 recallはPrecisionRecallDisplay提供される必要があります。

この種のものの1つの古典的なパターンは、次のように定義しています。

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を使用する方が好まれていることがわかります。 メトリックのプロットが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が欲しいです。

メトリックについては、推定量X、yよりもy_true、y_predを使用する方が優先されていることがわかります。 メトリックのプロットが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には入れないでください。 それは明らかにsemverの違反です

@ 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が必要で、もう一方は必要ありません） 'NS）。
したがって、同じインターフェースで両方を許可することは悪い考えだと思います（誰かが推定器を渡すときに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クラスの背後にある考え方を本当に理解していません。 この関数にはコンストラクターが1つとメソッドが1つしかないため、この関数を使用するたびに、インスタンスを作成してplot関数を呼び出すことになります。 これが単なる関数ではなくクラスである理由がわかりません。 また、他の*Displayクラス（PrecisionRecall、ROCなど）もありますが、それらのコンストラクター署名とplot()署名は完全に異なるため、とにかく交換することはできません。
多分これはこの問題の範囲を超えています。

@jhennrich

plot_confusion_matrix（y_true、y_pred）署名があり、それをestimator、x、yデータで実際に使用したい場合、記述する追加のコードはごくわずかです：plot_confusion_matrix（y、estimator.predict（x））。

混同行列の場合、 y_true, y_predインターフェイスがあれば、 estimator.predictを渡すのは簡単です。 一方、 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クラスの背後にある考え方を正直に理解していません。 この関数にはコンストラクターが1つとメソッドが1つしかないため、この関数を使用するたびに、インスタンスを作成してプロット関数を呼び出すことになります。 これが単なる関数ではなくクラスである理由がわかりません。

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"})

正直なところ、私はこの問題について危機に瀕しています。 est, X, yインターフェイスをプロットして削除するために、メトリックインターフェイスをコピーする方向に進んでいます。 ：/

混同行列の場合、y_true、y_predインターフェースがあれば、estimator.predictを渡すのは簡単です。 一方、plot_roc_aucの場合、ユーザーはスライスを行う必要があります。

はい。ただし、そうすることで、複数回の予測の計算を回避できます（ただし、予測はそれほど費用がかからないことがよくあります）。

おそらく実用的な解決策は、0.23のplot_XXX（該当する場合）でy_true, y_predをサポートすることです。

@jhennrichラベルを明示的に渡さずにこれをどのように行うのですか？ 与えられたものからラベルを推測できる場合は、 confusion_matrixがそれを行います。

しかし、確かにあなたは正しいです、それは1つではなく3つの行です。

confusion_matrixの場合、より一般的なケースがy_trueとy_predを渡す可能性があることに同意する傾向があります。
インターフェイスが現在の方法である理由は、他のメトリックプロット関数と一貫性を保つためです。 @thomasjpfanが言ったように、roc曲線をプロットするのはあまり明白ではありません。

現在、混同行列をプロットするためのコードとroc曲線をプロットするためのコードは同じです。 提案された変更により、それらはもはや同じではなくなり、同じにする簡単な方法はありません。

問題は、この場合、一貫性のあるインターフェースを使用する方がよいのか、それとも単純なインターフェースを使用する方がよいのかということです。
@jhennrich私にとって本当の問題は、 plot_roc_curveの適切なインターフェイスが何であるかということです。 あなたはそれについて考えがありますか？

@thomasjpfan roc aucのプロットにもy_storeを使う傾向がありますか？

メトリックインターフェイスを使用する代わりにスコアラーインターフェイスを使用することには、確かに長所と短所があります。 ただし、より複雑な場合は、スコアラーインターフェイスを使用する方がはるかに安全です。

@ qinhanmin2014
y_predをplot_confusion_matrixに追加しても問題ないと思います。 問題は、 y_scoreをplot_roc_curveとplot_precision_recall_curveに追加するかどうかです。 そうすると、上で述べたようにpos_labelも追加する必要があり、事態はさらに複雑になります。

私はこれから3つの方法を見ます：
a） y_predをplot_confusion_matrixに追加するだけで、 y_scoreをplot_roc_curveなどに追加しないでください。欠点： predict_proba呼び出しの問題これらのメトリックには複数回存在し続けます。
b） Displayオブジェクトを直接使用しやすくします（方法はわかりませんが）。
c）メトリックインターフェイスをミラーリングする別のメソッドまたは関数を追加します。 欠点：APIサーフェスが大きくなります。

一般に、 plot_X関数でスコアラーとメトリックインターフェイスの両方を同時にミラーリングすることは良い考えではないと思います。

なんらかの方法でこれを解決できれば素晴らしいと思います@adrinjalali次の会議で話し合いたいですか？

私は時々この問題について悪夢を見ます。 メトリックの出力を直接受け取る静的メソッドを追加できるかもしれません。

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

roc曲線の場合：

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

ちなみに、コードベースを見ると、スコアインターフェイスよりもメトリックインターフェイスに精通しているユーザーが多いと思います。

私は時々この問題について悪夢を見ます。

大野 ：（

ちなみに、コードベースを見ると、スコアインターフェイスよりもメトリックインターフェイスに精通しているユーザーが多いと思います。

これは間違いなく本当だと思います。 しかし、 y_scoreを使用する必要があるときにy_predを使用し、インターフェイスが別のことを行う必要があることを通知しないため、間違った結果が得られることも確かです。ドキュメントを読む人もいます。

提案する静的メソッドがコンストラクターとどのように異なるかはわかりませんが、何かを見落としている可能性があります。

こんにちは、私はこの問題に賛成票を投じました-長年のsklearnユーザーとして、私はplot_confusion_matrixの現在のAPIを非常に...まあ、混乱させていることに気づきました。 私はその追加（コピー貼り付けが少ない）が本当に好きですが、メトリック関数は常に（y_true、y_pred）スキームを使用していました。これは、より柔軟で、私がすでに慣れているものです。

私の場合、推定器を渡すことは意味がありません。これは非常に遅いモデルであり、結果を分析するたびに再実行するのではなく、ファイルから予測をロードしたいからです。 このスレッドで* Displayオブジェクトを使用した回避策があることを知ってうれしいですが、その発見可能性はあまり良くありません-少なくともそれをplot_confusion_matrixドキュメントまたは混同行列ユーザーガイドに追加することをお勧めします？

私の場合、推定量を渡すことは意味がありません。これは非常に遅いモデルであり、予測をロードしたいからです。

ご意見ありがとうございます。 現在のAPIが混乱している場合は、より多くのメトリックに移行する方が理にかなっています。APIのようなインターフェイスを使用して、痛みを伴う非推奨サイクルを実行します。

メトリックインターフェイスの使用に関する最大の懸念事項は次のとおりです。

しかし、y_scoreを使用する必要があるときにy_predを使用し、インターフェイスが別のことを行う必要があることを通知せず、誰もドキュメントを読まないため、間違った結果が得られることも確かです。

@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), ...)をお勧めしますが、メトリックのようなAPIに関してわかりません。

metric APIを許可することが本当に理にかなっているいくつかの新しいプロットユーティリティがあります。

• https://github.com/scikit-learn/scikit-learn/pull/18020のplot_prediction_error
• https://github.com/scikit-learn/scikit-learn/pull/17443（CC @lucyleeow ）のplot_calibration_curve

@amuellerがpos_labelなどを渡す必要があると述べた問題を理解していますが、これは前述の関数のいずれについても問題ではありません。

これら2つのスコアラーAPIとメトリクスAPIの両方をサポートしても大丈夫ですか？ そこでは下位互換性について心配する必要はありません。

私はまだprecomputedを使用することを提案しています。これは、推定器で一般的に使用されています。 この場合、署名は次のようになります。

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

これがどのように見えるかを確認するためにPRをまとめます。

APIについてはまだ実際には説明していませんが、新しいPRの両方のオプションをサポートしてもよいかどうかだけを尋ねています。

（しかし、APIに関しては、「事前計算」はあまり役に立たないと思います： Xについてどうすればよいですか？適切にエラーを発生させることにより、（y_pred）と（estimator、X）を相互に排他的に保つ必要があると思います。また、推定量が事前に計算されるとはどういう意味ですか？）

または、 estimator='none' 、 estimator='predictions' 、 estimator='precomputed_predictions'場合、 Xはy_predまたはy_scoreます。 これX 、推定量で

これら2つのスコアラーAPIとメトリクスAPIの両方をサポートしても大丈夫ですか？

両方のオプションをどのようにサポートしますか？ 2つの機能で？

私も好きだっただろう：

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

これは2つの方法になります。

タプルの使用に関するギヨームの提案https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment-670590882は1つのオプションです。 最初からそこから始めていたら、それが最善の選択肢だったと思います。 しかし、タプルを使用すると、既存のユーティリティとの一貫性が失われるのではないかと心配しています。

相互排除を伴うplot_XYZ(estimator=None, X=None, y=None, y_pred=None)は別のオプションであり、今のところ、これが私が提唱しているオプションです。

私はCalibrationDisplay.from_estimator(...)が好きですが、Andyが指摘したように、 plot_XYZ関数を削除する必要があります。 検討する価値があるかもしれません。

タプルに移動して、現在の動作を非推奨にすることができると思います。 （タプルの使用に同意する限り）

それで、これは名前空間について議論しているようですよね？
1つの関数と1つのコンストラクター、2つのクラスメソッド、または2つの関数のいずれであっても、まったく同じ機能であり、基本的に同じコードです。

@pzelasko @jhennrich 2つのクラスメソッドまたは2つの関数があることについてどう思いますか？ または、Pythonでは少し面倒な単一の関数をお勧めします。

また、2つの関数または2つのクラスメソッドを好む場合、発見可能であるにもかかわらず、何か利点がありますか？ 発見可能性はクラスメソッドを実行する十分な理由かもしれませんが、2つの関数を持つことについての強い議論は見当たりません。

ここにブロッカーラベルを追加できますか？ ＃18020と＃17443（cc @cmarmo）の進行を妨げているようです

ブロッカーラベルはリリースブロッカー（リリース前に絶対に修正する必要があるもの）用であり、PRブロッカー用ではありません

ああ、知ってよかった。

@pzelasko @jhennrich 2つのクラスメソッドまたは2つの関数があることについてどう思いますか？ または、Pythonでは少し面倒な単一の関数をお勧めします。

また、2つの関数または2つのクラスメソッドを好む場合、発見可能であるにもかかわらず、何か利点がありますか？ 発見可能性はクラスメソッドを実行する十分な理由かもしれませんが、2つの関数を持つことについての強い議論は見当たりません。

私は2つのクラスメソッドが最もアプローチするのが好きです。特にfrom_xxxパターンが好きです- sth ：

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

2つのクラスメソッドを使用することに強い反対はないように見えるので、それを実行しましょう。 次のことを行う必要があります。

• 現在存在するプロットのクラスメソッドを導入します。

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay 。 これについては、 from_predictionsクラスメソッドを導入する必要はありません。意味がないため、 from_estimatorのみが必要です。

• 上記のすべてのディスプレイで、対応するplot_...関数を非推奨にします。 plot_det_curveはまだリリースされていないため、非推奨にする必要はありません。削除するだけです。

• ＃17443や＃18020などの新しいPRの場合、 plot関数を導入する代わりに、クラスメソッドをすぐに実装できます。

これは少し手間がかかりますが、0.24より前にこれを実行できるので、＃17443と＃18020はすでに前進できると思います。

異議はありますか@ thomasjpfan @ jnothman @amueller @glemaitre ？

@jhennrich @ pzelasko 、Displayオブジェクトの1つにクラスメソッドを導入するためのPRを送信することに興味がありますか？

決定してくれてありがとう@NicolasHug！ ＃17443に乗ります（反対意見を待った後）

異議はありません。

異議もありません。

その後、他のクラスの面倒を見て、行き詰まったPRを進めます。
@lucyleeow私がそれらすべてを実行しなかった場合、あなたはいくつかのPRを検索していて、私にpingを

貢献したいのですが、今はあまりにも多くのプロジェクトに携わっています。 提案を聞いてくれてありがとう！

いいですね ：）