इस मुद्दे को खोलने के लिए धन्यवाद, गटर के अनुसार @jnothman @amueller @GaelVaroquaux को पिंग करें

8425 क्लासिफायर के निर्णय क्षेत्र से संबंधित नहीं है?

मैं प्लॉट_ट्री और प्लॉट_पार्टियल_डिपेंडेंस को sklearn.plot पर ले जाना पसंद करता हूं और 0.21 में # 13335 को हल करता हूं (शायद निर्णय सीमा को प्लॉट करने के लिए एक फ़ंक्शन पेश करें, क्योंकि यह महत्वपूर्ण है और शुरुआती आईएमओ के लिए आसान नहीं है)। दूसरे क्या सोचते हैं?

sklearn.plot के दायरे को नियंत्रित करने में मदद करने के लिए, मेरा प्रस्ताव है कि हम केवल अक्ष स्तर पर प्लॉटिंग करें, न कि आकृति स्तर पर। उपयोगकर्ता कुल्हाड़ियों में एक कीवर्ड के रूप में पास होगा। सुविधा के रूप में, कुल्हाड़ियों का डिफ़ॉल्ट कोई नहीं होगा। केवल इस मामले में, प्लॉटिंग फ़ंक्शन प्लॉट करने के लिए एक अक्ष/आंकड़ा उत्पन्न करेगा।

अच्छा विचार है, लेकिन मौजूदा कार्यों (प्लॉट_ट्री और प्लॉट_पार्टियल_डिपेंडेंस) के अनुरूप नहीं है, है ना?

ऐसे मामले हैं जहां आपको किसी आंकड़े को आउटपुट/संशोधित करने की आवश्यकता होती है, जैसे कि with
मल्टीपल सबप्लॉट्स (समुद्री जन्म के पहलू प्लॉट आदि देखें, और इसके लिए अपसेटप्लॉट देखें)
उदाहरण)। क्या आप कारण बता सकते हैं कि आप इसे कुल्हाड़ियों तक सीमित क्यों रखना चाहते हैं?

शुक्रवार, १५ मार्च २०१९, २:१९ पूर्वाह्न हनमिन किन, नोटिफिकेशन @github.com ने लिखा:

इस मुद्दे को खोलने के लिए धन्यवाद, पिंग @jnothman
https://github.com/jnothman @amueller https://github.com/amueller
@GaelVaroquaux https://github.com/GaelVaroquaux गटर के अनुसार

८४२५ https://github.com/scikit-learn/scikit-learn/issues/8425 नहीं है

क्लासिफायर के निर्णय क्षेत्र से संबंधित है?
मैं प्लॉट_ट्री और प्लॉट_पार्टियल_डिपेंडेंस को sklearn.plot पर ले जाना पसंद करता हूं और
हल #13335 https://github.com/scikit-learn/scikit-learn/issues/13335
0.21 में (शायद निर्णय सीमा को प्लॉट करने के लिए एक फ़ंक्शन पेश करें, क्योंकि
शुरुआती आईएमओ के लिए यह महत्वपूर्ण और आसान नहीं है)। दूसरे क्या सोचते हैं?

sklearn.plot के दायरे को नियंत्रित करने में मदद करने के लिए, मेरा प्रस्ताव है कि हम केवल प्लॉटिंग करें
कुल्हाड़ियों के स्तर पर और आंकड़ा स्तर पर नहीं। उपयोगकर्ता कुल्हाड़ियों में गुजरेगा
एक कीवर्ड के रूप में। सुविधा के रूप में, कुल्हाड़ियों का डिफ़ॉल्ट कोई नहीं होगा। में केवल
इस मामले में, क्या प्लॉटिंग फ़ंक्शन प्लॉट करने के लिए एक अक्ष/आंकड़ा उत्पन्न करेगा।

अच्छा विचार है, लेकिन मौजूदा कार्यों के अनुरूप नहीं है (प्लॉट_ट्री और
प्लॉट_पार्टियल_डिपेंडेंस), है ना?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

अच्छा विचार है, लेकिन मौजूदा कार्यों (प्लॉट_ट्री और प्लॉट_पार्टियल_डिपेंडेंस) के अनुरूप नहीं है, है ना?

@qinhanmin2014 plot_tree इस आंकड़े को समायोजित नहीं कर रहा है। plot_partial_dependence features आधार पर कई प्लॉट बनाता है। हालांकि, इसे कुल्हाड़ियों के स्तर की साजिश में दोबारा किया जा सकता है। एक उपयोगकर्ता को अलग-अलग कुल्हाड़ियों (और सुविधाओं) को देते हुए कई बार plot_partial_dependence पर कॉल करने की आवश्यकता होगी।

क्या आप कारण बता सकते हैं कि आप इसे कुल्हाड़ियों तक सीमित क्यों रखना चाहते हैं?

@jnothman Seaborn के पास प्रलेखन है जो स्पष्ट रूप से "आंकड़ा-स्तर" भूखंड और "अक्ष-स्तर" भूखंडों को अलग करता है। अगर हम इस व्यवहार को स्किकिट-लर्न में ठीक से दस्तावेज कर सकते हैं, तो इन "आंकड़ा-स्तर" भूखंडों का होना संभव है। "आंकड़ा-स्तर" भूखंडों के साथ मेरी सबसे बड़ी चिंता यह है कि उन्हें बनाए रखना और परीक्षण करना कठिन होता है। एक अक्ष से ऐसे तत्व होंगे जो दूसरी कुल्हाड़ियों के साथ ओवरलैप हो सकते हैं। हालांकि, हम आंकड़ों को इस तरह से संरचित करके इसके आसपास काम कर सकते हैं कि ओवरलैपिंग कम बार होती है।

