Scikit-learn: Saran: Hapus prediksi dari plot_confusion_matrix dan cukup berikan label prediksi

Kita harus tetap kompatibel ke belakang, tetapi menambahkan arg kata kunci y_pred terdengar masuk akal bagi saya. Kita harus memunculkan kesalahan jika y_pred dilewatkan tetapi X atau estimator juga dilewati.

Apakah Anda ingin mengirimkan PR @jhennrich ?

Saya mengajukan PR, tetapi saya pikir saat ini ada masalah dengan CI sehingga belum lulus.

Saya setuju bahwa kita harus mendukung plot_XXX(y_true, y_pred) untuk menghindari penghitungan prediksi berkali-kali.
Kami juga memiliki masalah serupa di plot_roc_curve dan plot_precision_recall_curve.
Menambahkan y_pred tampaknya dapat diterima, tetapi sejujurnya saya pikir itu bukan solusi yang baik.
Untuk fungsi-fungsi yang menerima **kwargs (misalnya, plot_precision_recall_curve), tampaknya tidak mungkin untuk tetap kompatibel ke belakang?

Mengapa tidak mungkin untuk menjaga kompatibilitas ke belakang? Sepertinya proposal di #15883 tidak masalah

Mengapa tidak mungkin untuk menjaga kompatibilitas ke belakang? Sepertinya proposal di #15883 tidak masalah

karena kami tidak mendukung **kwargs di plot_confusion_matrix. @NicolasHug

Mengapa kwargs menjadi masalah?

Hmm, jadi ada hal lain yang mengganggu, kami mendukung **kwargs di plot_roc_curve dan plot_precision_recall_curve (dan plot_partial_dependence), tetapi kami tidak mendukungnya di plot_confusion_matrix

Mengapa kwargs menjadi masalah?

jika kita menambahkan parameter baru sebelum **kwargs, kita dapat menjaga kompatibilitas ke belakang, bukan?

Perubahan dalam PR saya kompatibel ke belakang dan **kwargs masih dapat ditambahkan. Tapi saya setuju dengan @qinhanmin2014 , solusi yang jauh lebih bersih adalah membuang estimator dan X dan menggunakan argumen posisi (y_true, y_pred, ...) hal-hal sklearn lainnya.

jika kita menambahkan parameter baru sebelum **kwargs, kita dapat menjaga kompatibilitas ke belakang, bukan?

Ya

solusi yang jauh lebih bersih....

Sayangnya itu akan membutuhkan siklus penghentian (kecuali kami membuatnya sangat cepat dalam rilis perbaikan bug tapi saya ragu ...)

@thomasjpfan , ada alasan untuk melewatkan estimator sebagai input alih-alih prediksi?

Terima kasih, mari tambahkan y_pred dulu, **kwags adalah masalah lain.

Sayangnya itu akan membutuhkan siklus penghentian (kecuali kami membuatnya sangat cepat dalam rilis perbaikan bug tapi saya ragu ...)

Ini sepertinya tidak mungkin, desah

@thomasjpfan , ada alasan untuk melewatkan estimator sebagai input alih-alih prediksi?

Saya setuju bahwa kita perlu mempertimbangkan kembali desain API kita. coba juga ping ke @amueller

Jika pengguna ingin memberikan bagian plot mereka sendiri dan memberikan matriks kebingungan mereka sendiri:

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

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

Hal serupa dapat dilakukan untuk fungsi plotting metrik lainnya.

plot_confusion_matrix dirancang seperti pencetak angka yang mampu menangani keluaran estimator dengan baik. Dengan kata lain, ini adalah pembungkus praktis untuk berinteraksi dengan ConfusionMatrixDisplay dan estimator.

Dengan menerima estimator terlebih dahulu, ada antarmuka yang seragam untuk fungsi plot. Misalnya, plot_partial_dependence melakukan semua perhitungan yang diperlukan untuk membuat plot ketergantungan parsial dan meneruskannya ke PartialDependenceDisplay . Seorang pengguna masih dapat membuat PartialDependenceDisplay sendiri, tetapi dalam hal ini akan lebih terlibat.

