شكرا لفتح هذه القضية، بينغjnothmanamuellerGaelVaroquaux وفقا لمشبكة

لا يرتبط 8425 بمناطق القرار من المصنفات ،؟

أفضل نقل plot_tree و plot_partial_dependence إلى sklearn.plot وحل # 13335 في 0.21 (ربما أدخل وظيفة لرسم حدود القرار ، لأنها مهمة وليست سهلة للمبتدئين IMO). ماذا يعتقد الاخرون؟

للمساعدة في التحكم في نطاق sklearn.plot ، أقترح أننا نقوم بالتخطيط على مستوى المحاور فقط وليس على مستوى الشكل. سوف يمر المستخدم في المحاور ككلمة رئيسية. للتيسير ، سيكون الافتراضي للمحاور بلا. فقط في هذه الحالة ، ستنشئ وظيفة الرسم محاورًا / شكلًا للتخطيط عليها.

فكرة جيدة ، لكنها لا تتوافق مع الوظائف الحالية (plot_tree و plot_partial_dependence) ، أليس كذلك؟

هناك حالات تحتاج فيها إلى إخراج / تعديل شكل ، مثل
الحبكات الفرعية المتعددة (انظر المؤامرات ذات الواجهة البحرية وما إلى ذلك ، و upsetplot لـ
مثال). هل يمكنك إعطاء الأسباب التي تجعلك تريد قصره على المحاور؟

في الجمعة ، 15 مارس 2019 ، الساعة 2:19 صباحًا ، كتب هانمين تشين ، [email protected] :

شكرًا لفتح هذه المشكلة ، pingjnothman
https://github.com/jnothman amueller https://github.com/amueller
GaelVaroquaux https://github.com/GaelVaroquaux وفقًا لـ gitter

8425 https://github.com/scikit-learn/scikit-learn/issues/8425 ليس كذلك

المتعلقة مناطق القرار من المصنفات ،؟
أفضل نقل plot_tree و plot_partial_dependence إلى sklearn.plot و
حل # 13335 https://github.com/scikit-learn/scikit-learn/issues/13335
في 0.21 (ربما يتم تقديم وظيفة لرسم حدود القرار ، منذ ذلك الحين
إنها مهمة وليست سهلة للمبتدئين IMO). ماذا يعتقد الاخرون؟

للمساعدة في التحكم في نطاق sklearn.plot ، أقترح أننا نقوم بالتخطيط فقط
على مستوى المحاور وليس مستوى الشكل. سوف يمر المستخدم في المحاور
ككلمة رئيسية. للتيسير ، سيكون الافتراضي للمحاور بلا. فقط في
في هذه الحالة ، ستنشئ وظيفة الرسم محاور / شكل للتخطيط عليها.

فكرة جيدة ، لكنها لا تتوافق مع الوظائف الحالية (plot_tree و
plot_partial_dependence) ، أليس كذلك؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment-472914237 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAEz6y4ZcL4WftNY92wCoz19vqtXL9Njks5vWmiCgaJpZM4b0Oiz
.

فكرة جيدة ، لكنها لا تتوافق مع الوظائف الحالية (plot_tree و plot_partial_dependence) ، أليس كذلك؟

@ qinhanmin2014 plot_tree لا يبدو أنه يضبط الرقم. plot_partial_dependence بعمل العديد من المؤامرات بناءً على features . على الرغم من أنه يمكن إعادة بنائه في مخطط مستوى المحاور. سيحتاج المستخدم إلى الاتصال بـ plot_partial_dependence عدة مرات لإعطائه محاور (وميزات) مختلفة.

هل يمكنك إعطاء الأسباب التي تجعلك تريد قصره على المحاور؟

لدىjnothman Seaborn وثائق تفصل بوضوح بين مؤامرة "مستوى الشكل" و "مستوى المحاور". إذا تمكنا من توثيق هذا السلوك بشكل صحيح في scikit-Learn ، فمن الممكن أن يكون لدينا هذه المؤامرات "على مستوى الشكل". إن أكثر ما يقلقني بشأن المؤامرات "على مستوى الشكل" هو صعوبة صيانتها واختبارها. ستكون هناك عناصر من أحد المحاور قد تتداخل مع محاور أخرى. على الرغم من أنه يمكننا التغلب على هذا من خلال هيكلة الأرقام بطريقة لا يحدث فيها التداخل كثيرًا.

