Terima kasih telah membuka masalah ini, ping @jnothman @amueller @GaelVaroquaux menurut gitter

8425 tidak terkait dengan Wilayah Keputusan Pengklasifikasi,?

Saya lebih suka memindahkan plot_tree dan plot_partial_dependence ke sklearn.plot dan menyelesaikan #13335 di 0,21 (mungkin memperkenalkan fungsi untuk memplot batas keputusan, karena itu penting dan tidak mudah untuk IMO pemula). Apa yang orang lain pikirkan?

Untuk membantu mengontrol ruang lingkup sklearn.plot, saya mengusulkan agar kita hanya melakukan plot pada level sumbu dan bukan level gambar. Pengguna akan memasukkan sumbu sebagai kata kunci. Untuk kenyamanan, default sumbu adalah Tidak Ada. Hanya dalam kasus ini, fungsi plotting akan menghasilkan sumbu/gambar untuk diplot.

Ide bagus, tetapi tidak konsisten dengan fungsi yang ada (plot_tree dan plot_partial_dependence), bukan?

Ada kasus di mana Anda perlu menampilkan/memodifikasi gambar, seperti dengan
beberapa subplot (lihat plot segi seaborn dll, dan plot kesal untuk
contoh). Bisakah Anda memberikan alasan mengapa Anda ingin membatasinya pada sumbu?

Pada Jumat, 15 Maret 2019, 02:19 Hanmin Qin, [email protected] menulis:

Terima kasih telah membuka masalah ini, ping @jnothman
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquaux menurut gitter

8425 https://github.com/scikit-learn/scikit-learn/issues/8425 bukan

terkait dengan Wilayah Keputusan Pengklasifikasi,?
Saya lebih suka memindahkan plot_tree dan plot_partial_dependence ke sklearn.plot dan
selesaikan #13335 https://github.com/scikit-learn/scikit-learn/issues/13335
di 0,21 (mungkin memperkenalkan fungsi untuk memplot batas keputusan, karena
itu penting dan tidak mudah untuk pemula IMO). Apa yang orang lain pikirkan?

Untuk membantu mengontrol ruang lingkup sklearn.plot, saya mengusulkan agar kita hanya melakukan ploting
pada tingkat sumbu dan bukan tingkat gambar. Pengguna akan melewati sumbu
sebagai kata kunci. Untuk kenyamanan, default sumbu adalah Tidak Ada. Hanya di
dalam hal ini, akankah fungsi plotting menghasilkan sumbu/gambar untuk diplot.

Ide bagus, tetapi tidak konsisten dengan fungsi yang ada (plot_tree dan
plot_partial_dependence), kan?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

Ide bagus, tetapi tidak konsisten dengan fungsi yang ada (plot_tree dan plot_partial_dependence), bukan?

@qinhanmin2014 plot_tree tampaknya tidak menyesuaikan angka. plot_partial_dependence memang membuat banyak plot berdasarkan features . Meskipun, itu dapat direfaktor menjadi plot tingkat sumbu. Seorang pengguna perlu memanggil plot_partial_dependence beberapa kali untuk memberikan sumbu (dan fitur) yang berbeda.

Bisakah Anda memberikan alasan mengapa Anda ingin membatasinya pada sumbu?

@jnothman Seaborn memiliki dokumentasi yang dengan jelas memisahkan plot "tingkat-angka" dan plot "tingkat-sumbu". Jika kita dapat mendokumentasikan perilaku ini dengan benar dalam scikit-learn, plot "level-angka" ini dimungkinkan. Kekhawatiran terbesar saya dengan plot "angka-tingkat", adalah mereka lebih sulit untuk dipelihara dan diuji. Akan ada elemen dari satu sumbu yang mungkin tumpang tindih dengan sumbu lain. Meskipun, kita dapat mengatasi ini dengan menyusun gambar sedemikian rupa sehingga tumpang tindih lebih jarang terjadi.

Dalam hal pengujian, kita bisa menggunakan cara seaborn dan menguji langsung objek matplotlib atau cara yellowbrick dimana kita melakukan pengujian tingkat piksel. Saya cenderung menyukai pengujian objek matplotlib.

2 sen saya:

• +1 untuk memuat fungsi-fungsi yang mengakses matplotlib dalam sub-paket umum, atau, pada modul di setiap sub-paket (sklearn.linear_models.plot, sklearn.ensemble.plot).

