Scikit-learn: اقتراح: قم بإزالة التنبؤ من plot_confusion_matrix واجتاز فقط التسميات المتوقعة

يجب أن نبقى بالتأكيد متوافقين مع الإصدارات السابقة ، ولكن إضافة كلمة رئيسية y_pred arg تبدو معقولة بالنسبة لي. يجب أن نرفع خطأ إذا تم تمرير y_pred ولكن تم تمرير X أو المقدر أيضًا.

هل تريد إرسال PRjhennrich ؟

لقد قدمت PR ، لكنني أعتقد أن هناك مشكلة حاليًا في CI ، لذا لم يتم تمريرها بعد.

أوافق على أنه يجب علينا دعم plot_XXX(y_true, y_pred) لتجنب حساب التنبؤ لعدة مرات.
لدينا أيضًا مشكلات مماثلة في plot_roc_curve و plot_precision_recall_curve.
يبدو أن إضافة y_pred مقبولة ، لكن بصراحة لا أعتقد أنه حل جيد.
بالنسبة لتلك الوظائف التي تقبل ** kwargs (على سبيل المثال ، plot_precision_recall_curve) ، يبدو أنه من المستحيل الحفاظ على التوافق مع الإصدارات السابقة؟

لماذا من المستحيل الحفاظ على التوافق مع الإصدارات السابقة؟ يبدو لي أن الاقتراح في # 15883 لا بأس به

لماذا من المستحيل الحفاظ على التوافق مع الإصدارات السابقة؟ يبدو لي أن الاقتراح في # 15883 لا بأس به

لأننا لا ندعم ** kwargs في plot_confusion_matrix. تضمين التغريدة

لماذا kwargs مشكلة؟

حسنًا ، هناك شيء مزعج آخر ، نحن ندعم ** kwargs في plot_roc_curve و plot_precision_recall_curve (و plot_partial_dependence) ، لكننا لا ندعمها في plot_confusion_matrix

لماذا kwargs مشكلة؟

إذا أضفنا المعامل الجديد قبل ** kwargs ، يمكننا الحفاظ على التوافق مع الإصدارات السابقة ، أليس كذلك؟

التغييرات في العلاقات العامة الخاصة بي متوافقة مع الإصدارات السابقة ولا يزال من الممكن إضافة ** kwargs. لكنني أتفق مع @ qinhanmin2014 ، فإن الحل الأنظف هو التخلص من estimator و X واستخدام الوسيطات الموضعية (y_true ، y_pred ، ...) التي تتوافق مع معظم أشياء أخرى من sklearn.

إذا أضفنا المعامل الجديد قبل ** kwargs ، يمكننا الحفاظ على التوافق مع الإصدارات السابقة ، أليس كذلك؟

نعم

حل أنظف بكثير ....

لسوء الحظ ، سيتطلب ذلك دورة إهمال (ما لم نجعلها سريعة جدًا في إصدار bugfix لكنني أشك في ذلك ...)

thomasjpfan ، أي سبب لتمرير المقدر كمدخل بدلاً من التنبؤات؟

شكرًا ، دعنا نضيف y_pred أولاً ، ** kwags هي مشكلة أخرى.

لسوء الحظ ، سيتطلب ذلك دورة إهمال (ما لم نجعلها سريعة جدًا في إصدار bugfix لكنني أشك في ذلك ...)

هذا يبدو مستحيلاً ، تنهد

thomasjpfan ، أي سبب لتمرير المقدر كمدخل بدلاً من التنبؤات؟

أوافق على أننا بحاجة إلى إعادة النظر في تصميم API الخاص بنا. حاول أيضًا استخدام pingamueller

إذا أراد المستخدم توفير جزء التخطيط الخاص به وتقديم مصفوفة الارتباك الخاصة به:

from sklearn.metrics import ConfusionMatrixDisplay
confusion_matrix = confusion_matrix(...)
display_labels = [...]

disp = ConfusionMatrixDisplay(confusion_matrix=confusion_matrix,
                              display_labels=display_labels)
disp.plot(...)

يمكن القيام بذلك بشكل مشابه لوظائف الرسم المتري الأخرى.

إن plot_confusion_matrix هو نوع من المصمم مثل المصححين القادرين على التعامل مع مخرجات المقدرات بشكل جيد. بمعنى آخر ، إنه غلاف ملائم للتفاعل مع ConfusionMatrixDisplay والمقدر.

