Nltk: A saída do stemmer de Porter é inconsistente com a das implementações de referência

Acabei de colocar o rótulo "goodfirstbug" neste aqui. O "bom primeiro bug" seria adicionar um monte de casos de teste a stem.doctest (https://github.com/nltk/nltk/blob/master/nltk/test/stem.doctest) - se você quiser mesclar nas correções de Stuart também, isso seria ótimo!

Olá a todos, especialmente @alexrudnick , isso deve ser marcado como resolvido agora?

Após uma leitura rápida, parece que não, ainda não foi resolvido. Mas gostaria de ouvir de um mantenedor.

@paulproteus - finalmente resolvido

Observe que o comportamento do lematizador _padrão_ no meu PR que Steven acabou de mesclar permanece inalterado; você precisa passar explicitamente mode=PorterStemmer.MARTIN_EXTENSIONS para o construtor PorterStemmer para obter um comportamento consistente com as implementações de referência de Martin (que são inconsistentes com o algoritmo original de Martin).

Indiscutivelmente, ter MARTIN_EXTENSIONS como o modo padrão (para consistência com as implementações de referência) seria melhor, já que os usuários vão esperar algo chamado PorterStemmer para se comportar fora da caixa como as implementações de referência de Martin. O problema é que isso seria uma quebra de compatibilidade com versões anteriores, e desagradavelmente não óbvia; alguém usando a implementação anterior do NLTK que atualiza o NLTK pode deixar de notar por um longo tempo que apenas algumas de suas raízes mudaram, possivelmente introduzindo bugs sutis dependendo do seu caso de uso. Outra opção é não ter um valor padrão e exigir que cada usuário leia a documentação sobre os diferentes modos e escolha explicitamente qual usar. Isso quebraria a compatibilidade com versões anteriores também, mas faria isso de uma maneira _obvious_ (apenas tentar instanciar o lematizador da maneira antiga explodiria) para que as pessoas fazendo atualizações sem ler as notas de lançamento não fossem pegas. Essa abordagem evitaria qualquer um dos cenários ruins acima, mas ao custo de exigir mais trabalho inicial de cada novo usuário do lematizador.

Nenhuma das opções é perfeita. Optei por ter NLTK_EXTENSIONS como padrão, mas há espaço para discordar. Alguém tem uma opinião?

@ExplodingCabbage : Eu

Oi, pessoal,

Eu tenho escrito um back-end de mecanismo de pesquisa com o PorterStemmer padrão em nltk, sem saber que ele não se comporta da mesma maneira que muitas outras implementações de stemmer Porter. Agora que estou trabalhando no front-end usando Javascript, estou encontrando bugs em que o front-end e o meu back-end originam palavras de maneira diferente. Eu queria saber o que devo observar se precisar recriar o comportamento padrão do PorterStemmer do nltk em Javascript para que eu possa executá-lo no navegador. Eu esperava que alguém onde (talvez @ExplodingCabbage ?) Pudesse me apontar a direção certa.

Eu realmente não tenho tempo para reindexar tudo com o modo MARTIN_EXTENSIONS, pois levaria semanas para fazer isso ...

@josephcc porter.py basicamente não tem dependências e não faz nada de profundo ou mágico, apenas uma longa série de manipulações de strings. Você só vai querer portar a classe PorterStemmer para JavaScript, preservando apenas os ramos if self.mode == self.NLTK_EXTENSIONS e jogando fora a lógica dos outros.

Não é uma tarefa de 5 minutos ou infalível, é certo, mas factível. Verifique também PorterTest em https://github.com/nltk/nltk/blob/develop/nltk/test/unit/test_stem.py e considere executar os casos de teste em sua implementação de JavaScript para verificar a exatidão do seu trabalho.