فيما يتعلق بالاختبار ، يمكننا السير في طريق البحر واختبار كائنات matplotlib مباشرة أو طريقة Yellowbrick حيث نقوم باختبار مستوى البكسل. أميل إلى تفضيل اختبار كائنات matplotlib.

2 سنتي:

• +1 لاحتواء وظائف الوصول إلى matplotlib في حزمة فرعية مشتركة ، أو في وحدة نمطية في كل حزمة فرعية (sklearn.linear_models.plot ، sklearn.ensemble.plot).

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

  أيضًا ، منذ وقت طويل ، كان هناك نقاش في النظام البيئي لإعطاء الخلفيات الأخرى للتخطيط كائنًا يشبه "المحاور" من أجل التوافق. لا أعرف إلى أين ذهب ذلك. لا يظهر البحث السريع في Google الكثير. الأقرب هو plotly.tools.mpl_to_plotly ، والذي لا يحتاج حقًا إلى هذا التقييد ، لذلك أعتقد أن هذه الحجة عبثية.

ربما تقدم وظيفة لرسم حدود القرار ، لأنها مهمة وليست سهلة للمبتدئين IMO

أوافق ولكني أعتقد أيضًا أن إظهار كيفية رسم النتائج للمستخدمين مثل حدود القرار هو أحد أهداف الأمثلة.

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

فيما يتعلق باسم الوحدة ، يعد IMO inspect أكثر تنوعًا من plot :

• لا يمكنني التفكير في أي مؤامرة ليست نوعًا من التفتيش
• # 12599 (الاعتماد الجزئي) يقدم بالفعل inspect

يعتبر فحص IMO أكثر تنوعًا من المؤامرة

لا يوجد رأي قوي ، سيتم التصويت +1 لكلا الاسمين. ربما تكون الحبكة أكثر وضوحًا؟

مرة أخرى ، أنا مهتم بإنشاء الوحدة الجديدة قبل 0.21 ونقل plot_tree و plot_partial_dependence هناك. من الناحية المثالية ، يجب أيضًا أن نتوصل إلى إجماع حول API (على سبيل المثال ، مستوى المحاور / مستوى الشكل).

نقطة أخرى لصالح inspect :

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

سأؤيد استخدام المحاور بدلاً من الأشكال ، كما هو مقترح (تنهد ، سأحتاج إلى تغيير PDPs مرة أخرى). من الأسهل علينا الدعم والاختبار. إنه عمل أكثر قليلاً للمستخدمين ، ولكنه يسمح أيضًا بمزيد من التحكم.

يعتبر فحص IMO أكثر تنوعًا من المؤامرة

لا يوجد رأي قوي ، سيتم التصويت +1 لكلا الاسمين. ربما تكون الحبكة أكثر وضوحًا؟

يتم تحميل "inspect" في Python (إنها وحدة نمطية في المكتبة القياسية). أنا
سيتجنب استخدام نفس الاسم.

مرة أخرى ، أنا مهتم بإنشاء الوحدة الجديدة قبل 0.21 ونقل plot_tree و plot_partial_dependence هناك. من الناحية المثالية ، يجب أيضًا أن نتوصل إلى إجماع حول API (على سبيل المثال ، مستوى المحاور / مستوى الشكل).

هذا لا ينبغي أن يؤخر 0.21. هدفنا هو إطلاق سراحه مبكرًا ، ونأمل
الافراج في وقت مبكر مرة أخرى.

يتم تحميل "inspect" في Python (إنها وحدة نمطية في المكتبة القياسية). أنا
سيتجنب استخدام نفس الاسم.

أقترح model_inspection . سارت الامور بشكل جيد مع اسمنا model_selection .