بقبول المقدر أولاً ، توجد واجهة موحدة لوظائف الرسم. على سبيل المثال ، يقوم plot_partial_dependence بكل العمليات الحسابية اللازمة لإنشاء مخططات التبعية الجزئية ويمررها إلى PartialDependenceDisplay . لا يزال بإمكان المستخدم إنشاء PartialDependenceDisplay بنفسه ، ولكن في هذه الحالة سيكون أكثر احتياجًا.

على الرغم من أنني منفتح على وجود "مسار سريع" ، مما يسمح بتمرير y_pred إلى وظائف التخطيط ذات الصلة بالمقاييس ، والتي سيتم تمريرها مباشرة إلى confusion_matrix والسماح لها بالتعامل مع التحقق من الصحة.

يعد حساب التنبؤات اللازمة لبناء PDPs معقدًا للغاية. أيضًا ، هذه التنبؤات عادةً ما تكون غير قابلة للاستخدام على سبيل المثال المسجل أو المقياس. إنها مفيدة فقط لتخطيط PDP. لذلك من المنطقي في هذه الحالة قبول المقدر فقط في الاعتماد على القطعة الجزئية.

OTOH لمصفوفة الارتباك ، التوقعات هي في الحقيقة est.predict(X) .

لا أعتقد أننا نريد واجهة موحدة هنا. هذان نوعان مختلفان جدًا من حالات استخدام المدخلات

تحرير: بالإضافة إلى ذلك ، لا تحتاج PDPs المستندة إلى الشجرة حتى إلى تنبؤات على الإطلاق

هناك أشياء أخرى سنواجهها بدون المقدر. على سبيل المثال ، إذا كان plot_precision_recall_curve سيقبل y_pred ، فسيحتاج إلى pos_label لأنه لا يمكن استنتاجه بعد الآن. في هذه الحالة ، أفضل استخدام PrecisionRecallDisplay مباشرة وجعل المستخدم يحسب المعلمات اللازمة لإعادة بناء المؤامرة.

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

إذا قبلنا y_pred, y_true ، يصبح السؤال الآن "كيف يتصرف هذا المقياس مع هذه البيانات؟" قد يتم إنشاء هذه البيانات أو لا يتم إنشاؤها بواسطة نموذج.

صحيح أنه في هذه الحالة المحددة ، jhennrich يمكنك استخدام عرض ConfusionMatrixDisplay مباشرةً.

عيب واحد هو أنك تحتاج إلى تحديد display_labels لأنه لا يوجد لديه الافتراضي.

thomasjpfan هل تعتقد أنه يمكننا بشكل عام توفير

بالنسبة لبعض المعلمات ، مثل display_labels ، هناك قيمة افتراضية معقولة. يمكن أن تحتوي معلمات الكائن Display الأخرى على قيم افتراضية معقولة أيضًا. يجب توفير بعض المعلمات مع ذلك. على سبيل المثال ، يجب توفير confusion_matrix لـ ConfusionMatrixDisplay أو precision و recall لـ PrecisionRecallDisplay .

أحد الأنماط الكلاسيكية لهذا النوع من الأشياء هو تحديد:

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

لكن هذا ليس مصطلحًا اصطلاحيًا للغاية بالنسبة لـ scikit-Learn.

بدأت أشعر بالارتباك. الهدف من واجهة برمجة التطبيقات الحالية هو تجنب الحساب لمرات متعددة إذا أراد المستخدمون الرسم لعدة مرات ، ولكن إذا قبلنا y_true و y_pred ، فلا يزال المستخدمون لا يحتاجون إلى الحساب عدة مرات؟ (أعلم أن الأشياء مختلفة في PDP)

jnothman أن API جميلة المظهر!

@ qinhanmin2014 يعمل تمرير estimator, X, y أو y_true, y_pred تلبية واجهة برمجة التطبيقات "لا تحسب عدة مرات". في كلتا الحالتين ، يتم حساب مصفوفة الارتباك وتخزينها في الكائن Display .

الفرق بينهما هو حيث يبدأ حساب مصفوفة الارتباك. يمكن للمرء أن يفكر في تمرير y_pred كقيمة "محسوبة مسبقًا" للمقدر.

لذلك أعتقد أن y_true, y_pred أفضل من estimator, X, y (ليس في PDP بالطبع) ، لأنه في بعض الأحيان (غالبًا؟) لا يرغب المستخدمون فقط في رسم التنبؤات ، بل يريدون أيضًا تحليل التنبؤات. باستخدام واجهة برمجة التطبيقات الحالية ، سيحتاجون إلى حساب التنبؤات عدة مرات.

