Nltk: Вывод стеммера Портера несовместим с эталонными реализациями

Я только что поставил на это ярлык "goodfirstbug". «Первая хорошая ошибка» - это добавление нескольких тестовых примеров в stem.doctest (https://github.com/nltk/nltk/blob/master/nltk/test/stem.doctest) - если вам хочется слиться в исправлениях Стюарта тоже было бы здорово!

Привет всем, особенно @alexrudnick , следует ли сейчас пометить это как

На бегу, похоже, нет, это еще не решено. Но хотел бы получить известие от сопровождающего.

@paulproteus - наконец решено

Обратите внимание, что поведение стеммера _default_ на момент моего PR, которое только что объединил Стивен, не изменилось; вам нужно явно передать mode=PorterStemmer.MARTIN_EXTENSIONS PorterStemmer чтобы получить поведение, соответствующее эталонным реализациям Мартина (которые сами по себе несовместимы с исходным алгоритмом Мартина).

Возможно, было бы лучше иметь MARTIN_EXTENSIONS в качестве режима по умолчанию (для согласованности с эталонными реализациями), поскольку пользователи будут ожидать, что что-то под названием PorterStemmer будет вести себя из коробки, как эталонные реализации Мартина. Проблема в том, что это было бы нарушением обратной совместимости, причем совершенно неочевидным; кто-то, кто использует предыдущую реализацию NLTK и обновляет NLTK, может долгое время не замечать, что изменились лишь некоторые из их основ, что может вносить небольшие ошибки в зависимости от варианта использования. Другой вариант - вообще не иметь значения по умолчанию и потребовать от каждого пользователя прочитать документацию по различным режимам и явно выбрать, какой из них использовать. Это также нарушит обратную совместимость, но сделает это _очевидным_ способом (просто попытка создать экземпляр стеммера старым способом взорвется), поэтому люди, выполняющие обновления, не читая примечания к выпуску, не будут пойманы. Такой подход позволил бы избежать любого из описанных выше плохих сценариев, но за счет того, что каждый новый пользователь стеммера требовал большей предварительной работы.

Ни один из вариантов не идеален. Я выбрал по умолчанию NLTK_EXTENSIONS , но есть возможность не согласиться. У кого-нибудь есть мнение?

@ExplodingCabbage : я предпочитаю ваш последний вариант, без значения по умолчанию, и сделаю это со следующим основным выпуском (а не второстепенным выпуском, в котором ваша работа появится впервые) с соответствующими предупреждениями в примечаниях к выпуску. Я думаю, было бы хорошо, если бы людей заставляли читать документы и получать пользу от вашей работы. Мне любопытно узнать, что думают другие.

Привет, ребята,

Я писал бэкэнд поисковой системы со стандартным PorterStemmer в nltk, не зная, что он ведет себя не так, как многие другие реализации стеммера Porter. Теперь, когда я работаю над интерфейсом с использованием Javascript, я сталкиваюсь с ошибками, когда интерфейс и мой сервер по-разному определяют слова. Мне было интересно, на что я должен смотреть, если мне нужно воссоздать поведение 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, чтобы проверить правильность вашей работы.