قد نرغب في فحص شيء ليس نموذجًا (مشفر ، معالج مسبق ، نتائج بحث الشبكة ...)

inspection إذن؟

هذه الأشياء هي أيضًا نماذج :)

اقتراح جايل لوحدة فرعية للحبكة العامة على كل حزمة فرعية يستحق
مع مراعاة.

FWIW ، أفضّل أيضًا plot على inspect ، نظرًا لأنه من السهل على معظم المستخدمين العثور عليه. من المرجح أن يحاول الأشخاص _ رسم_ نماذجهم أكثر من _inspect_ نماذجهم (عند البحث في محركات البحث على سبيل المثال ، أو النظر في خيارات الإكمال التلقائي الممكنة على IDE الخاص بهم).

اقتراح Gael لوحدة الحبكة الفرعية العامة على كل حزمة فرعية يستحق النظر فيه.

إذا كان الأمر كذلك ، فأين نضع plot_decision_boundary ؟

بخصوص # 12599 ، NicolasHug أشك في ما إذا كان يجب أن يكون partial_dependence في الوحدة الجديدة. (على سبيل المثال ، ensemble.partial_dependence + plot.plot_partial_dependence)

إذا كان الأمر كذلك ، فأين نضع قطعة الأرض؟

sklearn.plot؟

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

بخصوص # 12599 ، NicolasHug أشك فيما إذا كان الاعتماد الجزئي يجب أن يكون في الوحدة الجديدة. (على سبيل المثال ، ensemble.partial_dependence + plot.plot_partial_dependence)

أنا لا أفهم ما تقصد. # 12599 يتم إهمال ensemble.partial_dependence لصالح inspect.partial_dependence (بالطبع inspect عرضة للتغيير بناءً على هذه المناقشة). تختلف واجهة برمجة التطبيقات أيضًا بين التطبيقين.

أنا بخير مع plot ، أنا قلق فقط بشأن التداخل المرتفع المحتمل مع وحدة الفحص النهائية ، لكنني لن أدفعها أكثر :)

يجدر النظر في نموذج فرعي للقطاع العام على كل حزمة فرعية.

ولكن حتى الآن جميع أدوات التخطيط المقترحة (PDPs والمعايرة ومصفوفة الارتباك ومنطقة القرار) ليست خاصة بوحدة نمطية واحدة.

أنا لا أفهم ما تقصد. # 12599 يستبعد المجموعة.الاعتماد الجزئي لصالح التفتيش. تختلف واجهة برمجة التطبيقات أيضًا بين التطبيقين.

اعتذارات لم ألقي نظرة على هذه العلاقات العامة بالتفصيل. ربما inspect.partial_dependence + plot.plot_partial_dependence ؟

ربما تفقد.

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

لم يكن Gaël يقترح في وقت سابق sklearn.inspect.partial_dependence و
sklearn.inspect.plot.plot_partial_dependence (استبدل بعض الأسماء الأخرى
للتفتيش إذا كان ذلك مناسبًا)؟ أنا لا أمانع هذا.

ألم يقترح Gaël سابقًا sklearn.inspect.partial_dependence و sklearn.inspect.plot.plot_partial_dependence (استبدل اسمًا آخر للفحص إذا كان ذلك مناسبًا)؟

نعم ، لكني سألته أين نضع plot_decision_boundary ويبدو أنه غير رأيه؟

لمعلوماتك ، لقد قمت بتحديث PDP PR https://github.com/scikit-learn/scikit-learn/pull/12599 باتباع التوصيات أعلاه:

• partial_dependence في sklearn.model_inspection
• plot_partial_dependence في skearn.plot

المستندات هنا https://53182-843222-gh.circle-artifacts.com/0/doc/_changed.html

لاحظ أن دليل المستخدم يتضمن فقط الوحدة النمطية plot في الوقت الحالي. لا أعتقد أنه من المنطقي أن يكون لديك قسم دليل مستخدم يتحدث فقط عن model_inspection.partial_dependence ، نظرًا لأن قيود / سلوكه هو نفسه مثل plot_partial_dependence .