بالنسبة للمقاييس ، يمكنني رؤية التفضيل نحو استخدام y_true, y_pred على estimator, X, y . تخيل لو أن التخطيط للمقاييس يدعم فقط y_true, y_pred

est = # fit estimator

plot_partial_dependence(est, X, ...)

# if plot_confusion_matrix accepts `y_true, y_pred`
y_pred = est.predict(X)
plot_confusion_matrix(y_true, y_pred, ...)

# if plot_roc_curve supports `y_true, y_score`
y_score = est.predict_proba(X)[: , 1]
plot_roc_curve(y_true, y_score, ...)
plot_precision_recall_curve(y_true, y_score, ...)

تبدو واجهة برمجة التطبيقات حاليًا كما يلي:

est = # fit estimator
plot_partial_dependence(est, X, ...)
plot_confusion_matrix(est, X, y, ...)
plot_roc_curve(est, X, y, ...)

# this will call `predict_proba` again
plot_precision_recall_curve(est, X, y, ...)

أفضل أن يكون لدي واجهة برمجة تطبيقات تدعم كلا الخيارين (بطريقة ما).

بالنسبة للمقاييس ، يمكنني رؤية تفضيل استخدام y_true و y_pred على المقدر و X و y. تخيل لو أن التخطيط للمقاييس يدعم y_true و y_pred فقط

نعم ، هذا ما أعنيه.

أفضل أن يكون لدي واجهة برمجة تطبيقات تدعم كلا الخيارين (بطريقة ما).

أعتقد أن هذا حل عملي. الشيء المزعج هو أنه يمكننا فقط إضافة y_pred في النهاية (على سبيل المثال ، plot_confusion_matrix (مقدر ، X ، y_true ، ... ، y_pred))

نعم ، ستكون في النهاية وستبدو واجهة برمجة التطبيقات كما يلي:

plot_confusion_matrix(y_true=y_true, y_pred=y_pred, ...)

التي أعتقد أنني على ما يرام معها. هذا هو أساسًا العلاقات العامة https://github.com/scikit-learn/scikit-learn/pull/15883

نعم ، ستكون في النهاية وستبدو واجهة برمجة التطبيقات مثل هذه plot_confusion_matrix (y_true = y_true ، y_pred = y_pred ، ...)

أعتقد أنك تقصد أنه يجب علينا إضافة y_true وإزالة est & X ، أليس كذلك؟ اعتقد انه مستحيل؟ (لأنه يمكننا فقط إضافة y_pred في النهاية)

هل نريد حل هذا في 0.22.1؟ NicolasHugthomasjfox أعتقد أنه من المفيد أن يضع هذا في 0.22.1، ولكن في الوقت نفسه، يبدو أن هذا هو ميزة جديدة.

لا ، لا تضعه في 0.22.1. إنه انتهاك واضح لـ semver

@ qinhanmin2014 تبدو إضافة y_pred في النهاية أو إزالة est, X ميزة جديدة تنتمي إلى الإصدار التالي.

أعتقد أنك تقصد أنه يجب علينا إضافة y_true وإزالة est & X ، أليس كذلك؟ اعتقد انه مستحيل؟

في النهاية ، أفضل دعم وجود كلا الواجهتين ، لأن لهما حالة استخدام مختلفة قليلاً.

1. est, X أسهل في إجراء التحليل السريع ، لأن الوظيفة تتعامل مع اختيار وظيفة الاستجابة ، وتقسيم النتيجة وتمريرها إلى المقياس.
2. y_true, y_pred مخصص للمستخدمين الذين يفهمون كيفية التعامل مع المقياس الأساسي ولديهم التنبؤات المحفوظة بالفعل.

ما هي المشكلة في عمل https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -565489619؟

