Scikit-learn: إعادة التفكير في واجهة برمجة تطبيقات CategoricalEncoder؟

شكرا على الملخص jorisvandenbossche. أعتقد أنني أؤيد الخيار 2: إعادة استخدام فئة OneHotEncoder ، وإيقاف السمات الغريبة وإضافة معلمة مُنشئ لتحديد السلوك مع تحذير مستقبلي يفيد بأن السلوك الافتراضي سيتغير ولكنه يجعل من السهل إسكاته هذا التحذير بمجرد تمرير قيمة لهذا الخيار.

إن فكرة الرجوع إلى CategoricalEncoder تجعلني حزينًا للغاية ، لكنني أعتقد ذلك
أنت محق في أن المستخدمين المستقبليين سيكونون أقل حيرة بسبب الخيار 2. بلدي الرئيسي
القلق هو أننا حاولنا تنفيذ هذا كتغيير في OHE لـ
وقت طويل ولم تطير قط. ربما سيكون من الجيد محاولة
تعديلات على مستند OneHotEncoder وفقًا لذلك المقترح
التغيير ، حتى نتمكن من معرفة ما إذا كان يبدو عاقلاً.

+1 لما قاله جويل

⁣ مرسلة من هاتفي. من فضلك اغفر الأخطاء المطبعية والإيجاز.

في 23 كانون الثاني (يناير) 2018 ، الساعة 12:28 ، الساعة 12:28 ، كتب Joel Nothman [email protected] :

فكرة الرجوع إلى CategoricalEncoder تجعلني حزينًا للغاية ، لكنني
فكر في
أنت محق في أن المستخدمين المستقبليين سيكونون أقل حيرة بسبب الخيار 2. بلدي
الأساسية
القلق هو أننا حاولنا تنفيذ هذا كتغيير في OHE ل
أ
وقت طويل ولم تطير قط. ربما سيكون من الجيد محاولة
تعديلات على مستند OneHotEncoder وفقًا لذلك المقترح
التغيير ، حتى نتمكن من معرفة ما إذا كان يبدو عاقلاً.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على 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 data (تمت معالجتها من قبل بواسطة OneHotEncoder) تم تعيين encoded_input داخليًا على True ويتم رفع تحذير الإيقاف. إذا أراد المستخدم الاحتفاظ بالسلوك الحالي ، فيمكنه تحديده يدويًا على أنه OneHotEncoder(encoded_input=True) لإسكات التحذير.
• إذا لم يكن الإدخال يشبه int ، فقمنا بتعيين encoded_input داخليًا على False وبدون تحذير ، استخدم السلوك الجديد (= سلوك CategoricalEncoder الحالي)
• في المستقبل ، نقوم بتغيير الإعداد الافتراضي encoded_input من لا شيء إلى خطأ (بشكل افتراضي ، السلوك الجديد ، أيضًا للبيانات المشابهة)

ما زلت غير متأكد مما تقترحه هو الاختلاف العملي بسبب استنتاج الفئات من القيمة القصوى.

jnothman أفترض أنك تقر أنه يمكن أن يكون هناك اختلاف في الممارسة؟ (الإخراج الذي تحصل عليه بناءً على البيانات التي لديك)

لكن ما إذا كان هذا الاختلاف مهمًا في الممارسة ، لا أعرف. هذا هو المكان الذي أود أن أرى فيه ردود الفعل. ما إذا كان أي شخص يريد بالفعل هذه الطريقة القائمة على "القيمة القصوى" ، أو ما إذا كنا على ما يرام (في المستقبل ، بعد الإهمال) فقط باستخدام الطريقة القائمة على "القيم الفريدة".

أعتقد أنني شخصيًا لن أحتاج أبدًا إلى هذه الطريقة القائمة على القيمة القصوى ، لكن OneHotEncoder ظل هكذا لسنوات عديدة (لسبب وجيه أم لا؟).

في الواقع ، سيؤدي إهمال التصنيف المستند إلى القيمة القصوى إلى جعل التنفيذ (بعد الإهلاك) أبسط.
وإذا اخترنا هذا المسار ، فأنا أوافق على أن الخيار يجب أن يكون legacy_mode=True/False بدلاً من encoded_input / ordinal_input