(هذا هو نوع التداخل الذي كنت قلقًا بشأنه)

بالطبع إذا كنت تعتقد أنه لا يزال من الأفضل أن يكون لديك أدلة مستخدم منفصلة مقابل partial_dependence و plot_partial_dependence ، سأفعل ذلك.

لمعلوماتك ، لقد قمت بتحديث PDP PR # 12599 باتباع التوصيات أعلاه:
الاعتماد الجزئي في sklearn.model_inspection
plot_partial_dependence موجود في skearn.plot

+1

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

+1

لذلك قررنا استخدام الاسم sklearn.plot؟

أجد أن sklearn.plot يستورد التبعيات من جميع أنحاء sklearn ليكون غريبًا بعض الشيء عندما نتجنب وضع الجميع في مساحة اسم الجذر.

إذا كنت تفضل sklearn.model_inspection.plot وتضع plot_partial_dependence() هناك؟

لا يوجد وحدة plot ، أنا بخير مع ذلك

أعتقد أنني أفضل ذلك. لا تعرف بعد كيف يتم تعميمها.

أعتقد أنني أفضل ذلك. لا تعرف بعد كيف يتم تعميمها.

طالما أنه يمكننا تحديد مكان مناسب لوضع أشياء مثل plot_decision_boundary ، سأصوت +1 لـ sklearn.XXX.plot .

هل هذا يحتاج إلى نوم؟ لا يبدو أننا نحرز تقدمًا كبيرًا

عذرًا ، قم بقراءة تعليق جويل لأنني لا أعتقد أنني أفضل ذلك ، آسف

هل هذا يحتاج إلى نوم؟ لا يبدو أننا نحرز تقدمًا كبيرًا

أنا بخير مع أي من الحلين ( sklearn.plot / sklearn.XXX.plot ). المشكلة الرئيسية هنا IMO هي أنه لا أحد يخبرني أين سنضع أشياء مثل plot_decision_boundary إذا استخدمنا sklearn.XXX.plot :)

sklearn.model_inspection.plot ؟

sklearn.model_inspection.plot؟