لم أقرأ سلسلة المحادثات هذه بالكامل ، ولكن إذا سمحنا للواجهة هنا ، فسنحتاج أيضًا إلى القيام بذلك مقابل plot_roc_curve حيث ستكون الواجهة مختلفة تمامًا بين تقديم التنبؤات وتوفير المُقدِّر (يحتاج المرء إلى وضع علامة على الآخر لا 'ر).
لذلك أعتقد أن السماح لكليهما في نفس الواجهة هو فكرة سيئة (سيمرر شخص ما pos_label عند اجتياز مقدر ويحصل على نتيجة لا يتوقعها).

ConfusionMatrixDisplay.from_estimator(...)
ConfusionMatrixDisplay.from_predictions(...)

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

إذا أردنا إضافة from_predictions إلى plot_roc_curve فعلينا أن نعكس الواجهة roc_curve بشكل أساسي. لذلك لا أعتقد أنه من السيء للغاية أن يقوم المستخدم باستدعاء الوظيفة roc_curve مباشرة ثم تمرير النتائج إلى كائن العرض.

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

amueller من الناحية الفنية ، أنت محق ، الحل الحالي لمشكلتي هو فقط استخدام ConfusionMatrixDisplay . ومع ذلك ، فمن غير المناسب حقًا استخدام:

• عليك تمرير التسميات صراحة
• عليك حساب مصفوفة الارتباك أولاً
• يجب عليك إنشاء كائن من الفصل ثم استدعاء طريقة plot

بالنسبة لجميع التطبيقات ، يمكنني التفكير في أن توقيع plot_confusion_matrix مع (y_true, y_pred, ...) سيكون أكثر ملاءمة مما لدينا حاليًا. في رأيي ، هناك الكثير من حالات الاستخدام التي تريد فيها حساب التنبؤات صراحة (على الرغم من أنني متأكد من أن وجهة نظري منحازة).

إذا كان لديك توقيع plot_confusion_matrix(y_true, y_pred) وترغب بالفعل في استخدامه على estimator ، x ، y بيانات ، فهناك فقط القليل جدًا من الكود الإضافي للكتابة : plot_confusion_matrix(y, estimator.predict(x)) .
بالمقارنة ، إذا كان لديك التوقيع الحالي وتريد الرسم من y_true و y_pred ، يجب عليك كتابة المزيد من التعليمات البرمجية.

في رأيي ، يجب أن يكون التوقيع plot_confusion_matrix(y_true, y_pred) افتراضيًا ويجب إنشاء وظيفة أخرى تتطلب estimator و x و y في الأعلى.

أخيرًا وليس آخرًا ، أنا بصراحة لا أفهم الفكرة الكامنة وراء فئة ConfusionMatrixDisplay . تحتوي الوظيفة على مُنشئ واحد وطريقة واحدة بالضبط ، لذلك كلما استخدمتها ، ينتهي بك الأمر بإنشاء مثيل واستدعاء الوظيفة plot . لا أفهم لماذا يجب أن يكون هذا فصلًا وليس مجرد وظيفة. هناك أيضًا فئات أخرى من *Display (PrecisionRecall ، ROC ، ...) ، لكن توقيعات المُنشئ و plot() مختلفة تمامًا ، لذلك لا يمكن تبديلها على أي حال.
ربما هذا يتجاوز نطاق هذه القضية.

تضمين التغريدة

إذا كان لديك توقيع plot_confusion_matrix (y_true ، y_pred) وتريد بالفعل استخدامه في المقدر ، بيانات x ، y ، فهناك فقط القليل جدًا من التعليمات البرمجية الإضافية التي يمكنك كتابتها: plot_confusion_matrix (y ، مقدر.التنبؤ (x)).

بالنسبة لحالة مصفوفة الارتباك ، من السهل تمرير estimator.predict إذا كان لدينا واجهة y_true, y_pred . من ناحية أخرى ، مقابل plot_roc_auc ، سيحتاج المستخدم إلى إجراء التقطيع:

y_pred = est.predict_proba(X)
plot_roc_curve(y_true, y_pred[:, 1])

# or
y_pred = est.decision_function(X)
plot_roc_curve(y_true, y_pred[:, 1])

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

الغرض من كائنات Display هو تخزين القيم المحسوبة للسماح للمستخدمين بالاتصال بـ plot عدة مرات دون إعادة الحساب. يمكن ملاحظة ذلك باستخدام plot_partial_dependence :

# Does expensive computation
disp = plot_partial_dependence(est, ...)

# change line color without needing to recompute partial dependence
disp.plot(line_kw={"c": "red"})

بصراحة ، أنا على الحياد بشأن هذه القضية. أنا +0.1 للتحرك نحو نسخ واجهة المقاييس لتخطيط المقاييس وإزالة واجهة est, X, y . : /

بالنسبة لحالة مصفوفة الارتباك ، من السهل تمرير المقدر. توقع ما إذا كان لدينا واجهة y_true ، y_pred. من ناحية أخرى ، بالنسبة لـ plot_roc_auc ، سيحتاج المستخدم إلى إجراء التقطيع:

نعم ، ولكن من خلال القيام بذلك ، نتجنب حساب التنبؤ لعدة مرات (على الرغم من أن التنبؤ غالبًا ما يكون غير مكلف للغاية)

ربما يكون حلًا عمليًا لدعم y_true, y_pred في plot_XXX (عند الاقتضاء) في 0.23.

jhennrich كيف ستفعل هذا دون تمرير التسميات صراحة؟ إذا كان من الممكن الاستدلال على الملصقات مما تم تقديمه confusion_matrix فسوف يفعل ذلك نيابة عنك.

لكنك حقًا على حق ، إنها ثلاثة أسطر بدلاً من سطر واحد.

في حالة confusion_matrix ، أميل إلى الموافقة على أن الحالة الأكثر شيوعًا قد تكون تجاوز y_true و y_pred .
السبب في أن الواجهة حاليًا هي الطريقة التي تتوافق مع وظائف الرسم المتري الأخرى. كما قال thomasjpfan ، فإن منحنى roc أقل وضوحًا للتخطيط.

في الوقت الحالي ، فإن الكود الخاص بتخطيط مصفوفة الارتباك ورسم منحنى roc هو نفسه. مع التغيير الذي اقترحته ، لن يكونا متماثلين بعد الآن ، ولن تكون هناك طريقة سهلة لجعلهما متماثلين.

السؤال هو ما إذا كان من الأفضل في هذه الحالة أن يكون لديك واجهات متسقة أو أن يكون لديك واجهة بسيطة.
jhennrich بالنسبة لي ، السؤال الحقيقي هو ما هي الواجهة الصحيحة لـ plot_roc_curve . هل لديك أفكار حول ذلك؟

thomasjpfan هل تميل إلى أخذ y_store للتخطيط لـ roc auc أيضًا؟

هناك بالتأكيد إيجابيات وسلبيات لاستخدام واجهة المسجل بدلاً من استخدام الواجهة المترية. ولكن بالنسبة للأشياء الأكثر تعقيدًا ، يكون استخدام واجهة المسجل أكثر أمانًا.

@ qinhanmin2014
أعتقد أنه سيكون من الجيد إضافة y_pred إلى plot_confusion_matrix . السؤال هو ما إذا كنا نريد إضافة y_score إلى plot_roc_curve و plot_precision_recall_curve . إذا فعلنا ذلك ، فعلينا أيضًا إضافة pos_label كما قلت أعلاه ، وستصبح الأمور أكثر تعقيدًا.

أرى ثلاث طرق للخروج من هذا:
أ) أضف فقط y_pred إلى plot_confusion_matrix ، لكن لا تضف y_score إلى plot_roc_curve إلخ. الجانب السلبي: مشكلة استدعاء predict_proba عدة مرات تظل موجودة لهذه المقاييس.
ب) اجعل من الأسهل استخدام الكائن Display مباشرةً (على الرغم من أنني لا أعرف حقًا كيف).
ج) أضف طريقة أو وظيفة أخرى تعكس الواجهة المترية. الجانب السلبي: سطح API أكبر.

