Scikit-learn: CategoricalEncoder API पर फिर से विचार करना?

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

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

जोएल ने जो कहा उसके लिए +1

मेरे फोन से भेजा गया। कृपया टाइपो और संक्षिप्तता क्षमा करें।​

23 जनवरी 2018 को, 12:28, 12:28 बजे, जोएल नोथमैन नोटिफिकेशन @github.com ने लिखा:

CategoricalEncoder को वापस लाने का विचार मुझे काफी दुखी करता है, लेकिन I
सोच
आप सही कह रहे हैं कि भविष्य के उपयोगकर्ता विकल्प 2 से कम भ्रमित होंगे। My
मुख्य
चिंता की बात यह है कि हमने इसे OHE में बदलाव के रूप में लागू करने का प्रयास किया है
ए
लंबे समय तक और इसने कभी उड़ान नहीं भरी। शायद यह प्रयास करना अच्छा होगा
प्रस्तावित के अनुसार OneHotEncoder docstring में संशोधन
बदलें, तो हम देख सकते हैं कि क्या यह समझदार दिखता है।

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment -359761818

CategoricalEncoder को वापस लाने का विचार मुझे बहुत दुखी करता है

स्पष्ट होने के लिए, यह एक पूर्ववत नहीं होगा, यह एक रिफैक्टर/नाम बदलें जो सभी कार्यक्षमता रखता है!
लेकिन मुझे "CategoricalEncoder" नाम भी पसंद है, जो वास्तव में दुखद होगा।

उस ने कहा, मैं यह जानने के लिए जल्दी से परिवर्तन करने का प्रयास करूंगा कि इसे OnehotEncoder में एकीकृत करना कितना संभव है।

ठीक है, मैंने अवधारणा के प्रमाण के साथ एक पीआर खोला: https://github.com/scikit-learn/scikit-learn/pull/10523।
यह अभी तक पूरा नहीं हुआ है (पुराने व्यवहार में अभी तक कोई बहिष्करण चेतावनी और नई विशेषताओं की गणना नहीं की गई है)।

मुख्य एपीआई प्रश्न इनपुट डेटा के प्रारूप के बारे में है।
इसलिए संक्षेप में, दो अलग-अलग तरीके हैं जिनसे हम वर्तमान में श्रेणीबद्ध डेटा को संसाधित करते हैं :

1) वास्तविक के रूप में, अभी तक एन्कोड नहीं किया गया (पूर्णांक या स्ट्रिंग), श्रेणीबद्ध डेटा (यह कैसे किया जाता है CategoricalEncoder ) -> प्रशिक्षण डेटा में अद्वितीय मूल्यों से श्रेणियों का अनुमान लगाएं
2) पूर्णांक के रूप में, पहले से ही एन्कोडेड डेटा (यह वर्तमान OneHotEncoder में कैसे किया जाता है) -> प्रशिक्षण डेटा में अधिकतम मूल्य से श्रेणियों का अनुमान लगाएं

सवाल यह है कि क्या हम दोनों मामलों को समर्थन के लायक पाते हैं? इस प्रकार, संभावित रूप से मर्ज किए गए OneHotEncoder में, क्या हम दोनों को करने की क्षमता रखते हैं, या क्या हम पूरी तरह से पदावनत करते हैं और फिर क्रमिक इनपुट को संसाधित करने की क्षमता को हटा देते हैं?

यदि दोनों को संसाधित करने की क्षमता चाहते हैं, तो हम इनपुट डेटा प्रकार निर्दिष्ट करने के लिए एक बूलियन कीवर्ड जोड़ सकते हैं (अभी के लिए मैं encoded_input=False/True उपयोग करता हूं, लेकिन अन्य विचार ordinal_input , ...)

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

यह देखते हुए कि हम दोनों को संभालना चाहते हैं, एक सिंहावलोकन कि OneHotEncoder कैसे काम करेगा:

• अभी के लिए encoded_input=None , और हम डेटा के आधार पर डिफ़ॉल्ट का अनुमान लगाते हैं
• यदि int-like डेटा (OneHotEncoder द्वारा पहले संभाला जाता है) encoded_input आंतरिक रूप से True पर सेट है और एक बहिष्करण चेतावनी उठाई जाती है। यदि उपयोगकर्ता वर्तमान व्यवहार को बनाए रखना चाहता है, तो वह इसे मैन्युअल रूप से OneHotEncoder(encoded_input=True) रूप में निर्दिष्ट कर सकता है ताकि चेतावनी को शांत किया जा सके।
• यदि इनपुट इंट-लाइक नहीं है, तो हम encoded_input आंतरिक रूप से False पर सेट करते हैं और बिना किसी चेतावनी के नए व्यवहार का उपयोग करते हैं (= वर्तमान CategoricalEncoder व्यवहार)
• भविष्य में हम encoded_input डिफ़ॉल्ट को कोई नहीं से गलत में बदलते हैं (डिफ़ॉल्ट रूप से नया व्यवहार, इंट-लाइक डेटा के लिए भी)

मुझे अभी भी यकीन नहीं है कि आप जो सुझाव दे रहे हैं वह अधिकतम मूल्य से श्रेणियों का अनुमान लगाने के कारण व्यावहारिक अंतर है।

@jnothman मुझे लगता है कि आप स्वीकार करते हैं कि अभ्यास में अंतर हो सकता है? (आपके पास मौजूद डेटा के आधार पर आपको जो आउटपुट मिलता है)

लेकिन क्या यह अंतर व्यवहार में महत्वपूर्ण है, मुझे नहीं पता। वहीं मैं फीडबैक देखना चाहता हूं। क्या कोई वास्तव में यह "अधिकतम मूल्य"-आधारित विधि चाहता है , या क्या हम (भविष्य में, बहिष्करण के बाद) केवल "अद्वितीय मान"-आधारित पद्धति के साथ ठीक हैं।

मुझे लगता है कि मुझे व्यक्तिगत रूप से इस अधिकतम-मूल्य आधारित पद्धति की कभी आवश्यकता नहीं होगी, लेकिन OneHotEncoder कई वर्षों से ऐसा ही है (अच्छे कारण के लिए या नहीं?)