• Seperti yang disebutkan oleh @thomasjpfan , hanya mengakses sumbu membuatnya lebih mudah untuk diuji.

  Juga, dulu sekali, ada diskusi di ekosistem untuk memberikan backend plot lain objek seperti "Sumbu" untuk kompatibilitas. Saya tidak tahu kemana perginya. Googling cepat tidak menunjukkan banyak hal. Yang paling dekat adalah plotly.tools.mpl_to_plotly, yang sebenarnya tidak membutuhkan batasan ini, jadi saya pikir argumen itu sia-sia.

mungkin memperkenalkan fungsi untuk memplot batas keputusan, karena itu penting dan tidak mudah bagi pemula IMO

Saya setuju tetapi saya juga berpikir bahwa menunjukkan kepada pengguna cara merencanakan hasil seperti batas keputusan adalah salah satu tujuan dari contoh tersebut.

Jika saya ingin plot pertama yang cepat dari hasil, fungsi plot sangat bagus, terutama untuk plot yang rumit seperti plot pohon, tetapi saya sangat sering ingin mengubah plot sesuai kebutuhan saya dan untuk alasan itu saya lebih suka mengandalkan contoh yang ada dan memodifikasi kode.

Mengenai nama modul, IMO inspect lebih fleksibel daripada plot :

• Saya tidak bisa memikirkan plot apa pun yang bukan semacam inspeksi
• #12599 (Ketergantungan Sebagian) sudah memperkenalkan inspect

Pemeriksaan IMO lebih fleksibel daripada plot

tidak ada pendapat yang kuat, akan memilih +1 untuk kedua nama. Mungkin plotnya lebih lugas?

Sekali lagi saya tertarik untuk membuat modul baru sebelum 0,21 dan memindahkan plot_tree dan plot_partial_dependence di sana. Idealnya kita juga harus mencapai konsensus tentang API (misalnya, level sumbu/level angka).

Poin lain yang mendukung inspect :

Kami mungkin ingin memeriksa alat yang menawarkan plot sebagai opsi. Misalnya, cetak karakteristik pohon (jumlah simpul, daun, titik pisah, dll.) dan secara opsional plot dengan matplotlib.

Saya akan lebih suka menggunakan sumbu daripada angka, seperti yang disarankan (sigh, saya harus mengubah PDP lagi). Lebih mudah bagi kami untuk mendukung dan menguji. Ini sedikit lebih banyak pekerjaan untuk pengguna, tetapi juga memungkinkan lebih banyak kontrol.

Pemeriksaan IMO lebih fleksibel daripada plot

tidak ada pendapat yang kuat, akan memilih +1 untuk kedua nama. Mungkin plotnya lebih lugas?

"inspect" dimuat dengan Python (ini adalah modul di perpustakaan standar). Saya
akan menghindari menggunakan nama yang sama.

Sekali lagi saya tertarik untuk membuat modul baru sebelum 0,21 dan memindahkan plot_tree dan plot_partial_dependence di sana. Idealnya kita juga harus mencapai konsensus tentang API (misalnya, level sumbu/level angka).

Ini seharusnya tidak menunda 0,21. Tujuan kami adalah rilis lebih awal, dan semoga
rilis lebih awal lagi.

"inspect" dimuat dengan Python (ini adalah modul di perpustakaan standar). Saya
akan menghindari menggunakan nama yang sama.

Saya mengusulkan model_inspection . Ini cocok dengan nama model_selection .

Kami mungkin ingin memeriksa sesuatu yang bukan model (encoder, preprocessor, hasil pencarian grid...)

inspection lalu?

Hal-hal itu juga model :)

Saran Gael tentang submodul plot publik pada setiap sub-paket sangat berharga
mempertimbangkan.

FWIW, saya juga lebih suka plot inspect , karena lebih intuitif bagi sebagian besar pengguna untuk menemukannya. Orang lebih cenderung mencoba _merencanakan_ model mereka daripada _memeriksa_ model mereka (saat menelusuri di mesin telusur misalnya, atau melihat kemungkinan opsi pelengkapan otomatis pada IDE mereka).

Saran Gael tentang submodul plot publik pada setiap sub-paket patut dipertimbangkan.

Jika demikian, di mana kita harus meletakkan plot_decision_boundary ?