لا أعتقد أن وجود وظيفة plot_X تعكس كلاً من واجهة المسجل والمترية في نفس الوقت فكرة جيدة بشكل عام.

أعتقد أنه سيكون من الرائع حل هذا بطريقة ما adrinjalali هل تريد مناقشته في الاجتماع القادم ربما؟

أحيانًا يكون لدي كوابيس حول هذه المسألة. ربما يمكننا إضافة طريقة ثابتة تأخذ ناتج المقياس مباشرة:

result = confusion_matrix(...)
ConfusionMatrixDisplay.from_metric(result).plot()

لمنحنى roc:

result = roc_curve(...)
RocCurveDisplay.from_metric(*result).plot()

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

أحيانًا يكون لدي كوابيس حول هذه المسألة.

أوه لا :(

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

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

لست متأكدًا من اختلاف الطريقة الثابتة التي تقترحها عن المُنشئ ، لكن ربما أغفل شيئًا ما.

مرحبًا ، لقد قمت للتو بالتصويت على المشكلة - باعتباري مستخدم sklearn منذ فترة طويلة ، وجدت واجهة برمجة التطبيقات الحالية لـ plot_confusion_matrix جدًا ... حسنًا ، محير. أنا حقًا أحب إضافته (أقل لصق للنسخ) ، لكن وظائف المقاييس تستخدم دائمًا مخطط (y_true ، y_pred) الذي هو أكثر مرونة وما اعتدت عليه بالفعل.

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

في حالتي ، ليس من المنطقي تمرير مقدر ، لأنه نموذج بطيء جدًا وأنا أفضل تحميل التنبؤات

شكرا لمساهمتك. إذا كانت واجهة برمجة التطبيقات الحالية مربكة ، فسيكون من المنطقي بشكل أكبر الانتقال إلى واجهة API مثل المقاييس والمرور بدورة إهمال مؤلمة.

أكبر قلق لدينا بشأن استخدام واجهة المقاييس هو:

لكنني أيضًا متأكد تمامًا من أن الأشخاص يستخدمون y_pred عندما يجب عليهم استخدام y_score ويحصلون على نتائج خاطئة لأن الواجهة لا تخبرك أنك بحاجة إلى القيام بشيء مختلف ولا أحد يقرأ المستندات على الإطلاق.

pzelasko ما هي أفكارك حول هذا الموضوع؟

thomasjpfan أنا أفهم المشكلة ، إنها مشكلة صعبة. ربما يكون الحل الوسط المعقول هو السماح فقط بحجج الكلمات الرئيسية لهذه الوظيفة (الآن لم تعد مضطرًا إلى دعم Python 2)؟ مثل: def plot_confusion_matrix(*, y_true, y_pred, ...) . لا يزال مختلفًا عن باقي المقاييس ، ولكن 1) له سبب وجيه لذلك ، 2) يستخدم على الأقل نفس نوع المدخلات مثل الوظائف الأخرى.