असल में अधिकतम-मूल्य आधारित वर्गीकरण को बहिष्कृत करना निश्चित रूप से कार्यान्वयन (बहिष्करण के बाद) को आसान बना देगा।
और यदि हम उस मार्ग के लिए चुनते हैं, तो मैं मानता हूँ विकल्प नहीं बल्कि होना चाहिए legacy_mode=True/False बजाय encoded_input / ordinal_input

मुझे याद दिलाएं कि आउटपुट में वास्तविक अंतर क्या है, जब n_values='auto',
कृपया? मैंने सोचा था कि active_features_ चीज़ ने उन्हें मूल रूप से बनाया है
समान, लेकिन मैं शायद कुछ भूल रहा हूँ।

आह, यह हमारी गलतफहमी को स्पष्ट करता है :-)
मैंने गलत समझा कि वर्तमान OneHotEncoder वास्तव में कैसे काम कर रहा है। मान लीजिए कि आपके पास मूल्यों के साथ एक विशेषता है [2, 3, 5, 2]। मैंने सोचा था कि वर्तमान OneHotEncoder में श्रेणियां [0, 1, 2, 3, 4, 5] होंगी (जबकि वर्तमान CategoricalEncoder में श्रेणियां [2, 3, 5] होंगी)। लेकिन आप सही हैं कि active_features_ भी केवल [2, 3, 5] है, अनिवार्य रूप से उन्हें n_values='auto' के डिफ़ॉल्ट मान के साथ समान बना रहा है।

तो यह केवल वह मामला है जहां आप निर्दिष्ट करने के लिए n_values (जैसे श्रेणियों के लिए n_values=6 = [0, 1, 2, 3, 4, 5] के लिए एक पूर्णांक पास करते हैं) श्रेणियों की संख्या जो वास्तव में एक एपीआई परिवर्तन होगी (बहिष्कृत / हटा दी गई)।
और वह categories=range(6) . के साथ उपयोगकर्ता द्वारा आसानी से बदला जा सकेगा

गलतफहमी के लिए खेद है।
उस प्रकाश में, मुझे लगता है कि हमें legacy_mode विकल्प की भी आवश्यकता नहीं है। हम आंतरिक रूप से n_values=6 से categories=range(6) अनुवाद कर सकते हैं और इसके लिए चेतावनी दे सकते हैं (लेकिन वास्तविक परीक्षणों के साथ इसे जांचने की आवश्यकता है)।

अन्य अंतर अनदेखी श्रेणियों की हैंडलिंग है। OneHotEncoder के वर्तमान व्यवहार के साथ, यदि अनदेखी मान सीमा (0, अधिकतम) के भीतर हैं, तो यह handle_unknow='error' (डिफ़ॉल्ट) होने पर भी कोई त्रुटि नहीं उठाएगा। लेकिन यह भी अलग से हल किया जा सकता है ऐसे मामले में एक चेतावनी उठाकर कि उपयोगकर्ता को मौजूदा व्यवहार को बनाए रखने के लिए मैन्युअल रूप से handle_unknown='ignore' सेट करना चाहिए।

एकमात्र विशेषता जो हम खो देंगे वह अज्ञात श्रेणियों के बीच का अंतर है जो सीमा (0, अधिकतम) के भीतर हैं (वर्तमान OneHotEncoder द्वारा 'अज्ञात' नहीं माना जाता है) और जो इससे बड़े हैं (> अधिकतम, जिन्हें वर्तमान में पहले से ही माना जाता है OneHotEncoder द्वारा अज्ञात के रूप में)।

नहीं, यह उस तरह की चीज है जिसे हमने पहले भी आजमाया है और यह भी है
बारीक। जब तक वर्तमान व्यवहार को बनाए रखने का कोई अच्छा कारण न हो, हम
हमें भविष्य में धीरे-धीरे लाने के लिए बस एक विरासत_मोड होना चाहिए।

नहीं, यह इस तरह की चीज है जिसे हमने पहले भी आजमाया है और यह बहुत बारीक है।

क्या आप स्पष्ट कर सकते हैं कि यह "नहीं" किस पहलू को संदर्भित करता है?
इस तथ्य के लिए कि मुझे लगता है कि legacy_mode की आवश्यकता नहीं है?

हाँ, इस विचार के लिए कि आप कुछ ऐसा बना सकते हैं जो दोनों पीछे की ओर हो
संगत और हम आगे क्या चाहते हैं

हां, इस विचार के लिए कि आप कुछ ऐसा बना सकते हैं जो पीछे की ओर संगत हो और जिसे हम आगे बढ़ाना चाहते हैं

मैंने यही सुझाव देने की कोशिश नहीं की थी। मैं यह स्पष्ट करना चाहता था कि लगता है कि legacy_mode कीवर्ड नहीं होना संभव है, न कि यह जादुई रूप से पीछे की ओर और भविष्य में हम क्या चाहते हैं, बल्कि मौजूदा कीवर्ड के व्यवहार को हटाकर।

तो ठोस होने के लिए: n_values एक गैर-डिफ़ॉल्ट मान बहिष्कृत किया जा सकता है और इसे categories विनिर्देश द्वारा प्रतिस्थापित किया जाना चाहिए। handle_unknow पूर्णांक डेटा के मामले में उपयोगकर्ता द्वारा स्पष्ट रूप से मौजूदा मिश्रण के बजाय पूर्ण अनदेखी या पूर्ण त्रुटि चुनने के लिए सेट किया जाना चाहिए (और अन्यथा बहिष्करण चेतावनी उठाई जाती है)।

तो अगर मैं .fit([[5]]).transform([[4]]) करता हूं, जिसके लिए n_values ​​के मान,
श्रेणियां और हैंडल_मज्ञात क्या कोई त्रुटि उत्पन्न करेगा?

25 जनवरी 2018 को सुबह 9:32 बजे, "जोरिस वैन डेन बोस्चे" सूचनाएं @github.com
लिखा था:

हाँ, इस विचार के लिए कि आप कुछ ऐसा बना सकते हैं जो दोनों पीछे की ओर हो
संगत और हम आगे क्या चाहते हैं

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

