Scikit-learn: اقتراح: إضافة دعم للانحدار اللوجستي غير المعاقب

عليك تزييفها عن طريق ضبط C في LogisticRegression على عدد كبير

ما هي مشكلة هذا النهج؟

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

لقد لاحظت أن تعيين C مرتفعًا جدًا ، كما في ما يلي ، سيؤدي إلى توقف LogisticRegression.fit . لكنني لا أعرف ما إذا كان هذا خطأ أو مجرد خاصية متأصلة في الخوارزمية وتنفيذها على كمبيوتر 64 بت.

import numpy as np
from sklearn.linear_model import LogisticRegression

x = np.matrix([0, 0, 0, 0,  1, 1, 1, 1]).T
y =           [1, 0, 0, 0,  1, 1, 1, 0]

m = LogisticRegression(C = 1e200)
m.fit(x, y)
print m.intercept_, m.coef_

لقد لاحظت أن إعداد C عاليًا جدًا ، كما في ما يلي ، سيؤدي إلى تعليق LogisticRegression.fit

نعم ، هذا أمر متوقع حيث تصبح المشكلة في وضع سيء عندما تكون C كبيرة. المحللون التكراريون بطيئون مع مشاكل غير صحيحة.

في مثالك ، تستغرق الخوارزمية وقتًا طويلاً للوصول إلى التفاوت المطلوب. تحتاج إما إلى زيادة tol أو الرمز الثابت max_iter .

mblondel هل هناك بديل لـ "
لن تحصل بالضبط على الخيار غير النظامي ، أليس كذلك؟

Kodiologist لماذا تريد هذا؟

أنت تسأل لماذا أريد أن أفعل الانحدار اللوجستي دون تنظيم؟ لأنه (1) في بعض الأحيان تكون العينة كبيرة بما يكفي بما يتناسب مع عدد الميزات التي لن يشتريها التنظيم أي شيء و (2) في بعض الأحيان تكون المعاملات الأكثر ملاءمة مهمة ، بدلاً من تعظيم الدقة التنبؤية.

نعم ، كان هذا سؤالي.

(1) ليس صحيحا. سيشتري لك دائمًا حلًا أسرع.

(2) هو أكثر في مجالات التحليل الإحصائي ، وهو ليس في الحقيقة محور scikit-Learn. أعتقد أنه يمكننا إضافة هذا ولكني لا أعرف ما هو الحل الذي سنستخدمه. بصفتي شخصًا غير إحصائي ، أتساءل ما هي فائدة أي معاملات تتغير مع القليل من التنظيم.

لا أستطيع أن أقول الكثير عن (1) لأن الحساب ليس موطن قوتي. بالنسبة لـ (2) ، أنا محلل بيانات مع خلفية في الإحصاء. أعلم أن scikit-Learn يركز على التعلم الآلي التقليدي ، لكنه في رأيي أفضل حزمة Python لتحليل البيانات في الوقت الحالي ، وأعتقد أنها ستستفيد من عدم تقييد نفسها كثيرًا. (أعتقد أيضًا ، باتباع لاري واسرمان وأندرو جيلمان ، أن الإحصاء والتعلم الآلي سيستفيدان بشكل متبادل من التداخل أكثر ، لكن أعتقد أن هذا هو العلبة الخاصة به من الديدان.) ستتغير جميع المعاملات مع التنظيم ؛ هذا ما يفعله التنظيم.

أنا لا أعارض إضافة أداة حل بدون تسوية. يمكننا التحقق مما سيكون جيدًا ، أو مجرد الكفالة واستخدام l-bfgs والتحقق مسبقًا مما إذا كان غير مشروط؟

نعم ، كل المعاملات تتغير مع التنظيم. أنا فقط أشعر بالفضول بصدق بشأن ما تريد القيام به معهم بعد ذلك.

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

أم نماذج دولة؟

ما هي الحلول التي تقترح تنفيذها؟ كيف سيكون ذلك مختلفًا عن المحاليل التي لدينا بالفعل مع C -> infty؟

ما هي الحلول التي تقترح تنفيذها؟ كيف سيكون ذلك مختلفًا عن المحاليل التي لدينا بالفعل مع C -> infty؟

يمكنك محاولة البحث في R أو statsmodels للأفكار. لست على دراية بأساليبهم ، لكنها سريعة بشكل معقول ولا تستخدم أي تنظيم على الإطلاق.

