2009-07-25 5 views
3

EDIT: Ce bug a été constaté dans les versions 32 bits de R a été corrigé dans R version 2.9.2.résultats inattendus agrep() liés à max.distance dans R


Cela m'a été tweeté par @leoniedu aujourd'hui et je n'ai pas de réponse à lui donc je pensais que je posterais ici.

J'ai lu la documentation de agrep() (correspondance de chaînes floues) et il semble que je ne comprenne pas complètement le paramètre max.distance. Voici un exemple:

pattern <- "Staatssekretar im Bundeskanzleramt" 
x <- "Bundeskanzleramt" 
agrep(pattern,x,max.distance=18) 
agrep(pattern,x,max.distance=19) 

Cela se comporte exactement comme je m'attendais. Il y a 18 caractères différents entre les cordes, donc je m'attends à ce que ce soit le seuil d'un match. Voici ce qui me dérange:

agrep(pattern,x,max.distance=30) 
agrep(pattern,x,max.distance=31) 
agrep(pattern,x,max.distance=32) 
agrep(pattern,x,max.distance=33) 

Pourquoi 30 et 33 correspond, mais pas 31 et 32? Pour vous éviter de compter,

> nchar("Staatssekretar im Bundeskanzleramt") 
[1] 34 
> nchar("Bundeskanzleramt") 
[1] 16 
+0

http://www.nabble.com/possible-agrep-bug--R-2.9.1,-Mac-OS-X-10.5-(PR-13789)-td24285192.html – ars

+0

Suivi. C'était un bug dans le 32 bits R, qui a été corrigé dans R2.9.2. (comme détaillé dans le message de Brian Ripley du 14 août à R-list dans le lien ci-dessus.) –

+0

si vous pouviez publier ce commentaire comme réponse, je l'accepterais volontiers et clôturerais cette question avec une réponse. Merci d'avoir signalé le problème. –

Répondre

2

J'ai posté ceci sur la liste R un certain temps et rapporté comme un bogue dans les bogues R-liste. Je n'avais aucune réponse utile, alors j'ai twitté pour voir si le bug était reproductible ou si je manquais juste quelque chose. JD Long a pu le reproduire et a gentiment posté la question ici. Notez que, au moins dans R, agrep est un terme inapproprié car il ne correspond pas pas correspond aux expressions régulières, tandis que grep signifie "Recherche globale de l'expression régulière et imprimer". Il ne devrait pas avoir de problème avec les modèles plus longs que le vecteur cible. (je pense!)

Dans mon serveur Linux, tout va bien, mais pas dans mes machines Mac et Windows.

Mac: sessionInfo() Version 2.9.1 R (26/06/2009) locale i386-apple-darwin8.11.1 : en_US.UTF-8/en_US.UTF-8/C/C /en_US.UTF-8/en_US.UTF-8

agrep (motif, x, max.distance = 30) [1] 1

agrep (motif, x, max.distance = 31 nombre entier (0) agrep (motif, x, max.distance = 32) nombre entier (0) agrep (motif, x, max.distance = 33) [1] 1

Linux: version R 2.9.1 (26/06/2009) x86_64-Linux inconnu gnu

paramètres régionaux: LC_CTYPE = en_US.UTF-8; LC_NUMERIC = C; LC_TIME = en_US.UTF-8; LC_COLLATE = en_US.UTF-8; LC_MONETARY = C; LC_MESSAGES = en_US.UTF-8; LC_PAPER = en_US.UTF-8; lc_name = C; LC_ADDRESS = C; LC_TELEPHONE = C; LC_MEASUREMENT = en_US.UTF-8; LC_IDENTIFICATION = C

agrep (motif, x, max.distance = 30) [1] 1 agrep (motif, x, max.distance = 31) [1] 1 agrep (motif, x, max.distance = 32) [1] 1 agrep (motif, x, max.distance = 33) [1] 1

+0

Je pense qu'il est prudent de dire que c'est un bug. Même si le cas d'utilisation est atypique, je ne vois pas pourquoi cela devrait produire des résultats différents sur des plates-formes différentes. Étiez-vous capable de reproduire cela avec différentes chaînes de différentes longueurs? –

0

Je ne suis pas sûr si votre exemple est logique. Pour le basic grep(), le pattern est souvent une expression simple ou régulière, et x est un vecteur dont l'élément correspond au motif. Avoir un motif en tant que plus longue chaîne que x me semble étrange.

Considérez ceci où nous utilisons juste grep au lieu de substr:

R> grep("vo", c("foo","bar","baz")) # vo is not in the vector 
integer(0) 
R> agrep("vo", c("foo","bar","baz"), value=TRUE) # but is close enough to foo 
[1] "foo" 
R> agrep("vo", c("foo","bar","baz"), value=TRUE, max.dist=0.25) # still foo 
[1] "foo" 
R> agrep("vo", c("foo","bar","baz"), value=TRUE, max.dist=0.75) # now all match 
[1] "foo" "bar" "baz" 
R> 
+1

A partir des docs de agrep, c'est une distance de Levenshtein, donc la longueur du motif n'a pas d'importance - nous sommes intéressés par une transformation du motif qui résulte en une sous-chaîne de la corde en question. (C'est plus intéressant quand la distance maximale est basse.) Mais c'est évidemment un bug, puisque la distance d'édition ne devient pas seulement discontinue entre 30 et 33. – ars