परीक्षण के संदर्भ में, हम सीबॉर्न के रास्ते पर जा सकते हैं और सीधे matplotlib ऑब्जेक्ट्स या येलोब्रिक तरीके से परीक्षण कर सकते हैं जहाँ हम पिक्सेल स्तर का परीक्षण करते हैं। मैं matplotlib ऑब्जेक्ट्स के परीक्षण का पक्ष लेता हूं।

मेरे 2 सेंट:

• एक सामान्य उपपैकेज में matplotlib तक पहुँचने वाले कार्यों को शामिल करने के लिए +1, या, प्रत्येक उपपैकेज में एक मॉड्यूल पर (sklearn.linear_models.plot, sklearn.ensemble.plot)।

• जैसा कि @thomasjpfan द्वारा उल्लेख किया गया है, केवल कुल्हाड़ियों तक पहुँचने से परीक्षण करना आसान हो जाता है।

  इसके अलावा, बहुत समय पहले, पारिस्थितिकी तंत्र में अन्य प्लॉटिंग बैकएंड को संगतता के लिए "एक्सिस" जैसी वस्तु देने के लिए चर्चा हुई थी। मुझे नहीं पता कि यह कहां गया। एक त्वरित गूगलिंग ज्यादा नहीं दिखाता है। निकटतम है प्लॉटली.टूल्स.mpl_to_plotly, जिसे वास्तव में इस प्रतिबंध की आवश्यकता नहीं है, इसलिए मुझे लगता है कि तर्क व्यर्थ है।

शायद निर्णय सीमा को प्लॉट करने के लिए एक फ़ंक्शन पेश करें, क्योंकि यह महत्वपूर्ण है और शुरुआती आईएमओ के लिए आसान नहीं है

मैं सहमत हूं लेकिन मुझे यह भी लगता है कि उपयोगकर्ताओं को यह दिखाना कि निर्णय सीमाओं जैसे परिणामों को कैसे प्लॉट करना है, उदाहरणों के लक्ष्यों में से एक है।

यदि मुझे परिणाम का एक त्वरित पहला प्लॉट चाहिए, तो प्लॉटिंग फ़ंक्शन बहुत अच्छे हैं, विशेष रूप से एक पेड़ की साजिश रचने जैसे जटिल भूखंडों के लिए, लेकिन मैं अक्सर अपनी आवश्यकताओं के अनुसार प्लॉट को बदलना पसंद करता हूं और इस कारण से मैं मौजूदा उदाहरणों पर भरोसा करना पसंद करता हूं और कोड को संशोधित करें।

मॉड्यूल के नाम के संबंध में, IMO inspect से अधिक बहुमुखी है plot :

• मैं किसी ऐसे प्लॉट के बारे में नहीं सोच सकता जो किसी तरह का निरीक्षण न हो
• #12599 (आंशिक निर्भरता) पहले से ही inspect

प्लॉट की तुलना में IMO निरीक्षण अधिक बहुमुखी है

कोई मजबूत राय नहीं, दोनों नामों के लिए +1 वोट करेंगे। शायद कथानक अधिक सीधा है?

फिर से मैं 0.21 से पहले नया मॉड्यूल बनाने में दिलचस्पी रखता हूं और वहां प्लॉट_ट्री और प्लॉट_पार्टियल_डिपेंडेंस को स्थानांतरित करता हूं। आदर्श रूप से हमें एपीआई पर भी आम सहमति तक पहुंचना चाहिए (उदाहरण के लिए, अक्ष स्तर/आंकड़ा स्तर)।

inspect पक्ष में अन्य बिंदु:

हम ऐसे टूल का निरीक्षण करना चाहते हैं जो एक विकल्प के रूप में प्लॉटिंग की पेशकश करते हैं। उदाहरण के लिए, एक पेड़ की विशेषताओं (नोड्स, पत्तियों, विभाजन बिंदुओं, आदि की संख्या) को प्रिंट करें और वैकल्पिक रूप से इसे matplotlib के साथ प्लॉट करें।

जैसा कि सुझाव दिया गया है, मैं आंकड़ों के बजाय कुल्हाड़ियों का उपयोग करने के पक्ष में हूं (आह, मुझे फिर से पीडीपी बदलने की आवश्यकता होगी)। हमारे लिए समर्थन और परीक्षण करना आसान है। यह उपयोगकर्ताओं के लिए थोड़ा अधिक काम है, लेकिन यह अधिक नियंत्रण की भी अनुमति देता है।

प्लॉट की तुलना में IMO निरीक्षण अधिक बहुमुखी है

कोई मजबूत राय नहीं, दोनों नामों के लिए +1 वोट करेंगे। शायद कथानक अधिक सीधा है?

"निरीक्षण" पायथन में लोड किया गया है (यह मानक पुस्तकालय में एक मॉड्यूल है)। मैं
एक ही नाम का प्रयोग करने से बचेंगे।