نعم ، تقوم statsmodels بالمهمة أيضًا إذا كنت تستخدم خوارزمية QR لعكس المصفوفة. حالة الاستخدام الخاصة بي تدور حول إمكانية تفسير النموذج. بالنسبة للأداء ، سأستخدم بالتأكيد التنظيم.

لا أعتقد أننا بحاجة إلى إضافة أي محلل جديد ... لا يتمتع الانحدار اللوجستي بحل مغلق ، مما يعني أن statsmodel يجب أن يستخدم حلًا تكراريًا من نوع ما أيضًا (تخميني سيكون المربعات الصغرى المعاد وزنها التكرارية ، ولكن أنا لم تحقق). يجب أن يعمل إعداد C=np.inf (أو ما يعادله alpha = 0 ) من حيث المبدأ مع الحلول الحالية لدينا. توصيتي بالتبديل إلى L-BFGS أو Newton-CG solver ، حيث يمكن أن يكون liblinear بطيئًا جدًا في هذا الإعداد. ربما يمكننا إضافة خيار solver="auto" والتبديل تلقائيًا إلى أحد هذه الخيارات عند C=np.inf أو ما يعادله penalty="none" ؟

نحن نغير الحل الافتراضي إلى lbfgs في # 10001 fwiw

للأشخاص الذين يريدون حقًا الانحدار اللوجستي غير المنظم (مثلي). لقد كنت مضطرًا لتسوية استخدام statsmodels وإنشاء فصل دراسي يحاكي SKLearn API.

أي تحديثات على هذا؟ هذا مانع كبير لرغبي في التوصية بـ scikit-Learn للناس. كما أنه ليس من الواضح على الإطلاق للأشخاص القادمين من مكتبات أخرى أن scikit-Learn يقوم بالتنظيم افتراضيًا وأنه لا توجد طريقة لتعطيله.

shermstats تقترح كيفية تحسين التوثيق على ذلك؟ أوافق على أنه قد لا يكون واضحًا جدًا.
هل تسمح l-bfgs C=np.inf ؟

يمكنك تحديد C=np.inf ، على الرغم من أنها ستعطيك نفس النتيجة مثل C=large value . في المثال الذي جربته ، كان مناسبًا بشكل أفضل من statsmodel وفشل statsmodel في التقارب مع معظم البذور العشوائية الأخرى:

from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression
import statsmodels.api as sm

X, y = make_classification(random_state=2)
lr = LogisticRegression(C=np.inf, solver='lbfgs').fit(X, y)


logit = sm.Logit(y, X)
res = logit.fit()

Optimization terminated successfully.
         Current function value: 0.167162
         Iterations 10

from sklearn.metrics import log_loss
log_loss(y, lr.predict_proba(X))
log_loss(y, res.predict(X))

0.16197793224715606
0.16716164149746823

لذلك أود أن أزعم أننا يجب أن نوثق فقط أنه يمكنك الحصول على نموذج غير معاقَب عن طريق تعيين C كبيرة أو np.inf.

أقترح إضافة إلى docstring ودليل المستخدم
"يتم معاقبة نموذج LogisticRegregression افتراضيًا. يمكنك الحصول على نموذج غير مُعاقب عن طريق تعيين C = np.inf و solver = 'lbfgs'."

أعطت ملاءمة أفضل من statsmodel وفشل statsmodel في التقارب مع معظم البذور العشوائية الأخرى

R's glm أكثر نضجًا وقد تجعل المقارنة أفضل.

أقترح إضافة إلى docstring ودليل المستخدم
"يتم معاقبة نموذج LogisticRegregression افتراضيًا. يمكنك الحصول على نموذج غير مُعاقب عن طريق تعيين C = np.inf و solver = 'lbfgs'."

لماذا لا تضيف السماح penalty = "none" a la SGDClassifier ؟

Kodiologist أنا لا أعارض إضافة penalty="none" لكني لست متأكدًا من فائدة إضافة خيار فائض عن الحاجة.
وأعتقد أننا نرحب بمقارنات مع glm. لست على دراية كبيرة بـ glm ، لذا ربما لست شخصًا جيدًا لإجراء المقارنة. ومع ذلك ، فإننا نقوم بتحسين فقدان السجل ، لذا يجب ألا يكون هناك فرق. ربما يطبقون أدوات حل مختلفة ، لذا فإن وجود معيار معياري سيكون أمرًا رائعًا.

أنا لا أعارض إضافة penalty="none" لكنني لست متأكدًا من فائدة إضافة خيار فائض عن الحاجة.