Meskipun, saya terbuka untuk memiliki "jalur cepat", memungkinkan y_pred untuk diteruskan ke metrik terkait fungsi plot, yang akan diteruskan langsung ke confusion_matrix dan membiarkannya menangani validasi.

Perhitungan prediksi yang dibutuhkan untuk membangun PDP cukup kompleks. Juga, prediksi ini biasanya tidak dapat digunakan, misalnya pencetak gol atau metrik. Mereka hanya berguna untuk merencanakan PDP. Jadi masuk akal dalam hal ini untuk hanya menerima estimator di plot_partial_dependence.

OTOH untuk matriks kebingungan, prediksinya benar-benar hanya est.predict(X) .

Saya tidak berpikir kita ingin antarmuka yang seragam di sini. Ini adalah 2 kasus penggunaan input yang sangat berbeda

EDIT: Selain itu, PDP berbasis pohon bahkan tidak memerlukan prediksi sama sekali

Ada hal lain yang akan kita hadapi tanpa estimator. Misalnya jika plot_precision_recall_curve akan menerima y_pred , itu akan membutuhkan pos_label karena tidak dapat disimpulkan lagi. Dalam hal ini, saya lebih suka menggunakan PrecisionRecallDisplay secara langsung dan meminta pengguna menghitung parameter yang diperlukan untuk merekonstruksi plot.

Ini bermuara pada pertanyaan seperti apa yang kami jawab dengan API ini. Antarmuka saat ini berkisar mengevaluasi estimator, sehingga menggunakan estimator sebagai argumen. Itu dimotivasi dengan menjawab "bagaimana model terlatih ini berperilaku dengan data input ini?"

Jika kita menerima y_pred, y_true , sekarang pertanyaannya menjadi "bagaimana perilaku metrik ini dengan data ini?" Data ini mungkin atau mungkin tidak dihasilkan oleh model.

Memang benar bahwa dalam kasus khusus ini, @jhennrich Anda bisa langsung menggunakan ConfusionMatrixDisplay.

Salah satu kelemahannya adalah Anda perlu menentukan display_labels karena tidak memiliki default.

@thomasjpfan apakah menurut Anda kami secara umum dapat memberikan default yang masuk akal untuk objek Display, sehingga masih membuat penggunaan langsung objek Display menjadi praktis?

Untuk beberapa parameter, seperti display_labels , ada default yang masuk akal. Parameter objek Display lainnya dapat memiliki default yang masuk akal juga. Beberapa parameter harus disediakan. Misalnya, confusion_matrix harus disediakan untuk ConfusionMatrixDisplay atau precision dan recall untuk PrecisionRecallDisplay .

Salah satu pola klasik untuk hal semacam ini adalah mendefinisikan:

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

tapi ini tidak terlalu idiomatis untuk scikit-belajar.

Saya mulai bingung. Tujuan dari API saat ini adalah untuk menghindari penghitungan beberapa kali jika pengguna ingin membuat plot beberapa kali, tetapi jika kami menerima y_true dan y_pred, pengguna masih tidak perlu menghitung beberapa kali? (Saya tahu bahwa hal-hal berbeda di PDP)

@jnothman API itu terlihat cukup bagus!

@qinhanmin2014 Melewati estimator, X, y atau y_true, y_pred berfungsi dalam memenuhi API "jangan hitung berkali-kali". Dalam kedua kasus, matriks konfusi dihitung dan disimpan ke dalam objek Display .

Perbedaan di antara mereka adalah di mana perhitungan matriks kebingungan dimulai. Seseorang dapat menganggap pass y_pred sebagai nilai "precomputed" dari estimator.

Jadi menurut saya y_true, y_pred lebih baik daripada estimator, X, y (tentu saja tidak dalam PDP), karena terkadang (sering?) pengguna tidak hanya ingin membuat plot prediksi, mereka juga ingin menganalisis prediksi. Dengan API saat ini, mereka harus menghitung prediksi beberapa kali.

Untuk metrik, saya dapat melihat preferensi untuk menggunakan y_true, y_pred daripada estimator, X, y . Bayangkan jika plot untuk metrik hanya mendukung 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, ...)

Saat ini API terlihat seperti:

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, ...)

Saya lebih suka memiliki API yang mendukung kedua opsi (entah bagaimana).