तो ठोस होने के लिए: n_values ​​​​का एक गैर-डिफ़ॉल्ट मान बहिष्कृत किया जा सकता है और
श्रेणियों के विनिर्देश द्वारा प्रतिस्थापित किया जाना है। के मामले में हैंडल_अज्ञात
पूर्णांक डेटा को उपयोगकर्ता द्वारा स्पष्ट रूप से पूर्ण चुनने के लिए सेट किया जाना चाहिए
वर्तमान मिश्रण के बजाय अनदेखी या पूर्ण त्रुटि (और अन्यथा बहिष्करण
चेतावनी उठाई गई है)।

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

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

क्या हम इसे सिर्फ इतना बना सकते हैं कि बहिष्करण के दौरान, श्रेणियों को स्पष्ट रूप से सेट किया जाना चाहिए, और चेतावनियों के साथ विरासत मोड अन्यथा प्रभावी है? क्या आप यही सुझाव दे रहे हैं?

हां, यह अभी भी गायब मामला हो सकता है, लेकिन मुझे लगता है कि यह संभव है (अगले सप्ताह वास्तविक कोडिंग द्वारा जांच करेगा)।

विभिन्न 'विरासत' मामले:

• n_values ​​= 'ऑटो' (डिफ़ॉल्ट)
  
  
  
  • हैंडल_अज्ञात = 'अनदेखा करें' -> ठीक है, व्यवहार में कोई बदलाव नहीं
  
  
  • हैंडल_अज्ञात = 'त्रुटि' -> समस्या, श्रेणी में मानों को अभी भी अनदेखा किया जाता है, सीमा से ऊपर के मान त्रुटि
    
    
    
    
    
    • संभावित स्थिति:
      
      
      
      
      
      
      
      • फिट में, यदि सीमा लगातार => ठीक है, व्यवहार में कोई बदलाव नहीं है (उन सभी लोगों के लिए जो अब इसके साथ लेबलएनकोडर को जोड़ते हैं, जो एक सामान्य उपयोग मामला है जो मुझे लगता है)
      
      
      
      
      • यदि ऐसा नहीं है: पदावनति चेतावनी बढ़ाएं कि उन्हें इस व्यवहार को बनाए रखने के लिए स्पष्ट रूप से श्रेणियां निर्धारित करनी होंगी (और आंतरिक रूप से विरासत मोड का उपयोग करें)
      
      
      
      
    
    
    
  
  
• n_values=value
  
  
  
  • इसका आंतरिक रूप से श्रेणियों = [श्रेणी (मान)] में अनुवाद किया जा सकता है, और बहिष्करण चेतावनी बढ़ा सकता है कि उपयोगकर्ता को भविष्य में स्वयं ऐसा करना चाहिए
  
  
  • इस मामले में handle_unknown='error' / 'ignore' उम्मीद के
  
  

n_values='auto' मामले में मूल्यह्रास चेतावनी केवल fit में बढ़ाई जाएगी और निर्माण पर नहीं (जो वास्तव में आदर्श नहीं है), लेकिन यह केवल फिट है कि हम जानते हैं कि उपयोगकर्ता इसे पास कर रहा है संख्यात्मक डेटा और स्ट्रिंग डेटा नहीं।

हम आमतौर पर किसी भी स्थिति में फिट होने तक चेतावनी नहीं देते हैं, इसलिए चिंता न करें
वह।

वह रणनीति ज्यादातर अच्छी लगती है।

मुझे वास्तव में यकीन नहीं है कि हमें डेटा में स्ट्रिंग्स के लिए सूँघना चाहिए,
हालांकि। आप मूल रूप से इसे चाहते हैं: यदि श्रेणियां हैं तो लीगेसी मोड सक्रिय है
सेट नहीं है और यदि डेटा सभी पूर्णांक है?

एक प्रश्न: यदि श्रेणियां और n_values ​​पैरामीटर उनके डिफ़ॉल्ट हैं, तो करें
हम श्रेणियाँ_ प्रकाशित करते हैं? यदि n_values ​​स्पष्ट रूप से सेट किया गया है, तो क्या हम प्रकाशित करते हैं
श्रेणियाँ_?

29 जनवरी 2018 को सुबह 10:00 बजे, "जोरिस वैन डेन बोस्चे" नोटिफिकेशन @github.com
लिखा था:

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

हाँ, यह अभी भी लापता मामला हो सकता है, लेकिन मुझे लगता है कि यह संभव है (होगा .)
इसे अगले सप्ताह वास्तविक कोडिंग द्वारा जांचें)।

विभिन्न 'विरासत' मामले:

• n_values ​​= 'ऑटो' (डिफ़ॉल्ट)
  
  
  
  • हैंडल_अज्ञात = 'अनदेखा करें' -> ठीक है, व्यवहार में कोई बदलाव नहीं
  
  
  • हैंडल_अज्ञात = 'त्रुटि' -> समस्या, सीमा में मान अभी भी हैं
    
    पर ध्यान नहीं दिया गया, सीमा से ऊपर के मान त्रुटि
    
    
    
    
    
    • संभावित स्थिति:
      
      
      
      
      
      
      
      • फिट में, यदि सीमा लगातार है => ठीक है, इसमें कोई बदलाव नहीं है
        
        
        
        व्यवहार (उन सभी लोगों के लिए जो अब इसके साथ LabelEncoder को मिलाते हैं, जो है
        
        
        
        मुझे लगता है कि एक सामान्य उपयोग मामला)
      
      
      
      
      • यदि ऐसा नहीं है: पदावनत चेतावनी बढ़ाएँ कि
        
        
        
        उन्हें इस व्यवहार को बनाए रखने के लिए स्पष्ट रूप से श्रेणियां निर्धारित करनी होंगी (और
        
        
        
        आंतरिक रूप से लीगेसी मोड का उपयोग करें)
      
      
      
      
    
    
    
    • n_values=value
    
    
    
  
  
  • इसका आंतरिक रूप से श्रेणियों = [श्रेणी (मान)] में अनुवाद किया जा सकता है,
    
    और बहिष्करण चेतावनी बढ़ाएं कि उपयोगकर्ता को स्वयं ऐसा करना चाहिए
    
    भविष्य
  
  
  • इस मामले में हैंडल_अज्ञात = 'त्रुटि' / 'अनदेखा' अपेक्षा के अनुरूप काम करता है
  
  