Mengenai #12599, @NicolasHug Saya ragu apakah partial_dependence harus ada di modul baru. (yaitu, ensemble.partial_dependence + plot.plot_partial_dependence)

Jika demikian, di mana kita akan meletakkan plot_decision_boundary?

sklearn.plot ?

Saya tidak ingin mendorong terlalu keras untuk solusi ini. Namun, saya setuju dengan
perasaan bahwa "plot" mungkin lebih mudah ditemukan oleh pengguna akhir.

Mengenai #12599, @NicolasHug Saya ragu apakah partial_dependence harus ada di modul baru. (yaitu, ensemble.partial_dependence + plot.plot_partial_dependence)

Saya tidak mengerti apa yang Anda maksud. #12599 mencela ensemble.partial_dependence demi inspect.partial_dependence (tentu saja inspect dapat berubah berdasarkan diskusi ini). API juga berbeda antara 2 implementasi.

Saya baik-baik saja dengan plot , saya hanya khawatir tentang potensi tumpang tindih yang tinggi dengan modul inspeksi akhirnya, tetapi saya tidak akan mendorongnya lebih jauh :)

submodul plot publik pada setiap subpaket layak untuk dipertimbangkan.

Namun sejauh ini semua alat plot yang diusulkan (PDP, Kalibrasi, Confusion matrix, dan wilayah keputusan) tidak spesifik untuk satu modul.

Saya tidak mengerti apa yang Anda maksud. #12599 tidak lagi menggunakan ensemble.partial_dependence dan menggantinya dengan inspect.partial_dependence (tentu saja inspect dapat berubah berdasarkan diskusi ini). API juga berbeda antara 2 implementasi.

Maaf saya belum melihat PR itu secara detail. Mungkin inspect.partial_dependence + plot.plot_partial_dependence ?

Mungkin inspect.partial_dependence + plot.plot_partial_dependence?

Saya suka pemisahan yang jelas antara menghitung nilai dan merencanakannya.
Ini adalah model/tampilan seperti pemisahan, dan itu akan membantu meningkatkan
dapat digunakan kembali.

Bukankah sebelumnya Gaël mengusulkan sklearn.inspect.partial_dependence dan
sklearn.inspect.plot.plot_partial_dependence (Ganti nama lain
untuk memeriksa jika sesuai)? Saya tidak keberatan ini.

Bukankah sebelumnya Gaël mengusulkan sklearn.inspect.partial_dependence dan sklearn.inspect.plot.plot_partial_dependence (Ganti nama lain untuk inspect jika sesuai)?

Ya, tapi saya bertanya padanya di mana kita harus meletakkan plot_decision_boundary dan sepertinya dia berubah pikiran?

FYI, saya memperbarui PR PDP https://github.com/scikit-learn/scikit-learn/pull/12599 mengikuti rekomendasi di atas:

• partial_dependence ada di sklearn.model_inspection
• plot_partial_dependence ada di skearn.plot

Dokumen ada di sini https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

Perhatikan bahwa panduan pengguna hanya menyertakan modul plot untuk saat ini. Saya tidak berpikir masuk akal untuk memiliki bagian panduan pengguna yang hanya akan berbicara tentang model_inspection.partial_dependence , karena kendala / perilakunya sama dengan plot_partial_dependence .

(Ini adalah jenis tumpang tindih yang saya khawatirkan)

Tentu saja jika menurut Anda masih lebih baik untuk memiliki panduan pengguna terpisah untuk partial_dependence dan plot_partial_dependence , saya akan melakukannya.

FYI, saya update PDP PR #12599 mengikuti rekomendasi di atas:
partial_dependence ada di sklearn.model_inspection
plot_partial_dependence ada di skearn.plot

+1

Perhatikan bahwa panduan pengguna hanya menyertakan modul plot untuk saat ini. Saya tidak berpikir masuk akal untuk memiliki bagian panduan pengguna yang hanya akan berbicara tentang model_inspection.partial_dependence, karena kendala/perilakunya sama dengan plot_partial_dependence.

+1

Jadi kami memutuskan untuk menggunakan nama sklearn.plot?

Saya menemukan sklearn.plot mengimpor dependensi dari seluruh sklearn menjadi agak aneh ketika kami menghindari menempatkan semua orang di root namespace.

Jadi Anda lebih suka sklearn.model_inspection.plot dan meletakkan plot_partial_dependence() sana?

Tidak ada modul plot , saya baik-baik saja dengan itu