ذكرني بالفرق الفعلي في المخرجات ، عندما n_values ​​= 'auto' ،
من فضلك؟ كنت أعتقد أن العنصر النشط هو من صنعها بشكل أساسي
متطابقة ، لكنني ربما نسيت شيئًا ما.

آها ، هذا يوضح سوء فهمنا :-)
لقد أساءت فهم كيفية عمل 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 الحالي الذي لا يعتبر `` غير معروف '') وتلك الأكبر من ذلك (> max ، يتم اعتبار هذه الفئات حاليًا بالفعل غير معروف بواسطة OneHotEncoder).

لا ، هذا هو نوع الأشياء التي جربناها من قبل وهي أيضًا
متطلب. ما لم يكن هناك سبب وجيه للحفاظ على السلوك الحالي ، فإننا
يجب أن يكون لديك وضع legacy_mode ليقودنا ببطء إلى المستقبل.

لا ، هذا هو الشيء الذي جربناه من قبل وهو صعب للغاية.

هل يمكنك توضيح الجانب الذي تشير إليه "لا"؟
لحقيقة أنني أعتقد أن legacy_mode غير مطلوب؟

نعم ، لفكرة أنه يمكنك فقط صنع شيء معكوس
متوافق وما نريده للمضي قدمًا

نعم ، لفكرة أنه يمكنك فقط صنع شيء متوافق مع الإصدارات السابقة وما نريده للمضي قدمًا

لم يكن هذا ما حاولت أن أقترحه. أردت أن أوضح أنه من الممكن ألا يكون لديك كلمة رئيسية legacy_mode ، ليس من خلال جعلها متوافقة بشكل سحري مع ما نريده في المستقبل ، ولكن عن طريق إهمال سلوك الكلمات الرئيسية الحالية.

لكي تكون ملموسًا: يمكن إهمال القيمة غير الافتراضية البالغة n_values ويجب استبدالها بمواصفات categories . handle_unknow في حالة وجود بيانات عدد صحيح بشكل صريح من قبل المستخدم لاختيار إما التجاهل الكامل أو الخطأ الكامل بدلاً من المزيج الحالي (وبخلاف ذلك يتم رفع تحذير الإهمال).

لذلك إذا قمت بعمل. fit ([[5]]). تحويل ([[4]]) ، لأي قيم n_values ​​،
الفئات و handle_umknown سوف تثير خطأ؟

في 25 كانون الثاني (يناير) 2018 الساعة 9:32 صباحًا ، "Joris Van den Bossche" [email protected]
كتب:

نعم ، لفكرة أنه يمكنك فقط صنع شيء معكوس
متوافق وما نريده للمضي قدمًا

لم يكن هذا ما حاولت أن أقترحه. أردت أن أوضح أنه يعتقد ذلك
من الممكن ألا يكون لديك كلمة رئيسية قديمة ، وليس من خلال امتلاكها بطريقة سحرية
كلاهما متوافق مع ما نريده في المستقبل وما نريده في المستقبل ، ولكن عن طريق الإهمال
سلوك الكلمات الرئيسية الموجودة.

لكي نكون ملموسين: يمكن إهمال قيمة غير افتراضية لـ n_values ​​و
يجب استبداله بمواصفات الفئات. handle_unknow في حالة
يجب تعيين بيانات عدد صحيح بشكل صريح من قبل المستخدم لاختيار إما كاملة
التجاهل أو الخطأ الكامل بدلاً من المزيج الحالي (والإهلاك بخلاف ذلك
رفع التحذير).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 ​​= "تلقائي" (الافتراضي)
  
  
  
  • handle_unknown = 'ignore' -> جيد ، لا تغيير في السلوك
  
  
  • handle_unknown = 'error' -> مشكلة ، القيم الموجودة في النطاق لا تزال متجاهلة ، القيم فوق خطأ النطاق
    
    
    
    
    
    • حل ممكن:
      
      
      
      
      
      
      
      • ملائم ، إذا كان النطاق متتاليًا => جيد ، لا يوجد تغيير في السلوك (لجميع الأشخاص الذين يجمعون الآن LabelEncoder معه ، وهي حالة استخدام نموذجية على ما أعتقد)
      
      
      
      
      • إذا لم يكن الأمر كذلك: رفع تحذير الإيقاف بأنه يتعين عليهم تعيين الفئات صراحةً للحفاظ على هذا السلوك (واستخدام الوضع القديم داخليًا)
      
      
      
      
    
    
    
  
  