فكرة مثيرة للاهتمام ، سأصوت +1. ربما ليس من الجيد إلقاء كل الأشياء على sklearn.plot (https://github.com/rasbt/mlxtend ضع جميع وظائف التخطيط في وحدة واحدة).

لذا سندعم from sklearn.XXX.plot import plot_XXX ؟ هل سندعم from sklearn.XXX import plot_XXX ؟

أعتقد أن المتطلبات الصريحة لـ .plot في الاستيراد شيء ما
سعى آخرون هنا.

هناك أيضًا المعكوس من sklearn.plot.XXX import plot_YYY

أعتقد أن المطلب الصريح لـ .plot في الاستيراد هو شيء سعى إليه الآخرون هنا.

لذلك توصلنا إلى إجماع على استخدام sklearn.XXX.plot (الدعم فقط من sklearn.XXX.plot import plot_XXX )؟

هناك أيضًا المعكوس من sklearn.plot.XXX import plot_YYY

لا أستطيع أن أفهم.

هناك أيضًا المعكوس من sklearn.plot.XXX import plot_YYY

قصدت أنه يمكننا الحصول عليها
sklearn.plot.model_inspection.plot_partial_dependence بدلاً من
sklearn.model_inspection.plot.plot_partial_dependence. لست متأكدا إذا كان هذا
يوفر أي فائدة / وضوح.

قصدت أنه يمكننا الحصول عليها
sklearn.plot.model_inspection.plot_partial_dependence بدلاً من
sklearn.model_inspection.plot.plot_partial_dependence. لست متأكدا إذا كان هذا
يوفر أي فائدة / وضوح.

حتى الآن لدينا 3 خيارات:
(1) sklearn.plot.plot_YYY (على سبيل المثال ، sklearn.plot.plot_tree)
(2) sklearn.plot.XXX.plot_YYY (على سبيل المثال ، sklearn.plot.tree.plot_tree)
(3) sklearn.XXX.plot.plot_YYY (على سبيل المثال ، sklearn.tree.plot.plot_tree ، لا تدعم من sklearn.XXX import plot_YYY)
سأصوت +1 لجميع هذه الحلول.
أفضل اتخاذ القرار قبل 0.21 لتجنب إهمال sklearn.tree.plot_tree

لست متأكدًا من أنه يحتاج إلى نوم ولكن قد يكون من المفيد دعوة آراء حول
القائمة البريدية

لست متأكدًا من أنه يحتاج إلى نوم ولكن قد يكون من المفيد دعوة الآراء في القائمة البريدية

+1. يبدو أنه لا يندرج ضمن معايير SLEPs.

كما قلت في القائمة البريدية ، أعتقد أننا يجب أن نفكر أيضًا في "مكان حدوث العمل" أو كيف ستكون الواجهة. كان هذا بالفعل غير واضح تمامًا بالنسبة للاعتماد الجزئي.
هل يجب أن يقوم plot_partial_dependence بالاتصال بـ partial_dependence أو الحصول على ناتج partial_dependence كمدخل؟ هذه الأسئلة هي في الأساس سؤال صالح لجميع وظائف المؤامرة.
الاعتبار الرئيسي الذي ناقشه مع NicolasHug هو أن الحصول على plot_X call compute_X مناسب للمستخدم - طالما أنهم يريدون رسم الشيء مرة واحدة فقط. إذا لم يعجبهم الحبكة ويريدون تغيير شيء ما ، فإنهم يحتاجون إلى compute_X مرة أخرى ، وهو ما قد يكون مضيعة.

لذلك يمكننا إما

• تأخذ دائمًا نتيجة compute_X . الجانب السلبي: غير مريح وعرضة للخطأ: ما هو ترتيب الدقة والاستدعاء والعتبات مرة أخرى في دقة_استدعاء_المنحنى؟

• أخذ الإدخال دائمًا إلى compute_X واستدعاء compute_X من plot_X . الجانب السلبي: أنت بحاجة إلى إعادة حساب لكل قطعة أرض.

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

• اتخاذ القرار بناءً على تكلفة compute_X ، أما بالنسبة لمصفوفة الارتباك ومخططات الاعتماد الجزئي ومخططات المعايرة ، فنحن لا نهتم بتكلفة إعادة الحساب ، ولكن بالنسبة لمخططات الاعتماد الجزئي نقوم بذلك. الجانب السلبي: واجهة غير متسقة.

الاعتبار الرئيسي الذي ناقشه مع NicolasHug هو أن الحصول على استدعاء plot_X compute_X مناسب للمستخدم - طالما أنهم يريدون رسم الشيء مرة واحدة فقط. إذا لم يعجبهم الحبكة وأرادوا تغيير شيء ما ، فإنهم بحاجة إلى حساب X مرة أخرى ، والذي من المحتمل أن يكون مضيعة.

+1000. إنها مشكلة شائعة أراها في كود البحث.

من مشكلة التصميم ، فإنه ينتهك فصل MVC (متحذلق قليلاً ،
آسف).

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

لست متأكدًا مما تقصده بالنموذج المناسب. غالبًا ما يكون ناتج الحساب ليس نموذجًا مناسبًا. يمكننا تحديد كائنات لجميع نتائج الحساب ، بحيث يقوم partial_dependence بإرجاع كائن PartialDependence . أو حفنة. لكنها لا ترجع مقدرًا.

أوه ، سبب طرح هذا الأمر الآن: بدون هذا القرار ، ليس لدي أي فكرة عن شكل رمز المستخدم ، ولا أحب اتخاذ قرارات التسمية / واجهة برمجة التطبيقات دون أن أكون قادرًا على تدوين الأمثلة ؛)

إعادة كائن سيكون أمرًا رائعًا لا يشبه sklearn ، imho. ولكنه قد يحل مشكلة الموقع: يمكن أن يكون له طرق plot ؛)