Saya pikir saya lebih suka itu. Belum pasti bagaimana generalisasinya.

Saya pikir saya lebih suka itu. Belum pasti bagaimana generalisasinya.

Selama kita dapat menemukan tempat yang tepat untuk meletakkan hal-hal seperti plot_decision_boundary , saya akan memilih +1 untuk sklearn.XXX.plot .

Apakah ini perlu tidur? kami tampaknya tidak membuat banyak kemajuan

EDIT ugh, mengantuk saya membaca komentar Joel karena saya tidak berpikir saya lebih suka itu , maaf

Apakah ini perlu tidur? kami tampaknya tidak membuat banyak kemajuan

Saya baik-baik saja dengan salah satu solusi ( sklearn.plot / sklearn.XXX.plot ). Masalah utama di sini IMO adalah tidak ada yang memberi tahu saya di mana kita harus meletakkan hal-hal seperti plot_decision_boundary jika kita menggunakan sklearn.XXX.plot :)

sklearn.model_inspection.plot ?

sklearn.model_inspection.plot?

Ide yang menarik, saya akan memilih +1. Mungkin tidak begitu baik untuk membuang semua hal ke sklearn.plot (https://github.com/rasbt/mlxtend meletakkan semua fungsi plot dalam satu modul).

Jadi kami akan mendukung from sklearn.XXX.plot import plot_XXX ? Akankah kami mendukung from sklearn.XXX import plot_XXX ?

Saya pikir persyaratan eksplisit .plot dalam impor adalah sesuatu
orang lain di sini telah mencari.

Ada juga yang terbalik dari sklearn.plot.XXX import plot_YYY

Saya pikir persyaratan eksplisit .plot dalam impor adalah sesuatu yang dicari orang lain di sini.

Jadi kita telah mencapai konsensus untuk menggunakan sklearn.XXX.plot (hanya dukungan dari sklearn.XXX.plot import plot_XXX )?

Ada juga yang terbalik dari sklearn.plot.XXX import plot_YYY

Saya tidak mengerti.

Ada juga yang terbalik dari sklearn.plot.XXX import plot_YYY

Maksud saya kita bisa memiliki
sklearn.plot.model_inspection.plot_partial_dependence daripada
sklearn.model_inspection.plot.plot_partial_dependence. Tidak yakin apakah ini
memberikan manfaat/kejelasan.

Maksud saya kita bisa memiliki
sklearn.plot.model_inspection.plot_partial_dependence daripada
sklearn.model_inspection.plot.plot_partial_dependence. Tidak yakin apakah ini
memberikan manfaat/kejelasan.

Jadi sekarang kita memiliki 3 opsi:
(1) sklearn.plot.plot_YYY (misalnya, sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (misalnya, sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (misalnya, sklearn.tree.plot.plot_tree, tidak mendukung dari sklearn.XXX import plot_YYY)
Saya akan memilih +1 untuk semua solusi ini.
Saya lebih suka membuat keputusan sebelum 0,21 untuk menghindari penghentian sklearn.tree.plot_tree

Tidak yakin itu perlu tidur tetapi mungkin layak mengundang pendapat tentang?
milis

Tidak yakin perlu tidur tapi mungkin layak mengundang pendapat di milis

+1. Tampaknya tidak termasuk dalam kriteria SLEP.

Seperti yang saya katakan di milis, saya pikir kita juga harus benar-benar mempertimbangkan "di mana pekerjaan itu terjadi" atau seperti apa antarmuka itu nantinya. Itu sudah cukup jelas untuk ketergantungan parsial.
Haruskah plot_partial_dependence memanggil partial_dependence atau mendapatkan output partial_dependence sebagai input? Pertanyaan ini adalah pertanyaan yang valid untuk semua fungsi plot pada dasarnya.
Pertimbangan utama yang saya diskusikan dengan @NicolasHug adalah bahwa memiliki plot_X call compute_X nyaman bagi pengguna - selama mereka hanya ingin merencanakannya sekali. Jika mereka tidak menyukai plot dan ingin mengubah sesuatu, mereka perlu compute_X lagi, yang berpotensi sia-sia.

Jadi kita juga bisa

• selalu ambil hasil dari compute_X . downside: tidak nyaman dan rawan kesalahan: bagaimana urutan presisi, penarikan, dan ambang batas lagi di precision_recall_curve?

• selalu ambil input ke compute_X dan panggil compute_X dari plot_X . downside: Anda perlu menghitung ulang untuk setiap plot.

• izinkan keduanya, jadi plot_X dapat mengambil input ke compute_X dan memanggil compute_X atau mengambil output compute_X jika pengguna sudah membuatnya. Itu memiliki kelemahan memperumit tanda tangan (dan mungkin memperumit mendokumentasikannya). Juga, jika pengguna memanggil plot_X sehingga secara internal melakukan compute_X dan kemudian menginginkan plot lain, dia perlu compute_X lagi. Jadi Anda perlu mengantisipasi bahwa Anda menginginkan lebih dari satu plot sebelum memanggil plot_X untuk pertama kalinya. Atau Anda perlu mengekspos hasil compute_X saat memanggil plot_X , tetapi tidak jelas bagi saya bagaimana melakukannya tanpa desain berorientasi objek

• membuat keputusan tergantung pada seberapa mahal compute_X, seperti untuk matriks kebingungan dan plot ketergantungan parsial dan plot kalibrasi, kami tidak peduli dengan biaya komputasi ulang, tetapi untuk plot ketergantungan parsial yang kami lakukan. kelemahan: antarmuka yang tidak konsisten.

Pertimbangan utama yang saya diskusikan dengan @NicolasHug adalah bahwa memiliki panggilan plot_X compute_X nyaman bagi pengguna - selama mereka hanya ingin memplotnya sekali. Jika mereka tidak menyukai plot dan ingin mengubah sesuatu, mereka perlu menghitung_X lagi, yang berpotensi menjadi pemborosan.

+1000. Ini adalah masalah umum yang saya lihat dalam kode penelitian.

Dari masalah desain, itu melanggar pemisahan MVC (sedikit bertele-tele,
maaf).

Dalam berbagai solusi yang Anda usulkan, apakah Anda akan mempertimbangkan untuk mengambil
model yang pas sebagai pendekatan? Saya merasa itu akan mengurangi masalah
mengingat urutan parameter. Tapi mungkin ada tambahan
masalah.

Saya tidak yakin apa yang Anda maksud dengan model pas. Seringkali keluaran komputasi bukanlah model yang pas. Kita dapat mendefinisikan objek untuk semua hasil komputasi, sehingga partial_dependence mengembalikan objek PartialDependence . Atau sekelompok. Tapi itu tidak mengembalikan estimator.

Oh alasan saya mengemukakan ini sekarang: tanpa keputusan ini saya tidak tahu akan seperti apa kode pengguna, dan saya tidak suka membuat keputusan penamaan/API tanpa bisa menuliskan contoh;)

mengembalikan suatu objek akan sangat tidak seperti sklearn, imho. Tapi itu mungkin menyelesaikan masalah lokasi: itu bisa memiliki metode plot ;)

Seringkali keluaran komputasi bukanlah model yang pas. Kita dapat mendefinisikan objek untuk semua hasil komputasi, sehingga partial_dependence mengembalikan objek PartialDependence. Atau sekelompok. Tapi itu tidak mengembalikan estimator.

Poin diambil.

Salah satu pilihan (tidak mengatakan bahwa itu adalah yang terbaik) adalah memiliki semua
fungsi komputasi mengembalikan tupel bernama dan semua komputasi yang sesuai
fungsi mengambil ini. Itu akan agak konsisten dengan modern
tambahan ke pustaka standar Python.

dan saya tidak suka membuat keputusan penamaan/API tanpa bisa menuliskan contoh ;)

