Nltk: vozes de porteiro: índice de cordas fora do intervalo

Para referência futura, copio / colo sua pergunta aqui:

Eu tenho um conjunto de documentos de texto em conserva que gostaria de eliminar usando PorterStemmer do nltk. Por razões específicas ao meu projeto, gostaria de fazer a derivação dentro de uma visualização de aplicativo django.

No entanto, ao gerar os documentos dentro da visão django, recebo uma exceção IndexError: string index out of range de PorterStemmer().stem() para a string 'oed' . Como resultado, execute o seguinte:

# xkcd_project/search/views.py
from nltk.stem.porter import PorterStemmer

def get_results(request):
    s = PorterStemmer()
    s.stem('oed')
    return render(request, 'list.html')

levanta o erro mencionado:

Traceback (most recent call last):
  File "//anaconda/envs/xkcd/lib/python2.7/site-packages/django/core/handlers/exception.py", line 39, in inner
    response = get_response(request)
  File "//anaconda/envs/xkcd/lib/python2.7/site-packages/django/core/handlers/base.py", line 187, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "//anaconda/envs/xkcd/lib/python2.7/site-packages/django/core/handlers/base.py", line 185, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/Users/jkarimi91/Projects/xkcd_search/xkcd_project/search/views.py", line 15, in get_results
    s.stem('oed')
  File "//anaconda/envs/xkcd/lib/python2.7/site-packages/nltk/stem/porter.py", line 665, in stem
    stem = self._step1b(stem)
  File "//anaconda/envs/xkcd/lib/python2.7/site-packages/nltk/stem/porter.py", line 376, in _step1b
    lambda stem: (self._measure(stem) == 1 and
  File "//anaconda/envs/xkcd/lib/python2.7/site-packages/nltk/stem/porter.py", line 258, in _apply_rule_list
    if suffix == '*d' and self._ends_double_consonant(word):
  File "//anaconda/envs/xkcd/lib/python2.7/site-packages/nltk/stem/porter.py", line 214, in _ends_double_consonant
    word[-1] == word[-2] and
IndexError: string index out of range

Agora, o que é realmente estranho é executar o mesmo lematizador na mesma string fora do django (seja um arquivo Python separado ou um console Python interativo) não produz nenhum erro. Em outras palavras:

# test.py
from nltk.stem.porter import PorterStemmer
s = PorterStemmer()
print s.stem('oed')

seguido pela:

python test.py
# successfully prints 'o'

o que está causando esse problema?

Descobri que esse problema é específico do nltk versão 3.2.2. Originalmente, executei test.py usando ipython, não python, conforme declarado acima. De alguma forma, consegui acessar a instalação do ipython no meu ambiente raiz //anaconda/bin/ipython , embora não tivesse especificado o ipython no ambiente virtual do meu projeto django (ativado) //anaconda/envs/xkcd/bin/ . Como resultado, o ipython deve estar usando a instalação nltk definida em meu ambiente raiz também, que executa a versão 3.2.0.

Para esclarecer, descobri que PorterStemmer falha em derivar a string 'oed' no nltk versão 3.2.2, mas não no nltk versão 3.2.0. Por que eu não tenho ideia.

Como uma observação lateral, eu estava usando o python 2 em ambos os casos. Meu ambiente raiz usa python 2.7.11 e o ambiente do meu projeto django usa python 2.7.13

Ei,
Desculpe por este (problema). Quer dizer, eu nunca uso o github, era
aconteceu acidentalmente. Não sei o que acabei de desencadear!

Em 7 de janeiro de 2017, 23:47, "jkarimi91" [email protected] escreveu:

Descobri que esse problema é específico do nltk versão 3.2.2.
Originalmente, executei test.py usando ipython, não python, conforme declarado acima.
De alguma forma, consegui acessar a instalação do ipython em meu root
ambiente // anaconda / bin / ipython mesmo que eu não tenha especificado
ipython em meu ambiente virtual atualmente ativado
// anaconda / envs / xkcd / bin /. Como resultado, o ipython deve estar usando o
A instalação nltk definida no meu ambiente raiz também executa a versão
3.2.0.

Para esclarecer, descobri que o PorterStemmer não consegue conter o
string 'oed' no nltk versão 3.2.2, mas não no nltk versão 3.2.0. Por que eu
não tenho ideia.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/nltk/nltk/issues/1581#issuecomment-271100268 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AVTBBiywlg5c81StFrrcNOsyuF610y9uks5rP9bLgaJpZM4LdV66
.

@ExplodingCabbage você poderia investigar este problema? O único commit que posso ver em porter.py após 3.2 ter sido lançado é d8402e3f43ce3b7a3c7ecb45c3b8b1f75c7124e2.

Este é o código usado no exemplo fornecido por @ jkarimi91.

from nltk.stem.porter import PorterStemmer
s = PorterStemmer()
print s.stem('oed')

Depurando o código acima usando pdb de _apply_rule_list() em porter.py , após algumas iterações você obtém:

>>> rule
(u'at', u'ate', None)
>>> word
u'o'

Neste ponto, o método _ends_double_consonant() tenta fazer word[-1] == word[-2] e falha.

Se não me engano, no NLTK 3.2 o método relativo era o seguinte:

def _doublec(self, word):
    """doublec(word) is TRUE <=> word ends with a double consonant"""
    if len(word) < 2:
        return False
    if (word[-1] != word[-2]):      
        return False        
    return self._cons(word, len(word)-1)

Pelo que eu posso ver, o cheque len(word) < 2 está faltando na nova versão.

Alterar _ends_double_consonant() para algo assim deve funcionar:

def _ends_double_consonant(self, word):
      """Implements condition *d from the paper

      Returns True if word ends with a double consonant
      """
      if len(word) < 2:
          return False
      return (
          word[-1] == word[-2] and
          self._is_consonant(word, len(word)-1)
      )

Caramba. Sim, parece que eu quebrei isso em https://github.com/nltk/nltk/commit/d8402e3f43ce3b7a3c7ecb45c3b8b1f75c7124e2 :(

Será um teste e uma correção de PR hoje à noite.

Obrigado @ jkarimi91 , @fievelk , @ExplodingCabbage

Olá, encontrei exatamente o mesmo problema hoje. Você poderia sugerir como eu poderia resolver isso? Devo atualizar algum pacote?

Olá @santoshbs. Você pode usar a versão master do NLTK ou lançar 3.2.1 para se livrar do bug; ele só existe na versão 3.2.2 .

@ExplodingCabbage Acho que você está se referindo ao ramo develop (não master ). É fácil ficar confuso, eu acho :)

@fievelk você está certo. Desculpe, sim: você pode usar o branch develop ou 3.2.1 para se livrar do bug.

Muito obrigado pelo ponteiro.