फिर से मैं 0.21 से पहले नया मॉड्यूल बनाने में दिलचस्पी रखता हूं और वहां प्लॉट_ट्री और प्लॉट_पार्टियल_डिपेंडेंस को स्थानांतरित करता हूं। आदर्श रूप से हमें एपीआई पर भी आम सहमति तक पहुंचना चाहिए (उदाहरण के लिए, अक्ष स्तर/आंकड़ा स्तर)।

इसमें 0.21 की देरी नहीं होनी चाहिए। हमारा लक्ष्य जल्दी रिलीज करना है, और उम्मीद है
फिर से जल्दी रिलीज।

"निरीक्षण" पायथन में लोड किया गया है (यह मानक पुस्तकालय में एक मॉड्यूल है)। मैं
एक ही नाम का प्रयोग करने से बचेंगे।

मैं model_inspection का प्रस्ताव करता हूं। यह हमारे model_selection नाम के साथ अच्छी तरह से चला जाता है।

हम कुछ ऐसा निरीक्षण करना चाहते हैं जो मॉडल नहीं है (एनकोडर, प्रीप्रोसेसर, ग्रिड खोज परिणाम ...)

inspection ?

वे चीजें भी मॉडल हैं :)

प्रत्येक उप-पैकेज पर सार्वजनिक प्लॉट सबमॉड्यूल के गेल के सुझाव के लायक है
मानते हुए।

एफडब्ल्यूआईडब्ल्यू, मैं plot से inspect भी पसंद करूंगा, क्योंकि अधिकांश उपयोगकर्ताओं के लिए इसे ढूंढना अधिक सहज है। लोग अपने मॉडलों की _निरीक्षण_ की तुलना में अपने मॉडलों को _प्लॉट_ करने की अधिक संभावना रखते हैं (उदाहरण के लिए खोज इंजन पर खोज करते समय, या अपने आईडीई पर संभावित स्वत: पूर्ण विकल्पों को देखते हुए)।

प्रत्येक उप-पैकेज पर एक सार्वजनिक प्लॉट सबमॉड्यूल का गेल का सुझाव विचार करने योग्य है।

यदि हां, तो हम कहां रखेंगे plot_decision_boundary ?

#12599 के संबंध में, @NicolasHug मुझे संदेह है कि partial_dependence नए मॉड्यूल में होना चाहिए या नहीं। (यानी, पहनावा। आंशिक_निर्भरता + प्लॉट। प्लॉट_पार्टियल_निर्भरता)

यदि हां, तो हम प्लॉट_डिसीजन_बाउंड्री कहां रखेंगे?

sklearn.प्लॉट ?

मैं इस समाधान के लिए बहुत अधिक जोर नहीं देना चाहता। हालाँकि, मैं सहमत हूँ
यह महसूस करना कि अंतिम उपयोगकर्ताओं के लिए "प्लॉट" खोजना आसान हो सकता है।

# 12,599 के बारे में, @NicolasHug मैं संदेह partial_dependence नया मॉड्यूल में होना चाहिए या नहीं। (यानी, पहनावा। आंशिक_निर्भरता + प्लॉट। प्लॉट_पार्टियल_निर्भरता)

मुझे समझ नहीं आ रहा है कि आपका क्या मतलब है। #12599 ensemble.partial_dependence को inspect.partial_dependence पक्ष में हटा देता है (बेशक inspect इस चर्चा के आधार पर परिवर्तन के अधीन है)। एपीआई 2 कार्यान्वयनों के बीच भी भिन्न है।

मैं plot साथ ठीक हूं, मैं केवल एक संभावित उच्च ओवरलैप के बारे में चिंतित हूं जो एक अंतिम निरीक्षण मॉड्यूल के साथ है, लेकिन मैं इसे और आगे नहीं बढ़ाऊंगा :)

प्रत्येक उप-पैकेज पर एक सार्वजनिक प्लॉट सबमॉड्यूल विचार करने योग्य है।

लेकिन अभी तक प्रस्तावित सभी प्लॉटिंग टूल (पीडीपी, कैलिब्रेशन, कन्फ्यूजन मैट्रिक्स और डिसीजन रीजन) एक मॉड्यूल के लिए विशिष्ट नहीं हैं।

मुझे समझ नहीं आ रहा है कि आपका क्या मतलब है। #12599 निरीक्षण के पक्ष में पहनावा। आंशिक_निर्भरता को दर्शाता है। आंशिक_निर्भरता (बेशक निरीक्षण इस चर्चा के आधार पर परिवर्तन के अधीन है)। एपीआई 2 कार्यान्वयनों के बीच भी भिन्न है।

क्षमा करें मैंने उस पीआर को विस्तार से नहीं देखा है। शायद inspect.partial_dependence + plot.plot_partial_dependence ?

हो सकता है कि निरीक्षण करें। आंशिक_निर्भरता + प्लॉट। प्लॉट_पार्टियल_डिपेंडेंस?

मुझे मूल्यों की गणना करने और इसकी साजिश रचने के बीच एक स्पष्ट अलगाव पसंद है।
यह अलगाव की तरह एक मॉडल/दृश्य है, और इसे बढ़ाने में मदद करनी चाहिए
पुन: प्रयोज्य।