Aku seperti kamu.

Jadi jika komputasinya mahal, kita bisa melakukan komputasi di luar fungsi. Jika demikian, kami mengembalikan objek dan fungsi ploting mengambil objek ini sebagai inputnya, bukan? Saya akan memilih +1.

Dan mungkin kita perlu masalah lain untuk membahas ini :)

Manfaat dari saran @GaelVaroquaux adalah mungkin tidak mengharuskan pengguna untuk mengubah kode mereka karena pembongkaran Tuple. Tapi itu tidak akan berhasil jika ada satu objek yang dikembalikan seperti di confusion_matrix . Ada Tuple tidak akan benar-benar diperlukan tetapi kemudian antarmuka menjadi sedikit tidak konsisten.

@qinhanmin2014 jika kami mengembalikan objek arbitrer, kami harus menghentikan tipe pengembalian untuk suatu fungsi setiap kali kami membuat pembantu plot. Itu sepertinya berantakan.

Saya punya satu ide, dan kemudian ide kedua yang lebih baik:
1) buat antarmuka berorientasi objek kedua yang memanggil fungsi yang ada, menyimpan objek, dan memiliki metode plot, seperti

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

Itu akan menyelesaikan masalah, tetapi akan menduplikasi beberapa antarmuka dan itu akan sedikit tidak jelas. Sebenarnya prinsip yang sama dapat dilakukan dengan cara yang menurut saya lebih intuitif:
2) minta fungsi plot_ selalu melakukan pekerjaan, gunakan hasilnya untuk membuat instance objek yang menyimpan hasilnya dan memplotnya:

