Nltk: إخراج بورتر جذع غير متسق مع تلك الخاصة بالتطبيقات المرجعية

لقد وضعت علامة "goodfirstbug" على هذا. قد يكون "الخطأ الأول الجيد" هو إضافة مجموعة من حالات الاختبار إلى ستم.دوكتست (https://github.com/nltk/nltk/blob/master/nltk/test/stem.doctest) - إذا كنت ترغب في الدمج في إصلاحات ستيوارت أيضًا ، سيكون ذلك رائعًا!

مرحبًا بالجميع ، خاصة

على المقشدة ، يبدو أنه لا ، لم يتم حلها بعد. ولكن أود أن أسمع من المشرف.

paulproteus - تم حلها أخيرًا

لاحظ أن سلوك الجذعية _default_ اعتبارًا من العلاقات العامة الخاصة بي التي دمجها ستيفن للتو لم يتغير ؛ تحتاج إلى تمرير mode=PorterStemmer.MARTIN_EXTENSIONS صراحة إلى مُنشئ PorterStemmer للحصول على سلوك يتوافق مع تطبيقات Martin المرجعية (والتي هي نفسها غير متوافقة مع خوارزمية Martin الأصلية).

يمكن القول إن الحصول على MARTIN_EXTENSIONS كوضع افتراضي (للتوافق مع عمليات التنفيذ المرجعية) سيكون أفضل ، لأن المستخدمين سيتوقعون شيئًا يسمى PorterStemmer ليتصرف خارج الصندوق مثل تطبيقات مارتن المرجعية. المشكلة هي أن ذلك سيكون بمثابة انقطاع في التوافق مع الإصدارات السابقة ، وغير واضح بشكل سيء ؛ قد يفشل شخص ما يستخدم التطبيق السابق لـ NLTK والذي يقوم بترقية NLTK في ملاحظة أن عددًا قليلاً فقط من السيقان قد تغير ، وربما يتسبب في حدوث أخطاء خفية اعتمادًا على حالة استخدامها. هناك خيار آخر وهو عدم وجود قيمة افتراضية على الإطلاق ، ومطالبة كل مستخدم بقراءة المستندات في الأوضاع المختلفة واختيار أي منها بشكل صريح لاستخدامه. سيؤدي هذا إلى كسر التوافق مع الإصدارات السابقة أيضًا ، ولكنه سيفعل ذلك بطريقة _ واضحة_ (مجرد محاولة إنشاء مثيل للمشتق بالطريقة القديمة ستنفجر) حتى لا يتم اكتشاف الأشخاص الذين يقومون بالترقيات دون قراءة ملاحظات الإصدار. سيتجنب هذا النهج أيًا من السيناريوهات السيئة المذكورة أعلاه ، ولكن على حساب المطالبة بمزيد من العمل المسبق من كل مستخدم جديد للجذع.

لا يوجد خيار مثالي. لقد اخترت الحصول على NLTK_EXTENSIONS كإعداد افتراضي ، ولكن هناك مجال للاختلاف. أي شخص لديه رأي؟

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

مرحبا الرجال،

لقد كنت أكتب خلفية محرك بحث باستخدام PorterStemmer الافتراضي في nltk ، ولا أعلم أنه لا يتصرف بنفس الطريقة مثل العديد من تطبيقات Porter الجذعية الأخرى. الآن بعد أن أعمل على الواجهة الأمامية باستخدام جافا سكريبت ، أواجه أخطاء حيث تكون الواجهة الأمامية وكلماتي الجذعية الخلفية مختلفة. كنت أتساءل ما الذي يجب أن أنظر إليه إذا كنت بحاجة إلى إعادة إنشاء سلوك PorterStemmer الافتراضي الخاص بـ nltk في Javascript حتى أتمكن من تشغيله في المتصفح. كنت أتمنى أن ExplodingCabbage ؟) إلى الاتجاه الصحيح.

ليس لدي الوقت حقًا لإعادة فهرسة كل شيء باستخدام الوضع MARTIN_EXTENSIONS لأنه قد يستغرق أسابيع للقيام بذلك ...

josephcc porter.py ليس له أساسًا أي تبعيات ولا يقوم بأي شيء عميق أو سحري ، بل مجرد سلسلة طويلة من التلاعب بالسلسلة. ستحتاج فقط إلى نقل فئة PorterStemmer إلى JavaScript ، مع الاحتفاظ فقط بفروع if self.mode == self.NLTK_EXTENSIONS والتخلص من المنطق عن الفروع الأخرى.

ليست مهمة مدتها 5 دقائق أو مهمة مضمونة ، باعتراف الجميع ، لكنها قابلة للتنفيذ. تحقق أيضًا من PorterTest في https://github.com/nltk/nltk/blob/develop/nltk/test/unit/test_stem.py وفكر في تشغيل حالات الاختبار هناك مقابل تنفيذ JavaScript للتحقق من صحتها من عملك.