n_values='auto' के मामले में मूल्यह्रास चेतावनी केवल में बढ़ाई जाएगी
फिट और निर्माण पर नहीं (जो वास्तव में आदर्श नहीं है), लेकिन यह केवल है
फिट में हम जानते हैं कि उपयोगकर्ता इसे संख्यात्मक डेटा पास कर रहा है, न कि स्ट्रिंग
आंकड़े।

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

आप मूल रूप से इसे चाहते हैं: यदि श्रेणियां सेट नहीं हैं और डेटा सभी पूर्णांक हैं तो विरासत मोड सक्रिय है?

हाँ वास्तव में (व्यवहार में यह कमोबेश वही होगा)

एक प्रश्न: यदि श्रेणियां और n_values ​​​​पैरामीटर उनके डिफ़ॉल्ट हैं, तो क्या हम श्रेणियां_ प्रकाशित करते हैं? यदि n_values ​​स्पष्ट रूप से सेट है, तो क्या हम श्रेणियां_ प्रकाशित करते हैं?

मैं व्यक्तिगत रूप से पहले से ही यथासंभव नए इंटरफ़ेस की विशेषताएँ प्रदान करूँगा, यहाँ तक कि लीगेसी मोड में भी। तो दोनों ही मामलों में मैं categories_ गणना करूंगा (भले ही यह थोड़ा और काम हो)

इसलिए मैंने उपरोक्त तर्क को कोड में डालने की कोशिश की (पीआर में कुछ अपडेट को आगे बढ़ाया जाएगा), और मेरे पास पूर्णांक डेटा के मामले में एक और सवाल है जब n_values या categories सेट नहीं है ( 'legacy_mode' के लिए विशिष्ट मामला)। समस्या इस तथ्य में निहित है कि यदि अनुमानित श्रेणियां केवल एक लगातार श्रेणी (0, 1, 2, 3, ... अधिकतम) हैं, तो नए और पुराने (विरासत) व्यवहार के बीच कोई अंतर नहीं है, और हम नहीं करते हैं आवश्यक रूप से एक बहिष्करण चेतावनी बढ़ाने की आवश्यकता है।
इस विशिष्ट मामले में करने के लिए कुछ संभावनाएं:

1) इस मामले का पता लगाएं (कि अनुमानित श्रेणियां लगातार श्रेणी हैं), और उस स्थिति में कोई चेतावनी न दें।
- यह पता लगाना संभव है (थोड़ी अतिरिक्त कोड जटिलता के साथ) क्योंकि हम पहले से ही किसी भी तरह फिट हैं
- मुझे लगता है कि पूर्णांक डेटा के साथ OneHotEncoder का उपयोग करते समय यह एक सामान्य मामला होगा, और एक ऐसा मामला जहां उपयोगकर्ता को वास्तव में हमारे रिफैक्टरिंग के बारे में चिंता करने की आवश्यकता नहीं है, इसलिए उसे चेतावनी के साथ परेशान न करना अच्छा होगा
2) हमेशा एक चेतावनी दें, और चेतावनी संदेश में इंगित करें कि यदि आप ऐसे मामले में हैं तो क्या करना है (एक स्पष्टीकरण के अलावा यदि आपके पास लगातार सीमा नहीं है तो क्या करें):
- अगर वे जानते हैं कि उनके पास श्रेणियों के रूप में केवल लगातार श्रेणियां हैं, तो वे चेतावनी को अनदेखा करना चाहते हैं, इसलिए हम चेतावनी संदेश में एक स्पष्टीकरण जोड़ सकते हैं कि यह कैसे करना है (फ़िल्टर चेतावनी के साथ एक कोड नमूना जोड़ें जिसे वे पेस्ट कॉपी कर सकते हैं)
- इसका एक संभावित लाभ यह है कि हम चेतावनी संदेश में यह भी जोड़ सकते हैं कि यदि उन्होंने पूर्णांक बनाने के लिए लेबलएनकोडर का उपयोग किया है, तो वे अब सीधे OneHotEncoder का उपयोग कर सकते हैं (मुझे लगता है कि यह वर्तमान में एक विशिष्ट उपयोग पैटर्न है)। इस तरह, चेतावनी भी चली जाएगी
3) हमेशा एक चेतावनी दें लेकिन उसे शांत करने के लिए एक कीवर्ड प्रदान करें (जैसे legacy_mode=False )
- अगर हमें filterwarnings स्टेटमेंट (ऊपर बिंदु 2 देखें) का उपयोग करने की सलाह बहुत बोझिल लगती है, तो हम वही परिणाम प्राप्त करने के लिए एक कीवर्ड भी जोड़ सकते हैं
- इसका नुकसान एक ऐसे कीवर्ड को पेश कर रहा है जिसकी अब कुछ रिलीज में जरूरत नहीं होगी जब बहिष्करण साफ हो जाएंगे।

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

हम्म, एक मामला मैं भूल गया जब आपके पास पूर्णांक अनुमानित श्रेणियां हैं जो लगातार नहीं हैं (मान लें [1,3,5]), लेकिन आप नया व्यवहार चाहते हैं न कि विरासत व्यवहार (इसलिए उस स्थिति में आप केवल चेतावनी को अनदेखा नहीं कर सकते हैं) , क्योंकि यह परिवर्तन चरण में अदृश्य मानों को अलग तरह से संभालेगा, अर्थात सीमा के बीच के मान (जैसे 2) कोई त्रुटि नहीं पैदा करेंगे)।
यदि हम legacy_mode=False कीवर्ड प्रदान नहीं करते हैं, तो नया व्यवहार प्राप्त करने का एकमात्र तरीका मैन्युअल रूप से categories=[1,3,5] , जो थोड़ी असुविधा हो सकती है। यह विकल्प 3 का पक्ष लेने का एक कारण हो सकता है और अस्थायी कीवर्ड legacy_mode=False को पेश करने पर मेरी आपत्ति को छोड़ सकता है (लेकिन यह भी पूरी तरह से सुनिश्चित नहीं है कि यह इसके लायक है, क्योंकि यह एकमात्र मामला होगा * जहां ऐसा कीवर्ड वास्तव में है आवश्यकता है)