plot_confusion_matrix(y, y_pred)

karenanya hanya akan memplot, dan mengembalikan objek ConfusionMatrixPlotter , yang menyimpan hasilnya, dan memiliki metode plot .
Jadi dalam kasus sederhana hanya merencanakan sekali, itu hanya satu panggilan fungsi. Jika Anda kemudian ingin hasilnya melakukan sesuatu yang lain dengannya, mereka disimpan di objek. Jika Anda ingin memplot lagi, Anda bisa memanggil plot pada objek lagi. Jika Anda telah menghitung hasilnya dan kemudian memutuskan ingin membuat plot, Anda dapat membuat instance ConfusionMatrixPlotter secara langsung.

Meskipun ini memperlihatkan kelas tambahan untuk kasus penggunaan yang lebih kompleks, saya pikir ini adalah pertukaran yang masuk akal karena memiliki jawaban yang bagus untuk semua situasi.

karenanya hanya akan memplot, dan mengembalikan objek ConfusionMatrixPlotter, yang menyimpan hasilnya, dan memiliki metode plot.

Mengapa pengguna perlu memplot data yang sama lagi? @amueller menyesuaikan format?

@qinhanmin2014 ya, buat font lebih besar, ubah warna, plot dengan sesuatu yang lain bersama di plot yang sama, tambahkan label, ...

@qinhanmin2014 ya, buat font lebih besar, ubah warna, plot dengan sesuatu yang lain bersama di plot yang sama, tambahkan label, ...

Saya ragu apakah perlu mempertimbangkan masalah pemformatan ini di sini. Pengguna dapat memulai akan sebagian kecil dari dataset?

Dan @amueller kami akan mendukung kapak yang lewat, sehingga pengguna dapat dengan mudah menyesuaikan plot setelah mereka memanggil fungsi plot?

@qinhanmin2014 tidak, banyak hal yang tidak dapat dengan mudah diubah setelahnya, dan kami tidak perlu memikirkan semua pemformatan sendiri, tetapi kami harus mengizinkan pengguna untuk merencanakan sesuatu lagi. Ini pada dasarnya akan terjadi setiap kali Anda membuat plot. Dan harus membuat subsampel dataset setiap kali saya ingin membuat plot agak mengganggu. Dan jika nanti saya berubah pikiran, saya masih perlu menghitung ulang.
Pada dasarnya intinya adalah bahwa Anda biasanya tidak dapat mengantisipasi apa yang sebenarnya Anda inginkan dalam analisis eksplorasi Anda, dan harus menghitung ulang semuanya untuk mengubah visualisasi tampaknya tidak bagus.

@qinhanmin2014 tidak, banyak hal yang tidak dapat dengan mudah diubah setelahnya, dan kami tidak perlu memikirkan semua pemformatan sendiri, tetapi kami harus mengizinkan pengguna untuk merencanakan sesuatu lagi. Ini pada dasarnya akan terjadi setiap kali Anda membuat plot. Dan harus membuat subsampel dataset setiap kali saya ingin membuat plot agak mengganggu. Dan jika nanti saya berubah pikiran, saya masih perlu menghitung ulang.

Ya, saya tahu ini mungkin berguna, tetapi masalah utama di sini adalah bahwa kami tidak memiliki cara yang bersih untuk mendukung fungsi ini, dan saya kira sebagian besar fungsi plot tidak memerlukan banyak perhitungan?