• n_values ​​= القيمة
  
  
  
  • يمكن ترجمة ذلك إلى فئات = [range (value)] داخليًا ، ورفع مستوى الإيقاف تحذيرًا بأنه يجب على المستخدم فعل ذلك بنفسه في المستقبل
  
  
  • في هذه الحالة handle_unknown='error' / 'ignore' العمل كما هو متوقع
  
  

تحذير الإيقاف في حالة n_values='auto' سيتم رفعه في fit وليس عند الإنشاء (وهو ليس مثاليًا حقًا) ، ولكن من المناسب فقط أن نعلم أن المستخدم يمر به البيانات الرقمية وليس البيانات المتسلسلة.

نحن لا نرفع التحذيرات عادة حتى يصلح في أي حال ، لذلك لا تقلق
الذي - التي.

هذه الإستراتيجية تبدو جيدة في الغالب.

لست متأكدًا حقًا مما إذا كان يجب علينا استنشاق السلاسل الموجودة في البيانات ،
على أية حال. أنت تريده بشكل أساسي أن يكون: الوضع القديم نشط إذا كانت الفئات كذلك
لم يتم تغيير وإذا كانت البيانات جميع الأعداد الصحيحة؟

سؤال واحد: إذا كانت الفئات و n_values ​​معلمات هي الافتراضية ، فافعل
ننشر الفئات_؟ إذا تم تعيين n_values ​​صراحة ، فهل ننشر
التصنيفات_؟

في 29 كانون الثاني (يناير) 2018 الساعة 10:00 صباحًا ، "Joris Van den Bossche" [email protected]
كتب:

يمكننا أن نجعلها فقط بحيث يجب تعيين الفئات أثناء الإهمال
بشكل صريح ، وما الوضع القديم مع التحذيرات ساري المفعول بخلاف ذلك؟ هل هذا
ماذا تقترح

نعم ، ربما لا تزال الحالة مفقودة ، لكنني أعتقد أن هذا ممكن (الإرادة
تحقق من خلال الترميز الفعلي الأسبوع المقبل).

حالات "الإرث" المختلفة:

• n_values ​​= "تلقائي" (الافتراضي)
  
  
  
  • handle_unknown = 'ignore' -> جيد ، لا تغيير في السلوك
  
  
  • handle_unknown = 'error' -> مشكلة ، القيم الموجودة في النطاق لا تزال موجودة
    
    متجاهلة ، القيم فوق خطأ النطاق
    
    
    
    
    
    • حل ممكن:
      
      
      
      
      
      
      
      • مناسب ، إذا كان النطاق متتاليًا => جيد ، فلا تغيير في
        
        
        
        السلوك (لجميع الأشخاص الذين دمجوا الآن LabelEncoder معه ، وهو
        
        
        
        حالة استخدام نموذجية على ما أعتقد)
      
      
      
      
      • إذا لم يكن الأمر كذلك: رفع الإيقاف تحذيرًا بأن
        
        
        
        يتعين عليهم تعيين الفئات صراحةً للحفاظ على هذا السلوك (و
        
        
        
        استخدام الوضع القديم داخليًا)
      
      
      
      
    
    
    
    • n_values ​​= القيمة
    
    
    
  
  
  • يمكن ترجمة هذا إلى فئات = [النطاق (القيمة)] داخليًا ،
    
    ورفع تحذير الإيقاف بأنه يجب على المستخدم فعل ذلك بنفسه في
    
    مستقبل
  
  
  • في هذه الحالة handle_unknown = 'error' / 'ignore' العمل كما هو متوقع
  
  