* यह एकमात्र मामला = अनुमानित श्रेणियों के साथ पूर्णांक डेटा जो लगातार सीमा नहीं हैं, और जहां आप श्रेणियों को मैन्युअल रूप से सेट नहीं कर सकते हैं या अनदेखा करने के लिए हैंडल_अज्ञात सेट नहीं कर सकते हैं।

सभी लंबे पाठ के लिए खेद है, लेकिन यह काफी जटिल है :)

हम केवल उस मामले के बारे में बात कर रहे हैं जहां n_values ​​सेट नहीं है, है ना?

मैं 1 के साथ ठीक हूं, और यह और अधिक महंगा नहीं होगा, क्योंकि ऑटो
पहले से ही लेबल के सेट की जांच करने की जरूरत है। मैं भी स्वीकार कर सकता था, क्योंकि
सरलता, 3 का एक प्रकार जो केवल "वनहॉटएनकोडर विरासत में चल रहा था
तरीका। श्रेणियों को सेट करें = 'ऑटो' थोड़ा अलग व्यवहार के लिए बिना a
चेतावनी।"

हम केवल उस मामले के बारे में बात कर रहे हैं जहां n_values ​​सेट नहीं है, है ना?

हां (दूसरे मामले का आसानी से इसके समकक्ष categories मूल्य में अनुवाद किया जा सकता है, एक अच्छी बहिष्करण चेतावनी के साथ, और नए और विरासत व्यवहार में अलग के बिना)

3 का एक प्रकार, वह था "वनहॉटएनकोडर लीगेसी मोड में चल रहा है। बिना किसी चेतावनी के थोड़ा अलग व्यवहार के लिए श्रेणियां = 'ऑटो' सेट करें।"

आह, यह एक अच्छा विचार लगता है! (चाहे लगातार श्रेणियों के मामले का पता लगाया जाए या नहीं)। इसलिए हम कोड में categories के डिफ़ॉल्ट को कोई नहीं (इसके डिफ़ॉल्ट के शब्दार्थ को बदले बिना) सेट करते हैं, इसलिए हम जानते हैं कि क्या उपयोगकर्ता इसे स्पष्ट रूप से सेट करता है, और इस तरह यह legacy_mode=False इंगित करने का एक अच्छा तरीका है

हां, लेकिन केवल तभी जब हम हर बार किसी के पास जाने के बिना इसका इस्तेमाल करने पर चेतावनी देना चाहते हैं
श्रेणियाँ। यह सस्ता कार्यान्वयन दृष्टिकोण है, लेकिन यह हो सकता है
उपयोगकर्ताओं के लिए अनावश्यक रूप से वर्बोज़, यही कारण है कि मैं 1 पसंद करूंगा यदि यह
सरलता से किया जा सकता है।

यह किसने गन्दा किया है :-/

या हम नए को DummyEncoder नाम दे सकते हैं;) (हालांकि यह डमी क्लासिफायर के साथ थोड़ा विरोधाभासी है)

@amueller उपरोक्त सभी को न पढ़ें!
मैं इस मुद्दे के नए पाठकों के लिए एक अच्छा सारांश बनाने की योजना बना रहा था। उपरोक्त चर्चा अत्यधिक जटिल है (क्योंकि मैं अभी भी OneHotEncoder के वर्तमान जटिल व्यवहार को पूरी तरह से समझ नहीं पा रहा था ... :-))

या हम नए का नाम डमीएनकोडर रख सकते हैं;)

मुझे लगता है कि @GaelVaroquaux इसके खिलाफ था क्योंकि "वन-हॉट" इसे और अधिक क्षेत्रों में जाना जाता है (और हम पहले से ही विज्ञान-सीखने में अन्य चीजों के लिए 'डमी' का उपयोग करते हैं ...)

नामकरण में निरंतरता के लिए इसे फिर से करना इसके लायक नहीं है। हम कहीं भी नामकरण में सुसंगत नहीं हैं। क्या आप उन चर्चाओं को संक्षेप में बता सकते हैं जो इसे आगे ले जाती हैं?

मुझे लगता है कि "डमी" सांख्यिकीविद क्या उपयोग करते हैं और पांडा इसका उपयोग करते हैं।

शीर्ष पोस्ट अभी भी सटीक और पढ़ने लायक है, और यह CategoricalEncoder नहीं रखने के तर्क को सारांशित करता है (जिसका अर्थ यह नहीं है कि हमें DummyEncoder के बजाय OneHotEncoder का उपयोग करने की आवश्यकता है, यह एक अलग प्रश्न है)

मैंने शीर्ष पोस्ट पढ़ा। जब मैंने कहा था कि "स्थिरता के लिए इसे फिर से करना इसके लायक नहीं है" तो मैंने यही कहा।

खोले गए मुद्दे

क्या आप इसे समझा सकते हैं?

"स्थिरता के लिए इसे फिर से करना इसके लायक नहीं है"

निरंतरता के साथ, क्या आप "यह क्या स्वीकार करता है" बनाम "यह क्या करता है" की नामकरण योजना की ओर इशारा कर रहे हैं? यदि हां, तो वह केवल एक मामूली कारण था। मेरे लिए यह मुख्य रूप से एक वर्ग में और अधिक सुविधाओं को जोड़ने में मापनीयता का प्रश्न है।

खोले गए मुद्दे