Saya suka kita mendiskusikan ini dengan sedikit lebih membumi, tapi tbh I'm
masih belum sepenuhnya yakin bahwa kita bahkan perlu memiliki plot dalam impor
jalan sama sekali. Bagaimanapun, kita tampaknya memiliki plot_ sebagai awalan untuk
fungsi. Pertanyaannya juga terkait dengan plot_tree: mengapa harus begitu
dipisahkan dari kode visualisasi ekspor dan tekstual lainnya?

@qinhanmin2014 Saya tidak berpikir "kami belum memiliki API yang bagus" adalah alasan yang bagus.
Dan ketergantungan parsial, kepentingan permutasi, kurva pembelajaran, kurva validasi, dan hasil GridSearchCV dan RandomizedSearchCV adalah contoh umum yang membutuhkan banyak komputasi. Meskipun untuk gridsearchcv dan randomizedsearchcv hal yang jelas adalah melewatkan objek atau cv_results_ , melakukan pekerjaan di dalam fungsi plot dalam kasus-kasus itu tampaknya tidak masuk akal. Saya tidak sepenuhnya yakin tentang kurva belajar dan kurva validasi tbh.

@jnothman Saya pikir @GaelVaroquaux ingin menjaga ketergantungan matplotlib terbatas pada modul dan itu adalah salah satu motivasi utama? Saya belum benar-benar memiliki pemikiran yang koheren tentang ini.

Dan ketergantungan parsial, kepentingan permutasi, kurva pembelajaran, kurva validasi, dan hasil GridSearchCV dan RandomizedSearchCV adalah contoh umum yang membutuhkan banyak komputasi.

Terima kasih, saya sekarang menyadari bahwa saya salah :)
Meskipun saya masih tidak dapat memahami mengapa penting untuk menyediakan cara bagi pengguna untuk merencanakan tanpa menghitung ulang. Tetapi jika orang lain berpikir demikian dan ada cara yang baik, saya akan memilih +1.

Saya suka kita mendiskusikan ini dengan sedikit lebih membumi, tapi tbh I'm
masih belum sepenuhnya yakin bahwa kita bahkan perlu memiliki plot dalam impor
jalan sama sekali. Bagaimanapun, kita tampaknya memiliki plot_ sebagai awalan untuk
fungsi. Pertanyaannya juga terkait dengan plot_tree: mengapa harus begitu
dipisahkan dari kode visualisasi ekspor dan tekstual lainnya?

Ya ini juga bisa menjadi pilihan. Jika demikian, kita dapat menyebutkan bahwa semua fungsi yang dimulai dengan plot_ memerlukan matplotlib. Keuntungan lain dari opsi ini adalah kita tidak perlu memindahkan fungsi yang ada.

Menelusuri diskusi ini, saya setuju untuk tidak menambahkan modul sklearn.plot , dan menggunakan awalan plot_ untuk menandakan persyaratan matplotlib .

Misalnya, di https://github.com/scikit-learn/scikit-learn/pull/12599 , partial_dependence dan plot_partial_dependence akan ditempatkan di inspection .

Oke, kecuali ada yang tidak setuju dengan ini di hari-hari berikutnya, saya akan memperbarui PR PDP dan:

• masukkan partial_dependence dan plot_partial_dependence keduanya di sklearn.inspection
• buat plot_partial_dependence mengembalikan banyak dengan objek fig dan ax sebagai atribut (saat ini ia mengembalikannya dalam Tuple). Dengan cara ini, kami dapat menjaga agar 2 fungsi ini tetap kompatibel saat kami menerapkan opsi kedua dari https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520

Bisakah kita membuat keputusan akhir di sini?
Proposal disetujui oleh @jnothman , @NicolasHug dan saya (maaf jika saya salah): sklearn.XXX.plot_YYY (dukungan dari sklearn.XXX import plot_YYY). Kami akan menyebutkan bahwa semua fungsi yang dimulai dengan plot_ memerlukan matplotlib.
Keuntungan utama dari proposal ini adalah kita tidak perlu memindahkan fungsi yang ada.

Tidur di atasnya Saya pikir itu cukup sederhana untuk dijelaskan dan menghindari kesulitan untuk memikirkan api plot bersama antara modul yang berbeda.

Ya, mari kita lakukan itu. Jadikan fungsi pembantu untuk memberikan yang lebih bermanfaat
ImporError

FYI, saya menambahkan sklearn.utils.check_matplotlib_support di #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

FYI, saya menambahkan sklearn.utils.check_matplotlib_support di #12599

Itu hebat! Terima kasih.