سيتم رفع تحذير الإيقاف في حالة 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) قم دائمًا برفع تحذير ، والإشارة في رسالة التحذير إلى ما يجب فعله إذا كنت في مثل هذه الحالة (بالإضافة إلى شرح ما يجب القيام به إذا لم يكن لديك نطاق متتالي):
- إذا علموا أن لديهم نطاقات متتالية فقط كفئات ، فإنهم يريدون تجاهل التحذير ، لذلك يمكننا أن نضيف إلى رسالة التحذير شرحًا لكيفية القيام بذلك (أضف عينة رمز مع تحذيرات التصفية التي يمكنهم نسخها ولصقها)
- الميزة المحتملة لهذا هو أنه يمكننا أيضًا أن نضيف إلى رسالة التحذير أنه إذا استخدموا LabelEncoder لإنشاء الأعداد الصحيحة ، فيمكنهم الآن استخدام OneHotEncoder مباشرةً (أعتقد أن هذا نمط استخدام نموذجي حاليًا). بهذه الطريقة ، سيختفي التحذير أيضًا
3) قم دائمًا برفع تحذير مع توفير كلمة رئيسية لإسكاته (على سبيل المثال ، legacy_mode=False )
- إذا وجدنا أن النصيحة لاستخدام كشف حساب filterwarnings (انظر النقطة 2 أعلاه) مرهقة للغاية ، فيمكننا أيضًا إضافة كلمة رئيسية للحصول على نفس النتيجة
- من عيوب ذلك إدخال كلمة رئيسية لن تكون مطلوبة بعد الآن في عدد قليل من الإصدارات عند إزالة الإهمال.

أنا شخصياً أؤيد الخيار 1 أو 2. استخدام LabelEncoder قبل أن يبدو أن OneHotEncoder هو نمط نموذجي (من بحث سريع على github) ، وفي هذه الحالة يكون لديك دائمًا نطاقات متتالية ، ولن يكون هناك تغيير في السلوك مع التطبيق الجديد ، لذلك لا ينبغي أن نحذر من ذلك. من ناحية أخرى ، إذا حذرنا ، فيمكننا توجيههم إلى حقيقة أنهم إذا استخدموا LabelEncoder ، فلن يكونوا بحاجة إلى القيام بذلك. والذي سيكون من الجيد أن تقدم هذه النصيحة بشكل صريح.
السؤال هو كم مرة يكون لدى المستخدمين مثل هذه الأعداد الصحيحة المتتالية مثل الفئات دون استخدام LabelEncoder كخطوة سابقة ..

حسنًا ، لقد نسيت إحدى الحالات عندما يكون لديك فئات مستنبطة بعدد صحيح وليست متتالية (دعنا نقول [1،3،5]) ، لكنك تريد السلوك الجديد وليس السلوك القديم (لذلك في هذه الحالة لا يمكنك تجاهل التحذير فقط ، حيث أن ذلك سيتعامل مع القيم غير المرئية بشكل مختلف في خطوة التحويل ، أي أن القيم الموجودة بين النطاق (على سبيل المثال 2) لن تؤدي إلى حدوث خطأ).
في حالة عدم توفير الكلمة الرئيسية legacy_mode=False ، فإن الطريقة الوحيدة للحصول على السلوك الجديد هي تمرير categories=[1,3,5] يدويًا ، الأمر الذي قد يسبب إزعاجًا بسيطًا. قد يكون هذا سببًا لتفضيل الخيار 3 والتخلي عن اعتراضي على إدخال كلمة رئيسية مؤقتة legacy_mode=False (ولكن أيضًا لست متأكدًا تمامًا من أنها تستحق ذلك ، لأن هذه ستكون الحالة الوحيدة * حيث تكون هذه الكلمة الرئيسية في الواقع بحاجة)

* هذه الحالة فقط = بيانات عدد صحيح مع فئات مستنبطة ليست نطاقًا متتاليًا ، وحيث لا يمكنك / لا تريد تعيين الفئات يدويًا أو تعيين handle_unknown للتجاهل.

آسف على كل النص الطويل ، لكنه معقد للغاية :)

نحن نتحدث فقط عن الحالة التي تكون فيها n_values ​​غير محددة ، أليس كذلك؟

أنا بخير مع 1. ، ولن يكون أكثر تكلفة ، منذ السيارات
يحتاج بالفعل لفحص مجموعة التسميات. يمكنني أيضا أن أقبل ، ل
البساطة ، البديل 3. كان ذلك مجرد "OneHotEncoder يعمل في الإرث
الوضع. عيّن الفئات = "تلقائي" لسلوك مختلف قليلاً بدون ملف
تحذير."

نحن نتحدث فقط عن الحالة التي تكون فيها n_values ​​غير محددة ، أليس كذلك؟

نعم (الحالة الأخرى يمكن ترجمتها بسهولة categories المكافئة لها ، مع تحذير من الإيقاف ، وبدون اختلاف في السلوك الجديد والقديم)

البديل 3. كان فقط "OneHotEncoder يعمل في الوضع القديم. عيّن الفئات = 'تلقائي' لسلوك مختلف قليلاً بدون تحذير."