क्या गेल पहले sklearn.inspect.partial_निर्भरता का प्रस्ताव नहीं दे रहे थे?
sklearn.inspect.plot.plot_partial_निर्भरता (किसी अन्य नाम को प्रतिस्थापित करें
निरीक्षण के लिए यदि उपयुक्त हो)? मुझे इस बात से ऐतराज नहीं है।

क्या गेल पहले sklearn.inspect.partial_निर्भरता और sklearn.inspect.plot.plot_partial_निर्भरता का प्रस्ताव नहीं दे रहे थे (यदि उपयुक्त हो तो निरीक्षण के लिए किसी अन्य नाम को प्रतिस्थापित करें)?

हां, लेकिन मैंने उससे पूछा कि हम plot_decision_boundary कहां रखेंगे और ऐसा लगता है कि उसने अपना मन बदल लिया है?

FYI करें, मैंने उपरोक्त अनुशंसाओं का पालन करते हुए PDP PR https://github.com/scikit-learn/scikit-learn/pull/12599 को अपडेट किया है:

• partial_dependence sklearn.model_inspection
• plot_partial_dependence skearn.plot

दस्तावेज़ यहाँ हैं https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

ध्यान दें कि उपयोगकर्ता मार्गदर्शिका में अभी के लिए केवल plot मॉड्यूल शामिल है। मुझे नहीं लगता कि यह एक उपयोगकर्ता गाइड अनुभाग है जो केवल model_inspection.partial_dependence बारे में बात करेगा, क्योंकि इसकी बाधाएं/व्यवहार plot_partial_dependence ।

(यह उस तरह का ओवरलैप है जिसके बारे में मुझे चिंता थी)

बेशक अगर आपको लगता है कि partial_dependence और plot_partial_dependence लिए अलग-अलग उपयोगकर्ता गाइड रखना अभी भी बेहतर है, तो मैं यह करूँगा।

FYI करें, मैंने उपरोक्त अनुशंसाओं के बाद PDP PR #12599 को अपडेट किया है:
आंशिक_निर्भरता sklearn.model_inspection में है
प्लॉट_पार्टियल_डिपेंडेंस searn.plot . में है

+1

ध्यान दें कि उपयोगकर्ता मार्गदर्शिका में अभी के लिए केवल प्लॉट मॉड्यूल शामिल है। मुझे नहीं लगता कि यह एक उपयोगकर्ता गाइड अनुभाग है जो केवल model_inspection.partial_निर्भरता के बारे में बात करेगा, क्योंकि इसकी बाधाएं/व्यवहार प्लॉट_पार्टियल_निर्भरता के समान है।

+1

तो हमने sklearn.plot नाम का उपयोग करने का निर्णय लिया है?

मुझे sklearn.plot sklearn से निर्भरता आयात करना थोड़ा अजीब लगता है जब हमने सभी को रूट नेमस्पेस में डालने से परहेज किया है।

तो आप sklearn.model_inspection.plot पसंद करेंगे और वहां plot_partial_dependence() डालेंगे?

नहीं plot मॉड्यूल, मैं इसके साथ ठीक हूँ

मुझे लगता है कि मैं इसे पसंद करूंगा। अभी तक निश्चित नहीं है कि यह कैसे सामान्यीकरण करता है।

मुझे लगता है कि मैं इसे पसंद करूंगा। अभी तक निश्चित नहीं है कि यह कैसे सामान्यीकरण करता है।

जब तक हम plot_decision_boundary जैसी चीजों को रखने के लिए एक उपयुक्त स्थान का पता लगा सकते हैं, मैं sklearn.XXX.plot लिए +1 को वोट दूंगा।

क्या इसके लिए नींद की जरूरत है? ऐसा लगता है कि हम बहुत प्रगति नहीं कर रहे हैं

संपादित करें उह, मुझे जोएल की टिप्पणी पढ़नी है क्योंकि मुझे नहीं लगता कि मैं इसे पसंद करूंगा , क्षमा करें

क्या इसके लिए नींद की जरूरत है? ऐसा लगता है कि हम बहुत प्रगति नहीं कर रहे हैं

मैं किसी भी समाधान के साथ ठीक हूं ( sklearn.plot / sklearn.XXX.plot )। यहां मुख्य मुद्दा आईएमओ यह है कि कोई मुझे नहीं बताता कि हम plot_decision_boundary जैसी चीजें कहां रखेंगे यदि हम sklearn.XXX.plot :)

sklearn.model_inspection.plot ?

sklearn.model_inspection.plot?