Untuk metrik, saya dapat melihat preferensi untuk menggunakan y_true, y_pred daripada estimator, X, y. Bayangkan jika plot untuk metrik hanya mendukung y_true, y_pred

Ya, ini yang saya maksud.

Saya lebih suka memiliki API yang mendukung kedua opsi (entah bagaimana).

Saya pikir ini adalah solusi praktis. Hal yang mengganggu adalah bahwa kita hanya dapat menambahkan y_pred di akhir (yaitu, plot_confusion_matrix(estimator, X, y_true, ..., y_pred))

Yup itu akan berada di akhir dan API akan terlihat seperti ini:

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

yang menurut saya baik-baik saja. Ini pada dasarnya adalah PR https://github.com/scikit-learn/scikit-learn/pull/15883

Yup itu akan berada di akhir dan API akan terlihat seperti ini plot_confusion_matrix(y_true=y_true, y_pred=y_pred, ...)

Saya kira maksud Anda kita harus menambahkan y_true dan menghapus est & X, bukan? Saya kira itu tidak mungkin? (karena kami hanya dapat menambahkan y_pred di akhir)

Apakah kita ingin menyelesaikan ini di 0.22.1? @NicolasHug @thomasjfox Saya pikir ini bermanfaat untuk menempatkan ini di 0.22.1, tetapi pada saat yang sama, tampaknya ini adalah fitur baru.

Tidak, jangan masukkan ke 0.22.1. itu jelas melanggar semver

@qinhanmin2014 Menambahkan y_pred di akhir atau menghapus est, X sepertinya merupakan fitur baru yang termasuk dalam rilis berikutnya.

Saya kira maksud Anda kita harus menambahkan y_true dan menghapus est & X, bukan? Saya kira itu tidak mungkin?

Pada akhirnya saya lebih suka mendukung memiliki kedua antarmuka, karena mereka memiliki kasus penggunaan yang sedikit berbeda.

1. est, X lebih mudah untuk melakukan analisis cepat, karena fungsi menangani pemilihan fungsi respons, memotong hasilnya dan meneruskannya ke metrik.
2. y_true, y_pred adalah untuk pengguna yang memahami cara bekerja dengan metrik yang mendasarinya dan memiliki prediksi yang sudah disimpan.

Apa masalahnya dengan melakukan https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -565489619 ?