हमारे पास लापता मूल्यों को संभालने के तरीके के बारे में मुद्दा था (https://github.com/scikit-learn/scikit-learn/issues/10465), और इसके लिए आप क्रमिक और एक-हॉट एन्कोडिंग के लिए अलग व्यवहार चाहते हैं (या नहीं सभी विकल्प दोनों के लिए मान्य हैं, ..) हमारे पास पहले से ही मौजूदा handle_unknown जो केवल एक-हॉट एन्कोडिंग के लिए प्रासंगिक है और सामान्य के लिए नहीं। और वनहॉट एन्कोडिंग के लिए फीचर वेटिंग के बारे में https://github.com/scikit-learn/scikit-learn/issues/10518 था, लेकिन ऑर्डिनल के लिए भी प्रासंगिक नहीं था (अंत में यह समस्या कोई समस्या नहीं थी, जैसा कि आप कर सकते हैं) कॉलमट्रांसफॉर्मर ट्रांसफॉर्मर_वेट तर्क के साथ भार)। और हमारे पास एक-हॉट के लिए drop_first जैसा कुछ जोड़ने का फीचर अनुरोध भी है, जो फिर से क्रमिक एन्कोडिंग के लिए प्रासंगिक नहीं है।

मैं नहीं देखता कि प्रस्तावित परिवर्तन लापता मूल्यों के साथ कितना मदद करेगा। और असंगत विकल्प होना एक ऐसी चीज है जो अक्सर स्किकिट-लर्न में होती है। आदर्श नहीं है, लेकिन यह भी कोई बड़ी बात नहीं है।

मैं नहीं देखता कि प्रस्तावित परिवर्तन लापता मूल्यों के साथ कितना मदद करेगा।

यह इस तरह से मदद नहीं करता है, लेकिन यह विशिष्ट विकल्पों को विशेष रूप से विभिन्न एन्कोडिंग प्रकारों के अनुरूप बनाने के लिए कम जटिल बनाता है।

और असंगत विकल्प होना एक ऐसी चीज है जो अक्सर स्किकिट-लर्न में होती है। आदर्श नहीं है, लेकिन यह भी कोई बड़ी बात नहीं है।

वर्तमान में यह निश्चित रूप से अभी भी ठीक है, बहुत सारे असंगत विकल्प नहीं हैं (लेकिन आंशिक रूप से इसलिए भी क्योंकि मैंने sparse=True/False को encoding विकल्प में स्थानांतरित कर दिया है)। लेकिन सवाल यह है कि हम भविष्य में स्किकिट-लर्न में एन्कोडिंग कार्यक्षमता को किस हद तक विस्तारित करना चाहते हैं। जिसका निश्चित रूप से अब उत्तर देना एक कठिन प्रश्न है।
हमारे पास पहले से ही 'यूनरी एन्कोडिंग' के लिए एक पीआर है। क्या इसे एक नया वर्ग UnaryEncoder जोड़ने के बजाय CategoricalEncoder में नहीं जोड़ा जाना चाहिए? और क्या होगा यदि कोई 'बाइनरी एन्कोडिंग' जोड़ना चाहता है? या एक '(माध्य) लक्ष्य एन्कोडर'?

"माध्य लक्ष्य एन्कोडर" CountTransformer , इसके लिए एक पीआर है;)

क्या आपके पास इसके लिए एक लिंक है? "काउंटट्रांसफॉर्मर" की खोज करने से कोई परिणाम नहीं मिलता है

क्षमा करें, काउंटफ़ीचराइज़र #9614

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

इसका मतलब लक्ष्य एन्कोडिंग क्यों नहीं है? लेकिन हाँ यहाँ बहुत ज्यादा डायवर्ट न करें;)

तो वास्तविक प्रश्नों के सारांश के रूप में हमें उत्तर देने की आवश्यकता है (इस क्रम में!):

1. क्या हम वर्तमान CategoricalEncoder ? यदि नहीं, तो विचार यह है कि इसे विभिन्न वर्गों में विभाजित किया जाए, प्रत्येक प्रकार के एन्कोडिंग के लिए एक वर्ग (वर्तमान में 'वनहॉट' और 'ऑर्डिनल' एन्कोडिंग)।

2. यदि हम कई वर्गों में विभाजित होते हैं, तो हम (आदर्श रूप से?) 'वनहॉट' एन्कोडिंग के लिए OneHotEncoder का उपयोग कर सकते हैं, लेकिन यह वर्ग पहले से मौजूद है। तो, क्या हम मौजूदा OneHotEncoder वर्ग में नए 'वनहॉट' एन्कोडिंग (जो स्ट्रिंग्स का समर्थन करता है और अलग-अलग पैरामीटर हैं) को एकीकृत करता है? या हम कोई दूसरा नाम चुनते हैं? (जैसे डमी एनकोडर)

3. यदि हम मौजूदा OneHotEncoder में एकीकृत करना चुनते हैं, तो क्या हम निम्नलिखित परिणामों के साथ ठीक हैं: हम OneHotEncoder के कीवर्ड/विशेषताओं के एक समूह को हटा देते हैं, और एक विशिष्ट उपयोगकेस (देखे गए मानों की सीमा के भीतर अनदेखी मानों को स्वचालित रूप से अनदेखा करना) संभव नहीं होगा। अब मूल्यह्रास अवधि के बाद।

ऊपर दी गई अधिकांश चर्चा प्रश्न 3 के बारे में थी (CategoricalEncoder(encoding='onehot') को OneHotEncoder में एकीकृत करने का जटिल विवरण)। लेकिन आइए पहले पहले 2 प्रश्नों के निर्णय पर सहमत हों।

मेरे लिए दूसरा कारक यह है कि हर कोई वर्तमान ऑटो मोड में सोचता है
OneHotEncoder अजीब है। इसका कार्यान्वयन सीओओ को सीएसआर में परिवर्तित करना भी है
अजीब। यह एक नया स्वरूप देने योग्य है। और लोगों को बता रहे हैं "यदि आप एक हॉट चाहते हैं"
स्ट्रिंग्स को एन्कोड करें, इसके बजाय CategoricalEncoder पर जाएं" अजीब है, क्योंकि OHE
पहले से ही श्रेणीबद्धों के लिए अभिप्रेत है ...

घंटा मुझे लगता है कि हमने OneHotEncoder रखा है क्योंकि जब इसका उपयोग किया जा सकता है तो यह अधिक कुशल होता है.... आदर्श रूप से हम सभी अजीब व्यवहारों से छुटकारा पा लेंगे। मैं थोड़े इसे पदावनत करना चाहता था, लेकिन तब हमने ऐसा नहीं किया ...

मैं थोड़े इसे पदावनत करना चाहता था, लेकिन तब हमने ऐसा नहीं किया ...