दिलचस्प विचार, मैं +1 वोट दूंगा। हो सकता है कि सभी चीजों को sklearn.plot पर फेंकना इतना अच्छा नहीं है (https://github.com/rasbt/mlxtend सभी प्लॉटिंग फ़ंक्शंस को एक ही मॉड्यूल में रखें)।

तो हम from sklearn.XXX.plot import plot_XXX समर्थन करेंगे? क्या हम from sklearn.XXX import plot_XXX समर्थन करेंगे?

मुझे लगता है कि आयात में .plot की स्पष्ट आवश्यकता कुछ है
दूसरों ने यहां मांगा है।

Sklearn.plot.XXX से उलटा भी है, import plot_YYY

मुझे लगता है कि आयात में .plot की स्पष्ट आवश्यकता कुछ अन्य लोगों ने यहां मांगी है।

तो हम sklearn.XXX.plot (केवल sklearn.XXX.plot आयात plot_XXX से समर्थन) का उपयोग करने के लिए आम सहमति पर पहुंच गए हैं?

Sklearn.plot.XXX से उलटा भी है, import plot_YYY

मैं नहीं समझ सकता।

Sklearn.plot.XXX से उलटा भी है, import plot_YYY

मेरा मतलब था कि हमारे पास हो सकता है
sklearn.plot.model_inspection.plot_partial_निर्भरता के बजाय
sklearn.model_inspection.plot.plot_partial_निर्भरता। यकीन नहीं होता अगर यह
कोई लाभ/स्पष्टता प्रदान करता है।

मेरा मतलब था कि हमारे पास हो सकता है
sklearn.plot.model_inspection.plot_partial_निर्भरता के बजाय
sklearn.model_inspection.plot.plot_partial_निर्भरता। यकीन नहीं होता अगर यह
कोई लाभ/स्पष्टता प्रदान करता है।

तो अब हमारे पास 3 विकल्प हैं:
(1) sklearn.plot.plot_YYY (जैसे, sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (जैसे, sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (जैसे, sklearn.tree.plot.plot_tree, sklearn से समर्थन नहीं करते। XXX आयात प्लॉट_YYY)
मैं इन सभी समाधानों के लिए +1 को वोट दूंगा।
मैं sklearn.tree.plot_tree . को पदावनत करने से बचने के लिए 0.21 से पहले निर्णय लेना पसंद करता हूं

सुनिश्चित नहीं है कि इसे एक नींद की जरूरत है, लेकिन इस पर राय आमंत्रित करने लायक हो सकता है
मेलिंग सूची

सुनिश्चित नहीं है कि इसे नींद की जरूरत है लेकिन मेलिंग सूची पर राय आमंत्रित करने लायक हो सकता है

+1। ऐसा लगता है कि यह एसएलईपी के मानदंडों में नहीं आता है।

जैसा कि मैंने मेलिंग सूची में कहा था, मुझे लगता है कि हमें वास्तव में "जहां काम होता है" या इंटरफ़ेस कैसा होगा, इस पर भी विचार करना चाहिए। आंशिक निर्भरता के लिए यह पहले से ही काफी अस्पष्ट था।
क्या plot_partial_dependence को partial_dependence plot_partial_dependence कॉल करना चाहिए या इनपुट के रूप में partial_dependence का आउटपुट प्राप्त करना चाहिए? यह प्रश्न मूल रूप से सभी प्लॉट फ़ंक्शंस के लिए एक मान्य प्रश्न है।
मुख्य विचार मैं @NicolasHug के साथ चर्चा करता हूं कि plot_X कॉल compute_X उपयोगकर्ता के लिए सुविधाजनक है - जब तक वे केवल एक बार चीज़ को प्लॉट करना चाहते हैं। अगर उन्हें प्लॉट पसंद नहीं है और वे कुछ बदलना चाहते हैं, तो उन्हें फिर से compute_X जरूरत है, जो संभावित रूप से बेकार है।

तो हम या तो कर सकते थे

• हमेशा compute_X का परिणाम लें। डाउनसाइड: असुविधाजनक और त्रुटि-प्रवण: सटीक_रिकॉल_कर्व में फिर से सटीक, रिकॉल और थ्रेसहोल्ड का क्रम क्या था?

• हमेशा इनपुट को compute_X और compute_X से plot_X कॉल करें। नकारात्मक पक्ष: आपको प्रत्येक भूखंड के लिए पुनर्गणना करने की आवश्यकता है।

• दोनों की अनुमति देते हैं, तो plot_X या तो के लिए इनपुट ले जा सकते हैं compute_X करने के लिए और कॉल compute_X या के उत्पादन में ले compute_X उपयोगकर्ता पहले से ही यह बनाया है। इसमें हस्ताक्षर को जटिल बनाने का नकारात्मक पक्ष है (और संभवतः इसे दस्तावेज करना जटिल करता है)। साथ ही, यदि उपयोगकर्ता plot_X कॉल करता है ताकि वह आंतरिक रूप से compute_X और फिर एक और प्लॉट चाहता है, तो उसे फिर से compute_X आवश्यकता होगी। इसलिए आपको पहली बार plot_X कॉल करने से पहले यह अनुमान लगाना होगा कि आप एक से अधिक प्लॉट चाहते हैं। या आपको कॉल करते समय compute_X के परिणाम को उजागर करने की आवश्यकता है plot_X , लेकिन यह मेरे लिए स्पष्ट नहीं है कि बिना ऑब्जेक्ट ओरिएंटेड डिज़ाइन के इसे कैसे किया जाए

• कंप्यूट_एक्स कितना महंगा है, इसके आधार पर निर्णय लें, क्योंकि भ्रम मैट्रिक्स और आंशिक निर्भरता भूखंडों और अंशांकन भूखंडों के लिए हम पुनर्गणना की लागत की परवाह नहीं करते हैं, लेकिन आंशिक निर्भरता भूखंडों के लिए हम करते हैं। नकारात्मक पक्ष: असंगत इंटरफ़ेस।

जब तक वे केवल एक बार बात प्लॉट करने के लिए चाहते हैं - मुख्य विचार मैं @NicolasHug साथ चर्चा करता है कि plot_X कॉल compute_X होने उपयोगकर्ता के लिए सुविधाजनक है। अगर उन्हें प्लॉट पसंद नहीं है और वे कुछ बदलना चाहते हैं, तो उन्हें फिर से कंप्यूट_एक्स करना होगा, जो संभावित रूप से बेकार है।

+1000. यह एक सामान्य समस्या है जिसे मैं शोध कोड में देखता हूं।

एक डिजाइन समस्या से, यह एक एमवीसी अलगाव का उल्लंघन करता है (थोड़ा पांडित्य,
माफ़ करना)।

आपके द्वारा प्रस्तावित विभिन्न समाधानों में, क्या आप एक लेने पर विचार करेंगे?
एक दृष्टिकोण के रूप में फिट मॉडल? मुझे लगता है कि यह की समस्या को कम करेगा
मापदंडों के क्रम को याद रखना। लेकिन शायद अतिरिक्त हैं
समस्या।

मुझे यकीन नहीं है कि फिट मॉडल से आपका क्या मतलब है। अक्सर गणना का आउटपुट फिटेड मॉडल नहीं होता है। हम सभी गणना परिणामों के लिए वस्तुओं को परिभाषित कर सकते हैं, ताकि partial_dependence एक PartialDependence वस्तु लौटाए। या एक गुच्छा। लेकिन यह एक अनुमानक नहीं लौटाता है।

ओह इसका कारण मैं इसे अभी लाता हूं: इस निर्णय के बिना मुझे नहीं पता कि उपयोगकर्ता कोड कैसा दिखेगा, और मुझे उदाहरण लिखने में सक्षम होने के बिना नामकरण/एपीआई निर्णय लेना पसंद नहीं है;)

किसी ऑब्जेक्ट को वापस करना बहुत ही अन-स्केलर्न जैसा होगा, इम्हो। लेकिन यह स्थान की समस्या को हल कर सकता है: इसमें plot तरीके हो सकते हैं;)

अक्सर गणना का आउटपुट फिटेड मॉडल नहीं होता है। हम सभी गणना परिणामों के लिए वस्तुओं को परिभाषित कर सकते हैं, ताकि आंशिक_निर्भरता एक आंशिक निर्भरता वस्तु लौटाए। या एक गुच्छा। लेकिन यह एक अनुमानक नहीं लौटाता है।

मुद्दा लेना।

एक विकल्प (यह नहीं कहना कि यह सबसे अच्छा है) सभी का होना होगा
कंप्यूट फ़ंक्शन नाम टुपल्स और सभी संबंधित कंप्यूट लौटाते हैं
कार्य इसे लेते हैं। यह कुछ हद तक आधुनिक . के अनुरूप होगा
पायथन मानक पुस्तकालय के अतिरिक्त।

और मुझे उदाहरण लिखने में सक्षम हुए बिना नामकरण/एपीआई निर्णय लेना पसंद नहीं है;)