Saya belum membaca seluruh utas ini tetapi jika kami mengizinkan antarmuka di sini, kami juga perlu melakukannya untuk plot_roc_curve mana antarmuka akan sangat berbeda antara memberikan prediksi dan menyediakan penaksir (satu membutuhkan pos_label yang lain tidak 'T).
Jadi saya pikir mengizinkan keduanya dalam antarmuka yang sama adalah ide yang buruk (seseorang akan melewati pos_label ketika melewati penaksir dan mendapatkan hasil yang tidak mereka harapkan).

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

Bisa bekerja, tetapi pada dasarnya akan membuat plot_confusion_matrix berlebihan, jadi kami akan menghapus fungsi lagi dan mengubah tanggung jawab antara kelas dan fungsi (kami mengatakan kelas tidak melakukan penghitungan).

Jika kita ingin menambahkan from_predictions ke plot_roc_curve pada dasarnya perlu mencerminkan antarmuka roc_curve sempurna. Jadi saya tidak berpikir terlalu buruk untuk meminta pengguna memanggil fungsi roc_curve secara langsung dan kemudian meneruskan hasilnya ke objek Display.

Seluruh tujuan dari desain objek tampilan adalah untuk memungkinkan usecase yang disebutkan oleh @jhennrich dan mengapa kami memisahkan perhitungan dari fungsi. Saya belum melihat argumen mengapa kita harus mundur pada keputusan itu.

@amueller Secara teknis Anda benar, solusi saat ini untuk Masalah saya adalah dengan hanya menggunakan ConfusionMatrixDisplay . Namun sangat kikuk untuk digunakan:

• Anda harus memberikan label secara eksplisit
• Anda harus menghitung matriks kebingungan terlebih dahulu
• anda harus membuat objek kelas dan kemudian masih memanggil metode plot

Untuk semua aplikasi, saya dapat memikirkan tanda tangan plot_confusion_matrix dengan (y_true, y_pred, ...) akan jauh lebih nyaman daripada yang kita miliki saat ini. Menurut pendapat saya, ada lebih banyak kasus penggunaan di mana Anda ingin menghitung prediksi secara eksplisit (meskipun saya yakin pandangan saya bias).

Jika Anda memiliki tanda tangan plot_confusion_matrix(y_true, y_pred) dan Anda benar-benar ingin menggunakannya pada data estimator , x , y , hanya ada sedikit kode tambahan untuk ditulis : plot_confusion_matrix(y, estimator.predict(x)) .
Sebagai perbandingan, jika Anda memiliki tanda tangan saat ini dan Anda ingin membuat plot dari y_true dan y_pred , Anda harus menulis lebih banyak kode.

Menurut pendapat saya tanda tangan plot_confusion_matrix(y_true, y_pred) harus default dan fungsi lain yang membutuhkan estimator , x , y harus dibangun di atas.

Last but not least, sejujurnya saya tidak begitu mengerti ide di balik kelas ConfusionMatrixDisplay . Fungsi ini hanya memiliki satu konstruktor dan tepat satu metode, jadi setiap kali Anda menggunakannya, Anda akan membuat instance dan memanggil fungsi plot . Saya tidak mengerti mengapa ini harus menjadi kelas dan bukan hanya fungsi. Juga ada kelas *Display (PrecisionRecall, ROC, ...), tetapi tanda tangan konstruktor- dan plot() mereka sama sekali berbeda, sehingga mereka tidak dapat ditukar.
Mungkin ini melampaui cakupan masalah ini.

@jhennrich

Jika Anda memiliki tanda tangan plot_confusion_matrix(y_true, y_pred) dan Anda benar-benar ingin menggunakannya pada data estimator, x, y, hanya ada sedikit kode tambahan untuk ditulis: plot_confusion_matrix(y, estimator.predict(x)).

Untuk kasus matriks konfusi, mudah untuk memasukkan estimator.predict jika kita memiliki antarmuka y_true, y_pred . Di sisi lain, untuk plot_roc_auc , pengguna perlu melakukan pemotongan:

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])

Last but not least, sejujurnya saya tidak begitu mengerti ide di balik kelas ConfusionMatrixDisplay. Fungsi ini hanya memiliki satu konstruktor dan tepat satu metode, jadi setiap kali Anda menggunakannya, Anda akhirnya membuat instance dan memanggil fungsi plot. Saya tidak mengerti mengapa ini harus menjadi kelas dan bukan hanya fungsi.

Tujuan dari objek Display adalah untuk menyimpan nilai yang dihitung yang memungkinkan pengguna untuk memanggil plot berkali-kali tanpa menghitung ulang. Ini dapat dilihat dengan menggunakan 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"})

Jujur, saya berada di pagar tentang masalah ini. Saya +0,1 untuk menyalin antarmuka metrik untuk metrik yang merencanakan dan menghapus antarmuka est, X, y . :/

Untuk kasus matriks konfusi, mudah untuk memasukkan estimator.predict jika kita memiliki antarmuka y_true, y_pred. Di sisi lain, untuk plot_roc_auc, pengguna perlu melakukan pemotongan:

Ya, tetapi dengan melakukan itu, kami menghindari menghitung prediksi untuk beberapa kali (meskipun memprediksi seringkali tidak begitu mahal)

Mungkin solusi praktis untuk mendukung y_true, y_pred di plot_XXX (bila berlaku) di 0,23.

@jhennrich Bagaimana Anda akan melakukan ini tanpa memberikan label secara eksplisit? Jika label dapat disimpulkan dari apa yang diberikan confusion_matrix akan melakukannya untuk Anda.

Tapi memang Anda benar, itu tiga baris, bukan satu.

Dalam kasus confusion_matrix saya cenderung setuju bahwa kasus yang lebih umum mungkin melewati y_true dan y_pred .
Alasan antarmuka saat ini adalah agar konsisten dengan fungsi plot metrik lainnya. Seperti yang dikatakan @thomasjpfan , kurva roc kurang jelas untuk diplot.