على أي حال ، أعلم سبب ترددك في إجراء أي تغييرات في واجهة برمجة التطبيقات ، ولهذا السبب اقترحت أن أذكر على الأقل الحل البديل في المستندات. (لقد قرأتها في الواقع عدة مرات وأنا أقدرها حقًا!)

الطريقة الحالية لاستخدام y_true و y_pred موضحة هنا: https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_display_object_visualization.html#create -confusionmatrixdisplay

أعلم أنني أمتد هنا ولكن ماذا عن هذا:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ...)

حيث يقبل المركز الثاني y_true كتنبؤات إذا كان estimator='precomputed .

إذا كنت ترغب في التوسع أكثر فأنا أفضل plot_confusion_matrix((estimator, X, y), ...) أو plot_confusion_matrix((y_true, y_pred), ...) لكنني لست متأكدًا من أنه يحل المشكلات التي أثارها amueller بخصوص واجهة برمجة التطبيقات التي تشبه المقاييس

هناك عدد قليل من الأدوات المساعدة الجديدة للتخطيط حيث يكون السماح بواجهة برمجة تطبيقات metric أمرًا منطقيًا حقًا:

• plot_prediction_error في https://github.com/scikit-learn/scikit-learn/pull/18020
• plot_calibration_curve في https://github.com/scikit-learn/scikit-learn/pull/17443 ( CClucyleeow )

أتفهم المشكلة التي ذكرها @ amueller بشأن الحاجة إلى تمرير pos_label وما إلى ذلك ، ولكن هذه ليست مشكلة لأي من الوظائف المذكورة أعلاه.

هل نحن بخير لدعم كل من scored و metrics API لهذين الاثنين؟ لا داعي للقلق بشأن التوافق مع الإصدارات السابقة هناك.

ما زلت مع اقتراحي باستخدام precomputed ، والذي نستخدمه عادة في المقدرات لدينا. في هذه الحالة ، سيكون التوقيع:

plot_confusion_matrix(estimator='precomputed', y_true, y_pred, ..., metric_kwargs=None)

سأقوم بتجميع العلاقات العامة لمعرفة كيف يبدو هذا.

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

(لكن فيما يتعلق بواجهة برمجة التطبيقات ، لا أعتقد أن "الحوسبة المسبقة" تساعد كثيرًا: ماذا نفعل حول X ؟ أعتقد أنه يجب علينا فقط الاحتفاظ بـ (y_pred) و (مقدر ، X) بشكل متبادل ، عن طريق الخطأ بشكل صحيح . وماذا يعني أيضًا أن يكون المقدر محسوبًا مسبقًا؟)