मैं आप की तरह हूँ।

इसलिए यदि गणना महंगी है, तो हम फ़ंक्शन के बाहर गणना कर सकते हैं। यदि हां, तो हम एक ऑब्जेक्ट लौटाते हैं और प्लॉटिंग फ़ंक्शन इस ऑब्जेक्ट को इसके इनपुट के रूप में लेता है, है ना? मैं +1 वोट करूंगा।

और शायद हमें इस पर चर्चा करने के लिए एक और मुद्दे की जरूरत है :)

@GaelVaroquaux के सुझाव का लाभ यह है कि टपल confusion_matrix जैसी कोई भी लौटाई गई वस्तु है। वहां एक टुपल सख्ती से जरूरी नहीं होगा लेकिन फिर इंटरफ़ेस थोड़ा असंगत हो जाता है।

@ qinhanmin2014 अगर हम मनमानी वस्तुओं को वापस करते हैं तो हमें हर बार जब हम एक प्लॉटिंग हेल्पर बनाते हैं तो हमें किसी फ़ंक्शन के लिए रिटर्न प्रकार को बहिष्कृत करना पड़ता है। ऐसा लगता है कि एक गड़बड़ है।

मेरे पास एक विचार था, और फिर दूसरा बेहतर विचार:
1) एक दूसरा, ऑब्जेक्ट-ओरिएंटेड इंटरफ़ेस बनाएं जो मौजूदा फ़ंक्शन को कॉल करता है, ऑब्जेक्ट को स्टोर करता है, और एक प्लॉट विधि है, जैसे

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

यह समस्या का समाधान करेगा, लेकिन कुछ इंटरफ़ेस की नकल करेगा और यह थोड़ा अस्पष्ट होगा। असल में वही सिद्धांत इस तरह से किया जा सकता है जो मुझे लगता है कि अधिक सहज ज्ञान युक्त है:
2) plot_ फ़ंक्शन हमेशा काम करता है, परिणाम का उपयोग उस ऑब्जेक्ट को तुरंत करने के लिए करें जो परिणाम संग्रहीत करता है और इसे प्लॉट करता है:

plot_confusion_matrix(y, y_pred)