1. يصبح من الواضح كيفية الحصول على نموذج غير معاقبة.
2. يصبح من الواضح للقارئ ما هو الكود الذي يستخدم نموذجًا غير خاضع لعقوبة يحاول القيام به.
3. يسمح لـ sklearn بتغيير تنفيذها للنماذج غير النظامية في المستقبل دون كسر كود الأشخاص.

إذا كنت تشعر أنها تضيف إلى قابلية الاكتشاف ، فيمكننا إضافتها ، و 3 هي نقطة صالحة (على الرغم من أننا لا نستطيع في الواقع تغيير ذلك بدون إهمال على الأرجح ، انظر التغيير الحالي للحل).
هل تريد ارسال PR؟

ليس لدي ملابس مستديرة لذلك ؛ آسف.

Kodiologist على الأقل لقد علمتني لغة لم أكن أعرف عنها ؛)

لذا افتح للمساهمين: أضف penalty='none' كخيار. من المحتمل أيضًا التحقق من المحاليل التي تدعم هذا / تكون فعالة مع هذا (من المحتمل ألا يكون liblinear) وتقتصر على تلك الحلول.

أقترح إضافة إلى docstring ودليل المستخدم
"يتم معاقبة نموذج LogisticRegregression افتراضيًا. يمكنك الحصول على نموذج غير مُعاقب عن طريق تعيين C = np.inf و solver = 'lbfgs'."

هذا يبدو معقولا بالنسبة لي. أود أيضًا أن أقترح كتابة الجملة الأولى بالخط العريض لأنها أمر مثير للدهشة للأشخاص القادمين من بيئات أخرى لتعلم الآلة أو تحليل البيانات.

shermstats لذا اقترح Kodiologist إضافة penalty="none" لجعله أكثر وضوحًا ، والذي سيكون مجرد اسم مستعار لـ C=np.inf . من المنطقي بالنسبة لي أن أجعل هذا أكثر وضوحًا بهذه الطريقة. هل لديك أفكار حول ذلك؟
ثم سيكون هذا ما هو موجود في الوثائق. وأنا أوافق على أن الجرأة قد تكون فكرة جيدة.
أعتقد أنه بالنسبة لشخص لديه خلفية ML ، هذا متوقع (ربما؟) ، بالنسبة لشخص لديه خلفية إحصائية ، يبدو هذا مفاجئًا للغاية.

بالضبط! لدي خلفية إحصائية وعملت مع العديد من الإحصائيات من الأشخاص القادمين من R أو حتى واجهات الإشارة والنقر ، وهذا السلوك يثير الدهشة للغاية بالنسبة لنا. أعتقد الآن أن penalty=None (لست متأكدًا من "none" مقابل None ) هو حل جيد. في المستقبل ، يجب أن يكون لدينا حل منفصل يتم استدعاؤه تلقائيًا للانحدار اللوجستي غير المعاقب لمنع المشكلات التي وصفها mblondel .

عذرا ، أي قضية تقصد؟ نحن ننتقل إلى l-bfgs افتراضيًا ، ويمكننا أيضًا التبديل داخليًا إلى l-bfgs تلقائيًا إذا حدد شخص ما penalty='none' (غالبًا لا شيء هو رمز مميز نستخدمه للمعلمات المهملة ، لكننا توقفنا القيام بذلك. لا يزال "لا شيء" سيكون أكثر اتساقًا مع بقية المكتبة).
نحتاج إلى solver="auto" أي حال ، لذا لا ينبغي أن يكون تغيير الحل بناءً على العقوبة مشكلة.

هذه المشكلة ، التي تشير إلى أن الخوارزمية التكرارية أصبحت بطيئة جدًا بالنسبة لـ C. يبدو أيضًا أن penalty='none' هو الطريقة الصحيحة للتعامل مع هذا الأمر.

shermstats نعم ، مع l-bfgs لا يبدو أن هذه مشكلة. ومع ذلك ، لم أقم بإجراء معايير واسعة النطاق ، ولن يكون لدي وقت للقيام بذلك. إذا أراد أي شخص تنفيذ المعايير ، فسيكون ذلك مفيدًا جدًا.

إذا تم تضمين عقوبة = "لا شيء" ، أقترح إضافة نفس التحذير إلى دليل المستخدم حول colinear X كما في OLS (خاصة بالنسبة للميزات المشفرة الساخنة).