آه ، هذا يبدو كفكرة جيدة! (بصرف النظر عما إذا كان الكشف عن حالة الفئات المتتالية أم لا). لذلك قمنا بتعيين الإعداد الافتراضي في الكود categories إلى None (بدون تغيير دلالاته الافتراضية) ، لذلك نعرف ما إذا كان المستخدم قد حددها بشكل صريح ، وبهذه الطريقة تكون طريقة لطيفة للإشارة إلى legacy_mode=False بدون الحاجة إلى هذه الكلمة الأساسية الإضافية.

نعم ، ولكن فقط إذا أردنا التحذير في كل مرة يستخدمها شخص ما دون المرور
التصنيفات. إنه نهج التنفيذ الرخيص ، لكنه قد يكون كذلك
الإسهاب بلا داع للمستخدمين ، وهذا هو السبب في أنني أفضل 1 إذا كان
يمكن القيام به ببساطة.

ما الجحيم جديدة هو هذا :-/

أو يمكننا تسمية الجديد DummyEncoder ؛) (على الرغم من أن هذا يتعارض قليلاً مع DummyClassifier)

amueller لا تقرأ كل ما ورد أعلاه!
كنت أخطط للتو لتقديم ملخص لطيف للقراء الجدد حول هذا العدد. المناقشة أعلاه معقدة للغاية (أيضًا لأنني ما زلت لا أفهم تمامًا السلوك المعقد الحالي لـ OneHotEncoder ... :-))

أو يمكننا تسمية DummyEncoder الجديد ؛)

أعتقد أن GaelVaroquaux كان ضد ذلك لأنه من المعروف أن "one-hot" هو هذا في المزيد من المجالات (ونحن نستخدم بالفعل "Dummy" لأشياء أخرى في scikit-Learn ...)

إعادة هذا من أجل الاتساق في التسمية لا يستحق كل هذا العناء. نحن لسنا متسقين في تسمية أي مكان. هل يمكنك تلخيص المناقشات التي أدت إلى ذلك؟

أعتقد أن "الدمية" هي ما يستخدمه الإحصائيون وما يستخدمه الباندا.

لا يزال المنشور الأعلى دقيقًا ويستحق القراءة ، ويلخص سبب عدم الاحتفاظ بـ CategoricalEncoder (وهذا لا يعني أننا بحاجة إلى استخدام OneHotEncoder بدلاً من DummyEncoder ، هذا سؤال منفصل)

قرأت المنشور الأعلى. هذا ما أشرت إليه عندما قلت "إعادة هذا من أجل الاتساق لا يستحق كل هذا العناء".

القضايا التي تم فتحها

هل يمكن ان توضح ذلك؟

"إعادة هذا من أجل الاتساق لا يستحق كل هذا العناء"

مع الاتساق ، هل تشير إلى مخطط التسمية "ما يقبله" مقابل "ما يفعله"؟ إذا كان الأمر كذلك ، فهذا سبب بسيط فقط. بالنسبة لي ، يتعلق الأمر بشكل أساسي بقابلية التوسع في إضافة المزيد من الميزات إلى فئة واحدة.

القضايا التي تم فتحها