غالبًا ما يكون ناتج الحساب ليس نموذجًا مناسبًا. يمكننا تحديد كائنات لجميع نتائج الحساب ، بحيث يُرجع هذا الاعتماد الجزئي كائن PartialDependence. أو حفنة. لكنها لا ترجع مقدرًا.

أخذت النقطة.

سيكون أحد الخيارات (عدم القول بأنه الأفضل) هو الحصول على جميع ملفات
تعيد دوال الحوسبة المجموعات المسماة وكل الحسابات المقابلة
وظائف تأخذ هذا. سيكون متسقًا إلى حد ما مع الحديث
الإضافات إلى مكتبة Python القياسية.

ولا أحب اتخاذ قرارات التسمية / واجهة برمجة التطبيقات دون التمكن من تدوين الأمثلة ؛)

انا مثلك.

لذلك إذا كانت العملية الحسابية باهظة الثمن ، فيمكننا إجراء الحساب خارج الوظيفة. إذا كان الأمر كذلك ، فإننا نعيد كائنًا وتأخذ وظيفة الرسم هذا الكائن كمدخل لها ، أليس كذلك؟ سأصوت +1.

وربما نحتاج إلى قضية أخرى لمناقشة هذا :)

فائدة اقتراح GaelVaroquaux هي أنه قد لا يتطلب من المستخدمين تغيير الكود الخاص بهم بسبب تفريغ tuple. لكن هذا لن ينجح إذا كان هناك كائن واحد معاد مثل confusion_matrix . لن تكون هناك ضرورة قصوى لـ tuple ولكن بعد ذلك تصبح الواجهة غير متناسقة إلى حد ما.

@ qinhanmin2014 إذا قمنا بإرجاع كائنات عشوائية ، يتعين علينا إهمال نوع الإرجاع لوظيفة في كل مرة نقوم فيها بإنشاء مساعد رسم. هذا يبدو وكأنه فوضى.

كانت لدي فكرة واحدة ، ثم فكرة ثانية أفضل:
1) أنشئ واجهة كائنية ثانية تستدعي الوظيفة الحالية ، وتخزن الكائن ، ولها طريقة الرسم ، مثل

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

هذا من شأنه أن يحل المشكلة ، لكنه قد يكرر بعض الواجهة وسيكون الأمر غير واضح بعض الشيء. في الواقع ، يمكن تنفيذ نفس المبدأ بطريقة أعتقد أنها أكثر سهولة:
2) اجعل الدالة plot_ بالعمل دائمًا ، واستخدم النتيجة لإنشاء مثيل لكائن يخزن النتيجة ويرسمها:

plot_confusion_matrix(y, y_pred)

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

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

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

لماذا يحتاج المستخدمون إلى رسم نفس البيانات مرة أخرى؟ amueller ضبط التنسيق؟

@ qinhanmin2014 نعم ، اجعل الخط أكبر ، قم بتغيير الألوان ،

@ qinhanmin2014 نعم ، اجعل الخط أكبر ، قم بتغيير الألوان ،

أشك فيما إذا كان من المفيد النظر في مشكلات التنسيق هذه هنا. يمكن للمستخدمين بدء جزء صغير من مجموعة البيانات؟

وسندعمamueller محاور التمرير ، بحيث يمكن للمستخدمين بسهولة ضبط الحبكة بعد أن يسموا وظائف التخطيط؟

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

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

نعم ، أعلم أنه قد يكون مفيدًا ، لكن المشكلة الرئيسية هنا هي أنه ليس لدينا طريقة نظيفة لدعم هذه الوظيفة ، وأعتقد أن معظم وظائف التخطيط لا تتطلب الكثير من الحسابات؟

يعجبني أننا نناقش هذا مع مزيد من التأريض ، لكن tbh أنا
ما زلنا غير مقتنعين تمامًا بأننا نحتاج حتى إلى قطعة أرض في الاستيراد
المسار على الإطلاق. بعد كل شيء ، يبدو أن لدينا plot_ كبادئة لـ
المهام. يتعلق السؤال أيضًا بـ plot_tree: لماذا يجب أن يكون
مفصولة عن رمز التصور النصي والنص الآخر؟

