Nltk: voix de portier : indice de corde hors de portée

Pour référence future, je copie/colle votre question ici :

J'ai un ensemble de documents texte décapés que j'aimerais supprimer à l'aide de PorterStemmer nltk. Pour des raisons spécifiques à mon projet, j'aimerais faire le stemming à l'intérieur d'une vue d'application Django.

Cependant, lors de la racine des documents dans la vue Django, je reçois une exception IndexError: string index out of range de PorterStemmer().stem() pour la chaîne 'oed' . En conséquence, exécutez ce qui suit :

# 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')

soulève l'erreur mentionnée :

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

Maintenant, ce qui est vraiment étrange, c'est que l'exécution du même stemmer sur la même chaîne en dehors de Django (que ce soit un fichier python séparé ou une console python interactive) ne produit aucune erreur. En d'autres termes:

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

suivie par:

python test.py
# successfully prints 'o'

qu'est-ce qui cause ce problème ?

J'ai constaté que ce problème est spécifique à la version 3.2.2 de nltk. À l'origine, j'ai exécuté test.py utilisant ipython et non python, comme indiqué ci-dessus. D'une manière ou d'une autre, j'ai pu accéder à l'installation d'ipython dans mon environnement racine //anaconda/bin/ipython même si je n'avais pas spécifié ipython dans l'environnement virtuel de mon projet Django (l'activé) //anaconda/envs/xkcd/bin/ . En conséquence, ipython doit également avoir utilisé l'installation nltk définie dans mon environnement racine qui exécute la version 3.2.0.

Pour clarifier, j'ai découvert que le PorterStemmer ne parvient pas à radicaliser la chaîne 'oed' dans nltk version 3.2.2 mais pas dans nltk version 3.2.0. Pourquoi je n'en ai aucune idée.

En remarque, j'utilisais python 2 dans les deux cas. Mon environnement racine utilise python 2.7.11 et l'environnement de mon projet django utilise python 2.7.13

Hey,
Désolé pour ce (problème). Je veux dire que je n'utilise jamais github, c'était
est arrivé accidentellement. Je ne sais pas ce que je viens de déclencher !

Le 7 janvier 2017 à 23h47, "jkarimi91" [email protected] a écrit :

J'ai constaté que ce problème est spécifique à la version 3.2.2 de nltk.
À l'origine, j'ai exécuté test.py en utilisant ipython et non python, comme indiqué ci-dessus.
D'une manière ou d'une autre, j'ai pu accéder à l'installation d'ipython dans ma racine
environnement //anaconda/bin/ipython même si je n'avais pas spécifié
ipython dans mon environnement virtuel actuellement activé
//anaconda/envs/xkcd/bin/. En conséquence, ipython doit avoir utilisé le
nltk installtion définie dans mon environnement racine également qui exécute la version
3.2.0.

Pour clarifier, j'ai découvert que le PorterStemmer ne parvient pas à endiguer le
chaîne 'oed' dans nltk version 3.2.2 mais pas dans nltk version 3.2.0. Pourquoi je
Aucune idée.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/nltk/nltk/issues/1581#issuecomment-271100268 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AVTBBiywlg5c81StFrrcNOsyuF610y9uks5rP9bLgaJpZM4LdV66
.

@ExplodingCabbage, pourriez-vous enquêter sur ce problème ? Le seul commit que je peux voir sur porter.py après la publication de 3.2 est d8402e3f43ce3b7a3c7ecb45c3b8b1f75c7124e2.

C'est le code utilisé dans l'exemple fourni par @jkarimi91.

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

Déboguer le code ci-dessus en utilisant pdb partir de _apply_rule_list() dans porter.py , après quelques itérations, vous obtenez :

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

À ce stade, la méthode _ends_double_consonant() essaie de faire word[-1] == word[-2] et elle échoue.

Si je ne me trompe pas, dans NLTK 3.2 la méthode relative était la suivante :

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)

Autant que je sache, la vérification len(word) < 2 est manquante dans la nouvelle version.

Changer _ends_double_consonant() en quelque chose comme ceci devrait fonctionner :

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)
      )

Aïe. Oui, on dirait que j'ai cassé ça dans https://github.com/nltk/nltk/commit/d8402e3f43ce3b7a3c7ecb45c3b8b1f75c7124e2 :(

PR un test et un correctif ce soir.

Merci @jkarimi91 , @fievelk , @ExplodingCabbage

Bonjour, j'ai rencontré exactement le même problème aujourd'hui. Pourriez-vous s'il vous plaît suggérer comment je pourrais obtenir une solution à cela? Dois-je mettre à jour des packages ?

Salut @santoshbs. Vous pouvez soit utiliser la version master de NLTK, soit publier 3.2.1 pour vous débarrasser du bogue ; il n'existe qu'en version 3.2.2 .

@ExplodingCabbage Je pense que vous faites référence à la branche develop (pas master ). C'est facile de s'embrouiller je suppose :)

@fievelk tu as tout à fait raison. Désolé, oui : vous pouvez soit utiliser la branche develop soit 3.2.1 pour vous débarrasser du bogue.

Merci beaucoup pour le pointeur.