मेरे POC PR (https://github.com/scikit-learn/scikit-learn/pull/10523) में, मैंने OneHotEncoder की लगभग हर चीज़ को हटा दिया, सिवाय इसके नाम के ...

यह बहुत अधिक कुशल नहीं है। और अगर लेबलएन्कोडर के पास इनट्स के लिए तेज़ रास्ते थे
सीमा में [0, n_values-1], यदि उचित हो, तो यह काफी अच्छा होगा।

@amueller , क्या आप इस मुद्दे से सहमत हैं कि हम अंततः एन्कोडिंग के आधार पर अलग-अलग अतिरिक्त पैरामीटर (जैसे ड्रॉप_फर्स्ट, नैन हैंडलिंग) चाहते हैं, और यह प्रत्येक एन्कोडिंग प्रारूप के लिए एक अलग असतत एन्कोडर होने का औचित्य साबित करता है?

मैं इसे दो सप्ताह में स्प्रिंग ब्रेक में देखने की कोशिश करूँगा, ठीक है? सुनिश्चित नहीं है कि मेरे पास इससे पहले समय होगा: - /

मुझे आशा है कि यह पूछने के लिए गलत जगह नहीं है, लेकिन वर्तमान कार्यान्वयन उन तालिकाओं के साथ क्या करता है जो एक कॉलम के भीतर मिश्रित श्रेणीबद्ध और गैर-श्रेणीबद्ध हैं? https://github.com/pandas-dev/pandas/issues/17418 से उदाहरण लेते हुए

डेटाफ्रेम df = pd.DataFrame([{'apple': 1, 'pear':'a', 'carrot': 1}, {'apple':'a', 'pear':2, 'carrot':3}, {'apple': 2, 'pear':3, 'carrot':1}, {'apple': 3, 'pear':'b', 'carrot': 1}, {'apple': 4, 'pear':4, 'carrot': 1}]) पर विचार करें जो बराबर है:

  apple  carrot pear
0     1       1    a
1     a       3    2
2     2       1    3
3     3       1    b
4     4       1    4

DictVectorizer ठीक वही देता है जो मुझे इस मामले में चाहिए।

    from sklearn.feature_extraction import DictVectorizer
    enc = DictVectorizer(sparse = False)
    enc.fit_transform(df.to_dict(orient='r'))

यह देता है:

array([[ 1.,  0.,  1.,  0.,  1.,  0.],
       [ 0.,  1.,  3.,  2.,  0.,  0.],
       [ 2.,  0.,  1.,  3.,  0.,  0.],
       [ 3.,  0.,  1.,  0.,  0.,  1.],
       [ 4.,  0.,  1.,  4.,  0.,  0.]])

हम कॉलम के फीचर नाम देख सकते हैं:

    enc.feature_names_
    ['apple', 'apple=a', 'carrot', 'pear', 'pear=a', 'pear=b']

यह बहुत अच्छा होगा यदि नए CategoricalEncoder के पास ऐसा करने का विकल्प हो।

मुझे नहीं लगता कि हम उस तरह के मिश्रित मामले को संभालने का इरादा रखते हैं

कि एक शर्म की बात है। एक साधारण उप-मामला वह है जहां एक कॉलम संख्यात्मक होता है लेकिन इसमें कुछ लापता मान होते हैं। एक सरल उपाय यह है कि NaNs को खाली स्ट्रिंग्स में बदल दिया जाए और फिर ऊपर दिए गए मेरे उदाहरण के अनुसार DictVectorizer का उपयोग किया जाए। यह प्रभावी रूप से एक नई सुविधा बनाता है जब मान गायब होता है लेकिन संख्यात्मक मानों को अन्यथा अपरिवर्तित छोड़ देता है। मुझे यह बहुत उपयोगी तकनीक लगी है।

क्या नया CategoricalEncoder कुछ ऐसा ही कर पाएगा?

हमने उपयोगकर्ताओं को NaN को एक अलग श्रेणी के रूप में मानने की अनुमति देने पर विचार किया है
या इसी के समान। लेकिन यह मनमाना सांख्यिक मानों को संभालने जैसा नहीं है
तार से भिन्न।

यह अच्छा रहेगा।

आप सही हैं दो उपयोग के मामले हैं। मुझे एक विशेष उदाहरण के बारे में बताएं जहां संख्यात्मक मानों को स्ट्रिंग्स से अलग मानना ​​मेरे लिए उपयोगी रहा है। हो सकता है कि कोई बेहतर उपाय हो।

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

तो आप इसे गैर-रैखिक विवेक के लिए उपयोग कर रहे हैं? अगली रिलीज है
एक निश्चित-चौड़ाई वाले डिस्क्रीटाइज़र को शामिल करने की संभावना है, लेकिन एक लॉग से अनुसरण करना
ट्रांसफॉर्म या क्वांटाइल ट्रांसफॉर्म इसे आपके जैसा ही कार्य करना चाहिए
चाहते हैं... लेकिन आपकी सेटिंग में लॉग ट्रांसफ़ॉर्म अकेले ही पर्याप्त हो सकता है।

पर 25 फरवरी 2018 18:10 में, lesshaste [email protected] लिखा है:

यह अच्छा रहेगा।

आप सही हैं दो उपयोग के मामले हैं। मैं एक विशेष उदाहरण समझाता हूँ
जहां संख्यात्मक मानों को स्ट्रिंग्स से भिन्न मानना ​​उपयोगी रहा है
मेरे लिए। हो सकता है कि कोई बेहतर उपाय हो।

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

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

@jnothman हाँ एक अर्थ में एक मोड़ के अलावा। मान लें कि मुझे संदेह है कि 1...1024 से कुछ मान सार्थक हैं। वह 22 है जो कुछ विशिष्ट इंगित करता है जो 21 या 23 से काफी अलग है। लॉग लेने से यहां मदद नहीं मिलेगी। लेकिन मैं 1024 से अधिक के सभी मानों को संख्यात्मक के रूप में छोड़ना चाहता हूं क्योंकि मुझे नहीं लगता कि उन विशिष्ट मूल्यों का अधिक अर्थ है।

ऐसा लगता है कि आप एक सामान्य के लिए अपने चर के बारे में बहुत कुछ जानते हैं
आपको जिस चीज की जरूरत है, उसे रूपांतरित करें।

पर 25 फरवरी 2018 20:37 पर, lesshaste [email protected] लिखा है:

@jnothman https://github.com/jnothman हाँ एक अर्थ में a . को छोड़कर
मोड़ मान लें कि मुझे संदेह है कि 1...1024 से कुछ मान सार्थक हैं।
यानी 22 कुछ विशिष्ट इंगित करता है जो 21 या . से काफी अलग है

1. लॉग लेने से यहाँ मदद नहीं मिलेगी। लेकिन मैं सभी मूल्यों को छोड़ना चाहता हूं
   1024 संख्यात्मक के रूप में मुझे नहीं लगता कि उन विशिष्ट मूल्यों का मतलब ज्यादा है।

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

@jnothman थोड़ा स्पष्ट होने के लिए, मुझे नहीं पता कि 22 महत्वपूर्ण है। मुझे बस संदेह है कि कुछ मूल्य हैं लेकिन मुझे नहीं पता कि कौन से या कितने हैं। मैंने "एक स्ट्रिंग में कनवर्ट करें" और फिर DictVectorizer विधि को यह खोजने के लिए बहुत उपयोगी पाया है कि ये कौन से हैं।

@lesshaste अलग श्रेणी के रूप में NaN के मुद्दे के लिए, देखें https://github.com/scikit-learn/scikit-learn/issues/10465
यदि आप विशिष्ट गैर-रेखीय विवेकीकरण या मिश्रित संख्यात्मक/स्ट्रिंग एन्कोडिंग पर आगे चर्चा करना चाहते हैं, तो एक नया मुद्दा खोलने के लिए स्वतंत्र महसूस करें। लेकिन मैं इसे मूल मुद्दे पर केंद्रित रखना चाहता हूं, यानी CategoricalEncoder/OneHotEncoder के विभिन्न वर्गों में नामकरण और संगठन।

मैं इसे दो सप्ताह में स्प्रिंग ब्रेक में देखने की कोशिश करूँगा, ठीक है? सुनिश्चित नहीं है कि मेरे पास इससे पहले समय होगा: - /

@amueller यह ठीक है। मेरे पास पीआर पर काम करने के लिए आने वाले दो सप्ताह का समय नहीं होगा जो वैसे भी इससे अवरुद्ध है। उसके बाद मेरे पास फिर से इस पर काम करने के लिए भी समय होना चाहिए।

@amueller क्या आपके पास इसे देखने का समय था?

@amueller क्या आप इसके साथ ठीक हैं कि मैं पीआर पर काम कर रहा हूं ताकि ऑर्डिनलएन्कोडर और वनहॉटएन्कोडर (और OneHotEncoder के मौजूदा तर्कों को बहिष्कृत करने के साथ) में CategoricalEncoder को विभाजित किया जा सके?

अनुपस्थित रहने के लिए खेद है। ठीक लगता है, लेकिन क्या आप मुझे दो सप्ताह का समय दे सकते हैं ताकि मैं वास्तव में समीक्षा कर सकूं? धन्यवाद!

@amueller कोई समस्या नहीं, मेरे लिए वही :-)
लेकिन, अब मैं इसे फिर से देखने की योजना बना रहा हूं। तो अगर आप इसे एक नज़र दे सकते हैं तो आपका स्वागत होगा। मुझे पीआर पर कुछ काम करना है (https://github.com/scikit-learn/scikit-learn/pull/10523), इसलिए इसकी अभी तक विस्तार से समीक्षा न करें (आप एक विचार रखने के लिए इसे देख सकते हैं) हालांकि हम जो प्रस्ताव देते हैं)।
मुझे लगता है कि मैं इसमें बहुत समय लगाने से पहले मुख्य प्रश्न का उत्तर देखना चाहता हूं, यदि आप CategoricalEncoder को कई वर्गों में विभाजित करने के साथ ठीक हैं, और उस स्थिति में, यदि आप OneHotEncoder का पुन: उपयोग करने के साथ ठीक हैं (जिसका अर्थ है इसकी कुछ वर्तमान (अजीब) विशेषताओं को चित्रित करना)। उन सवालों का सारांश https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment -363851328 और https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment में दिया गया है। -364802471।

(और एक बार जब हम उस हिस्से पर सहमत हो जाते हैं, तो पीआर में वास्तविक कार्यान्वयन के बारे में चर्चा करने के लिए अभी भी बहुत कुछ है :))