Saat ini kode untuk memplot matriks konfusi dan memplot kurva roc adalah sama. Dengan perubahan yang Anda sarankan, mereka tidak akan sama lagi, dan tidak akan ada cara mudah untuk membuatnya sama.

Pertanyaannya adalah apakah dalam hal ini lebih baik memiliki antarmuka yang konsisten atau antarmuka yang sederhana.
@jhennrich Bagi saya pertanyaan sebenarnya adalah apa antarmuka yang tepat untuk plot_roc_curve itu. Apakah Anda memiliki pemikiran tentang itu?

@thomasjpfan apakah Anda condong mengambil y_store untuk merencanakan roc auc juga?

Pasti ada pro dan kontra untuk menggunakan antarmuka pencetak gol daripada menggunakan antarmuka metrik. Tetapi untuk hal-hal yang lebih kompleks, jauh lebih aman menggunakan antarmuka pencetak gol.

@qinhanmin2014
Saya pikir tidak apa-apa untuk menambahkan y_pred ke plot_confusion_matrix . Pertanyaannya adalah apakah kita ingin menambahkan y_score ke plot_roc_curve dan plot_precision_recall_curve . Jika kita melakukannya maka kita juga harus menambahkan pos_label seperti yang saya katakan di atas, dan semuanya akan menjadi lebih rumit.

Saya melihat tiga jalan keluar dari ini:
a) Hanya tambahkan y_pred ke plot_confusion_matrix , tetapi jangan tambahkan y_score ke plot_roc_curve dll. Kelemahan: masalah memanggil predict_proba beberapa kali tetap ada untuk metrik ini.
b) Mempermudah menggunakan objek Display secara langsung (walaupun saya tidak begitu tahu caranya).
c) Tambahkan metode atau fungsi lain yang mencerminkan antarmuka metrik. Kelemahan: permukaan API yang lebih besar.

Saya tidak berpikir bahwa memiliki fungsi plot_X mencerminkan antarmuka pencetak gol dan metrik pada saat yang sama adalah ide yang bagus secara umum.

Saya pikir akan sangat bagus untuk menyelesaikan ini dengan cara tertentu @adrinjalali apakah Anda ingin membahasnya di pertemuan berikutnya mungkin?

Saya terkadang mengalami mimpi buruk tentang masalah ini. Mungkin kita bisa menambahkan metode statis yang mengambil output dari metrik secara langsung:

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

Untuk kurva roc:

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

Di samping catatan, dari melihat basis kode, saya pikir lebih banyak pengguna yang akrab dengan antarmuka metrik daripada antarmuka skor.

Saya terkadang mengalami mimpi buruk tentang masalah ini.

Oh tidak :(

Di samping catatan, dari melihat basis kode, saya pikir lebih banyak pengguna yang akrab dengan antarmuka metrik daripada antarmuka skor.

Saya pikir ini pasti benar. Tetapi saya juga cukup yakin bahwa orang menggunakan y_pred ketika mereka seharusnya menggunakan y_score dan mendapatkan hasil yang salah karena antarmuka tidak memberi tahu Anda bahwa Anda perlu melakukan sesuatu yang berbeda dan tidak- seseorang pernah membaca dokumen.

Saya tidak yakin bagaimana metode statis yang Anda usulkan berbeda dari konstruktor, tetapi mungkin saya mengabaikan sesuatu.

Hai, saya baru saja memilih masalah - sebagai pengguna sklearn lama, saya menemukan API saat ini untuk plot_confusion_matrix sangat... yah, membingungkan. Saya sangat suka penambahannya (lebih sedikit copy-paste), tetapi fungsi metrik selalu menggunakan skema (y_true, y_pred) yang lebih fleksibel dan sudah biasa saya gunakan.

Dalam kasus saya, tidak masuk akal untuk memasukkan estimator, karena ini adalah model yang sangat lambat dan saya lebih suka memuat prediksi dari file daripada menjalankannya kembali setiap kali saya ingin menganalisis hasilnya. Saya senang mengetahui di utas ini ada solusi menggunakan *Display objek, tetapi kemampuan menemukannya tidak bagus - saya sarankan setidaknya menambahkannya ke dokumentasi plot_confusion_matrix atau mungkin panduan pengguna matriks kebingungan ?

Dalam kasus saya, tidak masuk akal untuk memasukkan estimator, karena ini adalah model yang sangat lambat dan saya lebih suka memuat prediksi

Terima kasih atas masukan Anda. Jika API saat ini membingungkan, akan semakin masuk akal untuk beralih ke antarmuka seperti API metrik dan melalui siklus penghentian yang menyakitkan.

Kekhawatiran terbesar yang kami miliki dengan menggunakan antarmuka metrik adalah:

Tetapi saya juga cukup yakin bahwa orang menggunakan y_pred ketika mereka seharusnya menggunakan y_score dan mendapatkan hasil yang salah karena antarmuka tidak memberi tahu Anda bahwa Anda perlu melakukan sesuatu yang berbeda dan tidak ada yang pernah membaca dokumen.

@pzelasko Apa pendapat Anda tentang hal ini?

@thomasjpfan Saya mengerti masalahnya, ini masalah yang sulit. Mungkin kompromi yang masuk akal adalah dengan hanya mengizinkan argumen kata kunci untuk fungsi ini (sekarang Anda tidak perlu lagi mendukung Python 2)? Seperti: def plot_confusion_matrix(*, y_true, y_pred, ...) . Ini masih berbeda dari metrik lainnya, tetapi 1) memiliki alasan yang bagus untuk itu, 2) setidaknya menggunakan jenis input yang sama dengan fungsi lainnya.