इसके लिए बस प्लॉट होगा, और एक ConfusionMatrixPlotter ऑब्जेक्ट लौटाएगा, जो परिणाम संग्रहीत करता है, और इसमें plot विधि है।
तो सिर्फ एक बार साजिश रचने के साधारण मामले में, यह सिर्फ एक ही फ़ंक्शन कॉल है। यदि आप परिणाम इसके साथ कुछ और करना चाहते हैं, तो वे ऑब्जेक्ट में संग्रहीत होते हैं। यदि आप फिर से प्लॉट करना चाहते हैं, तो आप ऑब्जेक्ट पर फिर से plot पर कॉल कर सकते हैं। यदि आप पहले ही परिणामों की गणना कर चुके हैं और फिर तय करते हैं कि आप प्लॉट करना चाहते हैं, तो आप सीधे ConfusionMatrixPlotter तुरंत चालू कर सकते हैं।

हालांकि यह अधिक जटिल उपयोग-मामलों के लिए एक अतिरिक्त वर्ग को उजागर करता है, मुझे लगता है कि यह एक उचित व्यापार-बंद है क्योंकि इसमें सभी स्थितियों का अच्छा जवाब है।

इसके लिए केवल प्लॉट होगा, और एक कन्फ्यूजनमैट्रिक्सप्लॉटर ऑब्जेक्ट लौटाएगा, जो परिणाम संग्रहीत करता है, और इसमें प्लॉट विधि होती है।

उपयोगकर्ताओं को उसी डेटा को फिर से प्लॉट करने की आवश्यकता क्यों है? @amueller प्रारूप को समायोजित करें?

@ qinhanmin2014 हाँ, फ़ॉन्ट को बड़ा करें, रंग बदलें, इसे एक ही प्लॉट में किसी और चीज़ के साथ प्लॉट करें, लेबल जोड़ें, ...

@ qinhanmin2014 हाँ, फ़ॉन्ट को बड़ा करें, रंग बदलें, इसे एक ही प्लॉट में किसी और चीज़ के साथ प्लॉट करें, लेबल जोड़ें, ...

मुझे संदेह है कि यहां इन स्वरूपण मुद्दों पर विचार करना उचित है या नहीं। उपयोगकर्ता शुरू कर सकते हैं डेटासेट का एक छोटा सा हिस्सा होगा?

और @amueller हम पासिंग कुल्हाड़ियों का समर्थन करेंगे, ताकि उपयोगकर्ता प्लॉटिंग फ़ंक्शन को कॉल करने के बाद प्लॉट को आसानी से समायोजित कर सकें?

@ qinhanmin2014 नहीं, बाद में कई चीजें आसानी से नहीं बदली जा सकतीं, और हमें सभी स्वरूपण के बारे में सोचने की ज़रूरत नहीं है, लेकिन हमें उपयोगकर्ताओं को फिर से कुछ प्लॉट करने की अनुमति देनी चाहिए। यह मूल रूप से तब होगा जब आप कोई प्लॉट करेंगे। और हर बार जब मैं कोई प्लॉट करना चाहता हूं तो डेटासेट को सब्सक्राइब करना थोड़ा कष्टप्रद होता है। और अगर मैं बाद में अपना विचार बदलता हूं तो भी मुझे फिर से गणना करने की आवश्यकता होगी।
मूल रूप से मुद्दा यह है कि आप आमतौर पर यह अनुमान नहीं लगा सकते हैं कि आप अपने खोजपूर्ण विश्लेषण में वास्तव में क्या चाहते हैं, और विज़ुअलाइज़ेशन को बदलने के लिए सब कुछ पुनर्गणना करना बहुत अच्छा नहीं लगता है।

@ qinhanmin2014 नहीं, बाद में कई चीजें आसानी से नहीं बदली जा सकतीं, और हमें सभी स्वरूपण के बारे में सोचने की ज़रूरत नहीं है, लेकिन हमें उपयोगकर्ताओं को फिर से कुछ प्लॉट करने की अनुमति देनी चाहिए। यह मूल रूप से तब होगा जब आप कोई प्लॉट करेंगे। और हर बार जब मैं कोई प्लॉट करना चाहता हूं तो डेटासेट को सब्सक्राइब करना थोड़ा कष्टप्रद होता है। और अगर मैं बाद में अपना विचार बदलता हूं तो भी मुझे फिर से गणना करने की आवश्यकता होगी।

हां, मुझे पता है कि यह उपयोगी हो सकता है, लेकिन यहां मुख्य मुद्दा यह है कि हमारे पास इस कार्यक्षमता का समर्थन करने का एक साफ तरीका नहीं है, और मुझे लगता है कि अधिकांश प्लॉटिंग कार्यों में अधिक गणना की आवश्यकता नहीं होती है?

मुझे यह पसंद है कि हम इस पर थोड़ी और ग्राउंडिंग के साथ चर्चा कर रहे हैं, लेकिन मैं हूँ
अभी भी पूरी तरह से आश्वस्त नहीं हैं कि हमें आयात में भूखंड की भी आवश्यकता है
पथ बिल्कुल। आखिरकार, हमें लगता है कि प्लॉट_ के लिए उपसर्ग के रूप में है
कार्य। यह प्रश्न भी प्लॉट_ट्री से संबंधित है: यह क्यों होना चाहिए
अन्य निर्यात और टेक्स्ट विज़ुअलाइज़ेशन कोड से अलग?