@ qinhanmin2014 لا أعتقد أن "ليس لدينا واجهة برمجة تطبيقات جيدة حتى الآن" هو سبب وجيه.
والاعتماد الجزئي وأهمية التقليب ومنحنيات التعلم ومنحنيات التحقق من الصحة ونتائج GridSearchCV و RandomizedSearchCV كلها أمثلة شائعة تتطلب الكثير من الحسابات. على الرغم من أن الشيء الواضح بالنسبة إلى gridsearchcv و randomizedsearchcv هو تمرير الكائن أو cv_results_ ، فإن القيام بالعمل داخل وظيفة الرسم في تلك الحالات يبدو غير منطقي. لست متأكدًا تمامًا من تعلم المنحنيات ومنحنيات التحقق من الصحة tbh.

jnothman أعتقد أن @ GaelVaroquaux أراد إبقاء تبعية matplotlib محصورة في وحدة نمطية وكان ذلك أحد الدوافع الرئيسية؟ ليس لدي أفكار متماسكة للغاية حول هذا حتى الآن.

والاعتماد الجزئي وأهمية التقليب ومنحنيات التعلم ومنحنيات التحقق من الصحة ونتائج GridSearchCV و RandomizedSearchCV كلها أمثلة شائعة تتطلب الكثير من الحسابات.

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

يعجبني أننا نناقش هذا مع مزيد من التأريض ، لكن tbh أنا
ما زلنا غير مقتنعين تمامًا بأننا نحتاج حتى إلى قطعة أرض في الاستيراد
المسار على الإطلاق. بعد كل شيء ، يبدو أن لدينا plot_ كبادئة لـ
المهام. يتعلق السؤال أيضًا بـ plot_tree: لماذا يجب أن يكون
مفصولة عن رمز التصور النصي والنص الآخر؟

نعم ، يمكن أن يكون هذا أيضًا خيارًا. إذا كان الأمر كذلك ، يمكننا أن نذكر أن جميع الوظائف التي تبدأ بـ plot_ تتطلب matplotlib. ميزة أخرى لهذا الخيار هي أننا لا نحتاج إلى نقل الوظائف الحالية.

بعد الانتهاء من هذه المناقشة ، أوافق على عدم إضافة وحدة sklearn.plot ، واستخدم البادئة plot_ للإشارة إلى متطلبات matplotlib .

على سبيل المثال ، في https://github.com/scikit-learn/scikit-learn/pull/12599 ، سيتم وضع partial_dependence و plot_partial_dependence في inspection .

حسنًا ، ما لم يوافق شخص ما على هذا في الأيام التالية ، سأقوم بتحديث PDP PR و:

• ضع كلاً من partial_dependence و plot_partial_dependence في sklearn.inspection
• اجعل plot_partial_dependence يعيد مجموعة مع كائنات fig و ax كسمات (الآن تقوم بإرجاعهم في مجموعة). بهذه الطريقة ، سنتمكن من الحفاظ على توافق هاتين الوظيفتين مع الإصدارات السابقة عندما ننفذ الخيار الثاني من https://github.com/scikit-learn/scikit-learn/issues/13448#issuecomment -479512520

هل يمكننا اتخاذ القرار النهائي هنا؟
وافق على الاقتراح jnothman و @ NicolasHug وأنا (
الميزة الرئيسية لهذا الاقتراح هي أننا لسنا بحاجة إلى نقل الوظائف الحالية.

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

نعم دعونا نفعل ذلك. جعل وظيفة المساعد لتقديم أكثر فائدة
استيراد خطأ

لمعلوماتك ، أقوم بإضافة sklearn.utils.check_matplotlib_support في 12599 #

def check_matplotlib_support(caller_name):
    try:
        import matplotlib
    except ImportError as e:
        raise ImportError(
            "{} requires matplotlib. You can install matplotlib with "
            "`pip install matplotlib`".format(caller_name)
        ) from e

لمعلوماتك ، أقوم بإضافة sklearn.utils.check_matplotlib_support في # 12599

هذا جيد! شكرا.