Bagaimanapun, saya tahu mengapa Anda ragu untuk membuat perubahan API apa pun, itu sebabnya saya menyarankan untuk setidaknya menyebutkan penyelesaiannya di dokumen. (Saya sebenarnya sudah membacanya berkali-kali dan saya sangat menghargainya!)

Cara saat ini untuk menggunakan y_true dan y_pred ditampilkan di sini: https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_display_object_visualization.html#create -confusionmatrixdisplay

Saya tahu saya melakukan peregangan di sini tetapi bagaimana dengan ini:

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

di mana posisi kedua menerima y_true sebagai prediksi jika estimator='precomputed .

jika Anda ingin meregangkan lebih banyak lagi, saya lebih suka plot_confusion_matrix((estimator, X, y), ...) atau plot_confusion_matrix((y_true, y_pred), ...) tetapi saya tidak yakin itu menyelesaikan masalah yang diangkat oleh @amueller mengenai API seperti metrik

Ada beberapa utilitas plot baru yang memungkinkan API metric benar-benar masuk akal:

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

Saya memahami masalah yang @amueller sebutkan tentang pos_label dll., tetapi ini bukan masalah untuk salah satu fungsi yang disebutkan di atas.

Apakah kami boleh mendukung API pencetak gol dan metrik untuk keduanya? Kami tidak perlu khawatir tentang kompatibilitas ke belakang di sana.

Saya masih menerima saran saya untuk menggunakan precomputed , yang biasa kami gunakan di estimator kami. Dalam hal ini, tanda tangannya adalah:

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

Saya akan mengumpulkan PR untuk melihat seperti apa ini.

Saya belum benar-benar membahas API, saya hanya bertanya apakah kami boleh mendukung kedua opsi untuk PR baru.

(Tetapi mengenai API, saya tidak berpikir 'precomputed' banyak membantu: apa yang kita lakukan tentang X ? Saya pikir kita harus menjaga (y_pred) dan (estimator, X) saling eksklusif, dengan kesalahan yang benar . Juga apa artinya estimator dikomputasi sebelumnya?)

Atau estimator='none' , estimator='predictions' , estimator='precomputed_predictions' , dan kemudian X menjadi y_pred atau y_score . Ini hampir seperti bagaimana kita menangani jarak yang telah dihitung sebelumnya dengan X dalam estimator.

Apakah kami boleh mendukung API pencetak gol dan metrik untuk keduanya?

Bagaimana kita akan mendukung kedua opsi? Dengan dua fungsi?

Saya juga akan menyukai:

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

yang akan menjadi dua metode.