كانت لدينا مشكلة حول كيفية التعامل مع القيم المفقودة (https://github.com/scikit-learn/scikit-learn/issues/10465) ، ولهذا قد ترغب في سلوك مختلف للترميز الترتيبي والتشفير الساخن (أو لا جميع الخيارات صالحة لكليهما ..). لدينا بالفعل handle_unknown والذي هو مناسب فقط للتشفير الساخن واحد وليس للترتيب الترتيبي. وكان هناك https://github.com/scikit-learn/scikit-learn/issues/10518 حول ترجيح الميزة لتشفير onehot ، ولكن أيضًا غير مناسب للترتيب (لم تكن هذه المشكلة في النهاية مشكلة ، كما يمكنك أن تفعل الترجيح باستخدام وسيطة ColumnTransformer transformer_weights). ولدينا أيضًا طلب الميزة لإضافة شيء مثل drop_first لـ one-hot ، وهو مرة أخرى غير مناسب للترميز الترتيبي.

لا أرى كيف سيساعد التغيير المقترح في القيم المفقودة كثيرًا. ووجود خيارات غير متوافقة هو أمر يحدث غالبًا في scikit-Learn. ليس مثاليا ، ولكن أيضا ليس صفقة كبيرة imho.

لا أرى كيف سيساعد التغيير المقترح في القيم المفقودة كثيرًا.

إنه لا يساعد على هذا النحو ، ولكنه يجعل الأمر أقل تعقيدًا أن يكون لديك خيارات محددة مصممة خصيصًا لأنواع الترميز المختلفة.

ووجود خيارات غير متوافقة هو أمر يحدث غالبًا في scikit-Learn. ليس مثاليا ، ولكن أيضا ليس صفقة كبيرة imho.

في الوقت الحالي لا يزال الأمر على ما يرام بالتأكيد ، لا يوجد الكثير من الخيارات غير المتوافقة (ولكن أيضًا جزئيًا لأنني قمت بنقل sparse=True/False إلى الخيار encoding ). لكن السؤال هو إلى أي مدى نريد توسيع وظيفة التشفير في scikit-Learn في المستقبل. وهو بالطبع سؤال يصعب الإجابة عليه الآن .
لدينا بالفعل علاقات عامة لـ "الترميز الأحادي". ألا يجب إضافة هذا إلى CategoricalEncoder بدلاً من إضافة فئة جديدة UnaryEncoder؟ وماذا لو أراد شخص ما إضافة "تشفير ثنائي"؟ أو "(يعني) الهدف التشفير"؟

"متوسط ​​الهدف التشفير" هو CountTransformer ، هناك علاقات عامة لذلك ؛)

هل لديك وصلة لذلك؟ البحث عن "CountTransformer" لا يعطي أية نتائج

آسف ، CountFeaturizer # 9614

إنه مرتبط بالتأكيد ، ولكنه ليس بالضبط ترميز مستهدف متوسط. كما أنها تضيف أعمدة ، لا تحل محلها ، لذلك لن تعمل بعد خارج الصندوق للبيانات الفئوية للسلسلة (ولكن هذا هو المزيد من التعليقات على ذلك العلاقات العامة ، وليس للمناقشة هنا).

لماذا لا يعني ترميز الهدف؟ لكن نعم ، دعونا لا نحول الكثير هنا ؛)

لذا ، كملخص للأسئلة الفعلية نحتاج إلى الإجابة (بهذا الترتيب!):

1. هل نحتفظ بـ CategoricalEncoder ؟ إذا لم يكن الأمر كذلك ، فإن الفكرة هي تقسيمها إلى فئات مختلفة ، فئة واحدة لكل نوع من أنواع الترميز (حاليًا "onehot" و "الترميز الترتيبي").

2. إذا قمنا بالتقسيم إلى فئات متعددة ، فيمكننا (بشكل مثالي؟) استخدام OneHotEncoder لتشفير "onehot" ، ولكن هذه الفئة موجودة بالفعل. لذا ، هل نقوم بدمج تشفير "onehot" الجديد (الذي يدعم السلاسل وله معلمات مختلفة) في فئة OneHotEncoder الحالية؟ أم نختار اسمًا آخر؟ (مثل DummyEncoder)

3. إذا اخترنا الاندماج في OneHotEncoder الحالي ، فهل نحن موافقون على العواقب التالية: نحن نتجاهل مجموعة من الكلمات الرئيسية / سمات OneHotEncoder ، وحالة استخدام محددة (تجاهل القيم غير المرئية تلقائيًا ضمن نطاق القيم المرئية) لن يكون ممكنًا بعد فترة الإيقاف.

كانت معظم المناقشة أعلاه تدور حول السؤال 3 (التفاصيل المعقدة لكيفية دمج CategoricalEncoder (الترميز = 'onehot') في OneHotEncoder). لكن دعنا أولاً نتفق على قرار يتعلق بالسؤالين الأولين.

العامل الآخر بالنسبة لي هو أن الجميع يعتقد أن الوضع التلقائي الحالي في
OneHotEncoder غريب. تنفيذه هو تحويل coo إلى csr أيضًا
عجيب. إنه يستحق إعادة التصميم. وإخبار الناس "إذا كنت تريد واحدًا ساخنًا
ترميز السلاسل ، انتقل إلى CategoricalEncoder بدلاً من ذلك "أمر محرج ، لأن OHE
مخصص بالفعل للفئات ...