@ qinhanmin2014 मुझे नहीं लगता कि "हमारे पास अभी तक एक अच्छा एपीआई नहीं है" एक अच्छा कारण है।
और आंशिक निर्भरता, क्रमपरिवर्तन महत्व, सीखने की अवस्था, सत्यापन वक्र और GridSearchCV और RandomizedSearchCV के परिणाम सभी सामान्य उदाहरण हैं जो बहुत अधिक गणना करते हैं। हालांकि gridsearchcv और randomizedsearchcv के लिए स्पष्ट बात यह होगी कि ऑब्जेक्ट या cv_results_ , उन मामलों में प्लॉटिंग फ़ंक्शन के अंदर काम करना निरर्थक लगता है। मैं वक्र और सत्यापन वक्र tbh सीखने के बारे में पूरी तरह से निश्चित नहीं हूं।

@jnothman मुझे लगता है कि @GaelVaroquaux matplotlib निर्भरता को एक मॉड्यूल तक सीमित रखना चाहता था और यह मुख्य प्रेरणाओं में से एक था? मेरे पास अभी तक इस बारे में बहुत सुसंगत विचार नहीं हैं।

और आंशिक निर्भरता, क्रमपरिवर्तन महत्व, सीखने की अवस्था, सत्यापन वक्र और GridSearchCV और RandomizedSearchCV के परिणाम सभी सामान्य उदाहरण हैं जो बहुत अधिक गणना करते हैं।

धन्यवाद, अब मुझे एहसास हुआ कि मैं गलत हूँ :)
हालांकि मैं अभी भी यह समझने में असमर्थ हूं कि उपयोगकर्ताओं को बिना पुनर्गणना के प्लॉट करने का तरीका प्रदान करना क्यों महत्वपूर्ण है। लेकिन अगर दूसरे ऐसा सोचते हैं और कोई अच्छा तरीका है, तो मैं +1 को वोट दूंगा।

मुझे यह पसंद है कि हम इस पर थोड़ी और ग्राउंडिंग के साथ चर्चा कर रहे हैं, लेकिन मैं हूँ
अभी भी पूरी तरह से आश्वस्त नहीं हैं कि हमें आयात में भूखंड की भी आवश्यकता है
पथ बिल्कुल। आखिरकार, हमें लगता है कि प्लॉट_ के लिए उपसर्ग के रूप में है
कार्य। यह प्रश्न भी प्लॉट_ट्री से संबंधित है: यह क्यों होना चाहिए
अन्य निर्यात और टेक्स्ट विज़ुअलाइज़ेशन कोड से अलग?

हाँ यह भी एक विकल्प हो सकता है। यदि ऐसा है, तो हम उल्लेख कर सकते हैं कि plot_ शुरू होने वाले सभी कार्यों के लिए matplotlib की आवश्यकता होती है। इस विकल्प का एक अन्य लाभ यह है कि हमें मौजूदा कार्यों को स्थानांतरित करने की आवश्यकता नहीं है।

इस चर्चा को देखते हुए, मैं sklearn.plot मॉड्यूल नहीं जोड़ने से सहमत हूं, और matplotlib आवश्यकता को इंगित करने के लिए उपसर्ग plot_ का उपयोग करता हूं।

उदाहरण के लिए, https://github.com/scikit-learn/scikit-learn/pull/12599 में , partial_dependence और plot_partial_dependence को inspection में रखा जाएगा।

ठीक है, जब तक कि आने वाले दिनों में कोई इससे असहमत न हो, मैं पीडीपी पीआर को अपडेट करने जा रहा हूं और:

• partial_dependence और plot_partial_dependence को sklearn.inspection डालें
• plot_partial_dependence को विशेषताओं के रूप में fig और ax ऑब्जेक्ट्स के साथ एक गुच्छा लौटाएं (अभी यह उन्हें एक टुपल में लौटाता है)। इस तरह, जब हम https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520 से दूसरे विकल्प को लागू करते हैं, तो हम इन 2 कार्यों को पिछड़ा संगत रखने में सक्षम होंगे।

क्या हम यहां अंतिम निर्णय ले सकते हैं?
प्रस्ताव @jnothman द्वारा सहमति व्यक्त की, @NicolasHug और मुझे (क्षमा याचना अगर मैं गलत हूँ): sklearn.XXX.plot_YYY (sklearn.XXX आयात plot_YYY से समर्थन)। हम उल्लेख करेंगे कि प्लॉट_ से शुरू होने वाले सभी कार्यों के लिए matplotlib की आवश्यकता होती है।
इस प्रस्ताव का एक प्रमुख लाभ यह है कि हमें मौजूदा कार्यों को स्थानांतरित करने की आवश्यकता नहीं है।

इस पर सोते हुए मुझे लगता है कि यह समझाने में काफी आसान है और यह विभिन्न मॉड्यूल के बीच साझा प्लॉटिंग एपीआई के बारे में सोचने में कठिनाई से बचाता है।

हाँ, चलो ऐसा करते हैं। अधिक सहायक प्रदान करने के लिए एक सहायक कार्य करें
आयात त्रुटि

FYI करें, मैं #12599 . में sklearn.utils.check_matplotlib_support जोड़ रहा हूँ

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 करें, मैं #12599 . में sklearn.utils.check_matplotlib_support जोड़ रहा हूँ

एक दम बढ़िया! धन्यवाद।