Saran Guillaume untuk menggunakan tupel https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -670590882 adalah salah satu opsi. Saya pikir itu akan menjadi pilihan terbaik jika kami mulai dari sana dari awal. Tapi saya khawatir menggunakan tupel merusak konsistensi dengan utilitas yang ada.

plot_XYZ(estimator=None, X=None, y=None, y_pred=None) dengan pengecualian bersama adalah opsi lain, dan itu yang saya anjurkan, untuk saat ini.

Saya suka CalibrationDisplay.from_estimator(...) , tetapi seperti yang dicatat Andy, kita harus menghapus fungsi plot_XYZ . Mungkin layak dipertimbangkan.

Saya pikir kita bisa pindah ke tupel dan menghentikan perilaku saat ini. (Selama kita setuju untuk menggunakan tupel)

Jadi ini sepertinya membahas ruang nama, kan?
Apakah kita memiliki satu fungsi dan satu konstruktor, atau dua metode kelas, atau dua fungsi, itu adalah fungsi yang persis sama dan pada dasarnya kode yang sama.

@pzelasko @jhennrich bagaimana perasaan Anda tentang memiliki dua metode kelas atau dua fungsi? Atau apakah Anda lebih suka satu fungsi, yang agak berantakan di python.

Dan jika Anda lebih suka dua fungsi atau dua metode kelas, apakah Anda melihat manfaat apa pun meskipun dapat ditemukan? Discoverability mungkin cukup menjadi alasan untuk melakukan classmethods, saya tidak melihat argumen yang kuat untuk memiliki dua fungsi.

Bisakah kita menambahkan label pemblokir di sini? Tampaknya itu mencegah kemajuan pada #18020 dan #17443 (cc @cmarmo)

Label pemblokir adalah untuk pemblokir rilis (hal-hal yang benar-benar perlu diperbaiki sebelum rilis), bukan untuk pemblokir PR

Ah senang tahu.

@pzelasko @jhennrich bagaimana perasaan Anda tentang memiliki dua metode kelas atau dua fungsi? Atau apakah Anda lebih suka satu fungsi, yang agak berantakan di python.

Dan jika Anda lebih suka dua fungsi atau dua metode kelas, apakah Anda melihat manfaat apa pun meskipun dapat ditemukan? Discoverability mungkin cukup menjadi alasan untuk melakukan classmethods, saya tidak melihat argumen yang kuat untuk memiliki dua fungsi.

Saya paling suka pendekatan two-classmethods, terutama pola from_xxx - sth seperti yang diusulkan @thomasjpfan :

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

Sepertinya tidak ada penentangan yang kuat untuk menggunakan 2 metode kelas, jadi mari kita lakukan itu. Kita harus:

• Perkenalkan metode kelas untuk plot yang ada saat ini:

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay . Untuk yang satu ini, kami tidak ingin memperkenalkan metode kelas from_predictions karena tidak masuk akal, kami hanya ingin from_estimator .

• Untuk semua Tampilan yang tercantum di atas, hentikan fungsi plot_... . Kita tidak perlu mencela plot_det_curve karena belum dirilis, kita tinggal menghapusnya saja.

• untuk PR baru seperti #17443 dan #18020 kita dapat langsung mengimplementasikan metode kelas daripada memperkenalkan fungsi plot .

Ini sedikit pekerjaan tapi saya pikir kita bisa menyelesaikan ini sebelum 0.24 sehingga #17443 dan #18020 sudah bisa bergerak maju.

Ada keberatan @thomasjpfan @jnothman @amueller @glemaitre ?

@jhennrich @pzelasko , apakah Anda tertarik untuk mengirimkan PR untuk memperkenalkan metode kelas di salah satu objek Tampilan?

Terima kasih telah membuat keputusan @NicolasHug! Saya akan naik ke #17443 (setelah menunggu keberatan)

Saya tidak keberatan.

Tidak ada keberatan juga.

Saya akan mengurus kelas lain kemudian dan memajukan PR saya yang macet.
@lucyleeow jika saya tidak melakukan semua itu dan Anda sedang mencari beberapa PR, ping saya :)

Saya ingin berkontribusi tetapi saya terlibat dalam terlalu banyak proyek saat ini. Terima kasih telah mendengarkan saran!

Kedengarannya bagus :)