hrm. أعتقد أننا احتفظنا بـ OneHotEncoder لأنه أكثر كفاءة عندما يمكن استخدامه ... من الناحية المثالية ، سنتخلص من جميع السلوكيات الغريبة. كنت أرغب في إهماله ولكن بعد ذلك لم ...

كنت أرغب في إهماله ولكن بعد ذلك لم ...

في POC PR (https://github.com/scikit-learn/scikit-learn/pull/10523) ، قمت بإهمال كل شيء تقريبًا في OneHotEncoder ، باستثناء اسمه ...

إنه ليس أكثر كفاءة. وإذا كان لدى LabelEncoder مسارات سريعة لـ ints
في النطاق [0 ، n_values-1] ، إذا كان هناك ما يبرر ذلك ، فسيكون ذلك جيدًا بدرجة كافية.

amueller ، هل اقتنعت المشكلة بأننا نريد في النهاية معلمات إضافية مختلفة (مثل drop_first ، معالجة nan) اعتمادًا على التشفير ، وهذا يبرر وجود برنامج تشفير منفصل مختلف لكل تنسيق ترميز؟

سأحاول النظر إلى هذا في عطلة الربيع بعد أسبوعين ، حسنًا؟ لست متأكدًا مما إذا كان لدي وقت قبل ذلك: - /

آمل ألا يكون هذا هو المكان الخطأ الذي تسأل فيه ولكن ماذا يفعل التنفيذ الحالي بالجداول المختلطة الفئوية وغير الفئوية في عمود واحد؟ أخذ المثال من 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 نعم بمعنى ما عدا ب
إلتواء. لنفترض أنني أشك في أن بعض القيم من 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 للمشكلة المتعلقة بـ NaNs كفئة منفصلة ، راجع https://github.com/scikit-learn/scikit-learn/issues/10465
إذا كنت ترغب في مزيد من المناقشة بشأن التقدير غير الخطي المحدد أو الترميز المختلط للأرقام / السلسلة ، فلا تتردد في فتح مشكلة جديدة. ولكني ترغب في إبقاء هذا يركز على المشكلة الأصلية ، أي التسمية والتنظيم في فئات مختلفة من CategoricalEncoder / OneHotEncoder.

سأحاول النظر إلى هذا في عطلة الربيع بعد أسبوعين ، حسنًا؟ لست متأكدًا مما إذا كان لدي وقت قبل ذلك: - /

amueller هذا جيد. لن يكون لدي الوقت في الأسبوعين المقبلين للعمل على العلاقات العامة التي تم حظرها من قبل هذا على أي حال. بعد ذلك يجب أن يكون لدي الوقت مرة أخرى للعمل على ذلك.

amueller هل كان لديك الوقت لإلقاء نظرة على هذا؟

amueller ، هل أنت موافق على ذلك فأنا أمضي قدمًا في العمل على العلاقات العامة لتقسيم CategoricalEncoder في OrdinalEncoder و OneHotEncoder (ومع إهمال الحجج الحالية لـ OneHotEncoder)؟

آسف على التغيب. يبدو جيدًا ، ولكن هل يمكنك منحني أسبوعين حتى أتمكن بالفعل من المراجعة؟ شكرا!

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 ، جاهز للمراجعة

سأقول بحذر أنني عدت ؛)

IMHO أهم شيء هو واجهة برمجة التطبيقات العالمية (أي المعلمات وأنماط السلوك b) لجميع أجهزة التشفير التي نناقشها

PS https://github.com/scikit-learn-contrib/categorical-encoding ؟

في الحزمة category_encoders ، تحتوي جميع برامج التشفير على وسيطة cols ، على غرار categorical_features في OneHotEncoder القديم (على الرغم من أنها لا تقبل نفس النوع من القيم بالضبط). انظر على سبيل المثال http://contrib.scikit-learn.org/categorical-encoding/onehot.html
هذا مرتبط بالمناقشة الحالية التي نجريها في https://github.com/scikit-learn/scikit-learn/pull/10523 حول إهمال categorical_features أم لا.

بالنسبة للبقية ، أعتقد أنه لا توجد كلمات رئيسية متضاربة حقًا (لديهم بعض الكلمات الأخرى الخاصة بإطارات البيانات التي لن نضيفها إلى sklearn في هذه المرحلة). تتوافق تسمية OneHotEncoder و OrdinalEncoder على الأقل مع الحزمة category_encoders .