Nltk: Die Ausgabe von Porter Stemmer stimmt nicht mit der von Referenzimplementierungen überein

Ich habe nur das Etikett "goodfirstbug" darauf gesetzt. Der "gute erste Fehler" wäre das Hinzufügen einer Reihe von Testfällen zu stem.doctest (https://github.com/nltk/nltk/blob/master/nltk/test/stem.doctest) - wenn du Lust hast, zusammenzufassen auch in Stuarts Fixes, das wäre toll!

Hallo zusammen , besonders

Auf den ersten Blick sieht es aus wie nein, es ist noch nicht gelöst. Würde aber gerne von einem Betreuer hören.

@paulproteus – endlich gelöst

Beachten Sie, dass das _default_ Stemmer-Verhalten aus meiner PR, die Steven gerade zusammengeführt hat, unverändert ist; Sie müssen mode=PorterStemmer.MARTIN_EXTENSIONS explizit an den PorterStemmer Konstruktor übergeben, um ein Verhalten zu erhalten, das mit Martins Referenzimplementierungen übereinstimmt (die selbst nicht mit Martins ursprünglichem Algorithmus übereinstimmen).

Es wäre wohl besser, MARTIN_EXTENSIONS als Standardmodus (für die Konsistenz mit den Referenzimplementierungen) zu verwenden, da Benutzer erwarten, dass sich etwas namens PorterStemmer wie Martins Referenzimplementierungen verhält. Das Problem ist, dass dies eine Abwärtskompatibilitätslücke wäre und eine unangenehme, nicht offensichtliche; jemand, der die vorherige Implementierung von NLTK verwendet und NLTK aktualisiert, könnte lange Zeit nicht bemerken, dass sich nur einige ihrer Stämme geändert haben, was möglicherweise je nach Anwendungsfall subtile Fehler einführt. Eine andere Möglichkeit besteht darin, überhaupt keinen Standardwert zu verwenden und von jedem Benutzer zu verlangen, die Dokumentation zu den verschiedenen Modi zu lesen und explizit auszuwählen, welcher verwendet werden soll. Dies würde auch die Abwärtskompatibilität beeinträchtigen, würde dies jedoch auf _offensichtliche_ Weise tun (nur der Versuch, den Stemmer auf die alte Weise zu instanziieren, würde explodieren), damit Leute, die Upgrades durchführen, ohne die Versionshinweise zu lesen, nicht erwischt werden. Dieser Ansatz würde eines der oben genannten schlechten Szenarien vermeiden, aber auf Kosten von mehr Vorarbeit von jedem neuen Benutzer des Stemmers.

Keine der Optionen ist perfekt. Ich habe mich für NLTK_EXTENSIONS als Standard entschieden, aber es gibt Raum, dem zu widersprechen. Hat jemand eine Meinung?

@ExplodingCabbage : Ich bevorzuge Ihre letzte Option, keine Standardeinstellung, und dies mit der nächsten Hauptversion (nicht der Nebenversion, in der Ihre Arbeit zuerst erscheinen wird), mit entsprechenden Warnungen in den Versionshinweisen. Ich denke, es wäre gut, wenn die Leute gezwungen wären, die Dokumente zu lesen und von Ihrer Arbeit zu profitieren. Ich bin gespannt, was andere denken.

Hallo Leute,

Ich habe ein Suchmaschinen-Backend mit dem Standard-PorterStemmer in nltk geschrieben, ohne zu wissen, dass es sich nicht so verhält wie viele andere Porter-Stemmer-Implementierungen. Jetzt, wo ich mit Javascript am Frontend arbeite, stoße ich auf Fehler, bei denen das Frontend und mein Backend Wörter unterschiedlich abstammen. Ich habe mich gefragt, was ich mir ansehen sollte, wenn ich das Standardverhalten von PorterStemmer von nltk in Javascript neu erstellen muss, damit ich es im Browser ausführen kann. Ich hatte gehofft, dass mir vielleicht jemand (vielleicht @ExplodingCabbage ?)

Ich habe wirklich keine Zeit, alles mit dem MARTIN_EXTENSIONS-Modus neu zu indizieren, da dies Wochen dauern würde ...

@josephcc porter.py hat im Grunde keine Abhängigkeiten und macht nichts Tiefgreifendes oder Magisches, nur eine lange Reihe von String-Manipulationen. Sie wollen einfach die Klasse PorterStemmer nach JavaScript portieren, nur die if self.mode == self.NLTK_EXTENSIONS Zweige beibehalten und die Logik von den anderen wegwerfen.

Zugegeben keine 5-Minuten-Aufgabe oder eine narrensichere, aber machbar. Schauen Sie sich auch PorterTest in https://github.com/nltk/nltk/blob/develop/nltk/test/unit/test_stem.py an und ziehen Sie in Betracht, die Testfälle dort gegen Ihre JavaScript-Implementierung auszuführen, um die Richtigkeit zu überprüfen Ihrer Arbeit.