मैंने पीआर अपडेट किया https://github.com/scikit-learn/scikit-learn/pull/10523 , समीक्षा के लिए तैयार

मैं सावधानी से कहूंगा कि मैं वापस आ गया हूं;)

आईएमएचओ सबसे महत्वपूर्ण चीज एक सार्वभौमिक एपीआई है (यानी पैरामीटर और बीबीहेवियर पैटर्न) हम जिन सभी एन्कोडर्स पर चर्चा करते हैं उनके लिए

पीएस https://github.com/scikit-learn-contrib/categorical-encoding ?

category_encoders पैकेज में, सभी एन्कोडर्स के पास cols तर्क है, जो पुराने OneHotEncoder में categorical_features समान है (हालांकि यह बिल्कुल उसी तरह के मूल्यों को स्वीकार नहीं करता है)। उदाहरण देखें http://contrib.scikit-learn.org/categorical-encoding/onehot.html
तो यह उस वर्तमान चर्चा से संबंधित है जो हम https://github.com/scikit-learn/scikit-learn/pull/10523 में categorical_features पदावनत करने या न करने के बारे में कर रहे हैं।

बाकी के लिए मुझे लगता है कि वास्तव में परस्पर विरोधी कीवर्ड नहीं हैं (उनके पास डेटाफ़्रेम के लिए विशिष्ट कुछ अन्य हैं जिन्हें हम इस बिंदु पर स्केलेर में नहीं जोड़ेंगे)। OneHotEncoder और OrdinalEncoder का नामकरण कम से कम category_encoders पैकेज के अनुरूप है।