أو estimator='none' ، estimator='predictions' ، estimator='precomputed_predictions' ، ثم X يصبح y_pred أو y_score . يشبه الأمر تقريبًا الطريقة التي نتعامل بها مع المسافات المحسوبة مسبقًا باستخدام المقدرات X .

هل نحن بخير لدعم كل من scored و metrics API لهذين الاثنين؟

كيف سندعم كلا الخيارين؟ مع وظيفتين؟

كنت أود أيضًا:

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

والتي ستكون طريقتين.

يعتبر اقتراح Guillaume باستخدام tuples https://github.com/scikit-learn/scikit-learn/issues/15880#issuecomment -670590882 أحد الخيارات. أعتقد أنه كان من الممكن أن يكون الخيار الأفضل إذا بدأنا من هناك من البداية. لكنني أخشى أن استخدام مجموعات tuples يكسر التوافق مع المرافق الموجودة.

plot_XYZ(estimator=None, X=None, y=None, y_pred=None) مع الاستبعاد المتبادل هو خيار آخر ، وهو الخيار الذي أدافع عنه في الوقت الحالي.

أحب CalibrationDisplay.from_estimator(...) ، لكن كما لاحظ Andy ، سنحتاج إلى إزالة وظائف plot_XYZ بعد ذلك. قد يكون من المفيد النظر.

أعتقد أنه يمكننا الانتقال إلى الصفوف وإهمال السلوك الحالي. (طالما نوافق على استخدام المجموعات)

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

pzelaskojhennrich كيف تشعر حيال وجود اثنين من classmethods أو وظيفتين؟ أو هل تفضل وظيفة واحدة ، وهي فوضوية بعض الشيء في Python.

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

هل يمكننا إضافة تسمية مانع هنا؟ يبدو أنه يمنع التقدم في # 18020 و # 17443 (cccmarmo)

التسمية المانعة لحاصرات التحرير (الأشياء التي يجب إصلاحها تمامًا قبل الإصدار) ، وليس لحاصرات العلاقات العامة

آه من الجيد معرفة ذلك.

pzelaskojhennrich كيف تشعر حيال وجود اثنين من classmethods أو وظيفتين؟ أو هل تفضل وظيفة واحدة ، وهي فوضوية بعض الشيء في Python.

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

يعجبني أسلوب الفصل الثنائي أكثر من غيره ، خاصة نمط from_xxx - شيء مثل

CalibrationDisplay.from_estimator(...)
CalibrationDisplay.from_predictions(...)

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

• قدم طرق الفصل للقطع الموجودة حاليًا:

  • ConfusionMatrixDisplay
  • PrecisionRecallDisplay
  • RocCurveDisplay
  • DetCurveDisplay
  • PartialDependenceDisplay . بالنسبة لهذا الأسلوب ، لا نريد تقديم أسلوب الفصل الدراسي from_predictions لأنه لن يكون منطقيًا ، فنحن نريد فقط from_estimator .

• لجميع أجهزة العرض المذكورة أعلاه ، قم بإيقاف وظيفة plot_... المقابلة لها. لا نحتاج إلى إهمال plot_det_curve لأنه لم يتم إصداره بعد ، يمكننا إزالته فقط.

• بالنسبة إلى العلاقات العامة الجديدة مثل # 17443 و # 18020 ، يمكننا تنفيذ طرق الفصل على الفور بدلاً من تقديم وظيفة plot .

هذا قليل من العمل ولكن أعتقد أنه يمكننا إنجاز ذلك قبل 0.24 حتى يتمكن # 17443 و # 18020 من المضي قدمًا بالفعل.

أي اعتراضthomasjpfanjnothmanamuellerglemaitre؟

jhennrichpzelasko، هل تكون مهتمة في تقديم PR لإدخال أساليب الفئة في أحد الكائنات العرض؟

شكرا لاتخاذ القرار NicolasHug! سأصل إلى # 17443 (بعد انتظار الاعتراضات)

ليس لدي اعتراضات.

لا اعتراض كذلك.

سأعتني بالفصول الأخرى بعد ذلك وأقدم علاقاتي العامة المتوقفة.
lucyleeow في حال لم أفعل كل هؤلاء وأنت تبحث عن بعض العلاقات العامة ، ping me :)

أرغب في المساهمة ولكني منخرط في العديد من المشاريع في هذا الوقت. شكرا للاستماع إلى الاقتراحات!

يبدو جيدا :)