2009-07-25 4 views
3

EDIT: Эта ошибка была обнаружена в 32-разрядных версиях R была исправлена ​​в версии 2.9.2 R.неожиданные результаты agrep(), связанные с max.distance в R


Это написал мне @leoniedu сегодня, и у меня нет ответа на него, так что я думал, что я бы разместить его здесь.

Я прочитал документацию для agrep() (соответствие нечеткой строки), и кажется, что я не полностью понимаю параметр max.distance. Вот пример:

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

Это ведет себя точно так, как я ожидал. Между строками существует 18 символов, поэтому я ожидаю, что это будет порог соответствия. Вот что меня смущает:

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

Почему 30 и 33 матча, но не 31 и 32? Чтобы сэкономить вам несколько минут,

> 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

Последующие меры. Это была ошибка в 32 бит R, которая была исправлена ​​в R2.9.2. (как подробно описано в сообщении Брайана Рипли с 14 августа в R-списке по ссылке выше.) –

+0

если бы вы могли опубликовать этот комментарий в качестве ответа, я с радостью соглашусь с ним и закрою этот вопрос с ответом. Спасибо, что указали на исправление ошибок. –

ответ

2

Я отправил это в списке R некоторое время назад и сообщил, как ошибка в R-глюки-лист. У меня не было никаких полезных ответов, поэтому я потрогал, чтобы узнать, воспроизводится ли ошибка, или я просто что-то упустил. JD Long смог воспроизвести его и любезно разместил здесь этот вопрос.

Обратите внимание, что, по крайней мере, в R, agrep является неправильным, так как он не соответствует регулярным выражениям, а grep означает «Глобальный поиск регулярного выражения и печати». У него не должно быть проблем с шаблонами, превышающими целевой вектор. (я думаю!)

На моем Linux-сервере все хорошо, но не так на машинах Mac и Windows.

Mac: sessionInfo() R версия 2.9.1 (2009-06-26) i386-яблочно-darwin8.11.1 локали: en_US.UTF-8/en_US.UTF-8/С/С /en_US.UTF-8/en_US.UTF-8

agrep (шаблон, х, max.distance = 30) [1] 1

agrep (шаблон, х, max.distance = 31) integer (0) agrep (pattern, x, max.distance = 32) integer (0) agrep (шаблон, х, max.distance = 33) [1] 1

Linux: R версия 2.9.1 (2009-06-26) x86_64-неизвестно-Linux-гну

locale: 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 = С; LC_ADDRESS = С; LC_TELEPHONE = С; LC_MEASUREMENT = en_US.UTF-8; LC_IDENTIFICATION = С

agrep (шаблон, х, max.distance = 30) [1] 1 agrep (шаблон, х, max.distance = 31) [1] 1 agrep (шаблон, х, max.distance = 32) [1] 1 agrep (шаблон, х, max.distance = 33) [1] 1

+0

Я думаю, можно с уверенностью сказать, что это ошибка. Даже если вариант использования является нетипичным, я не вижу хорошей причины, по которой это должно приводить к разным результатам на разных платформах. Могли ли вы воспроизвести это с помощью разных строк разной длины? –

0

Я не уверен, что ваш пример имеет смысл. Для основного grep() шаблон часто является простым или регулярным выражением, а x является вектором, элемент которого соответствует шаблону. Имея шаблон как более длинную строку, x ставит меня как нечетную.

Рассмотрим это, где мы просто использовать Grep вместо подстрока:

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

Из документов agrep это расстояние Левенштейна, поэтому длина шаблона не имеет значения - нас интересует некоторое преобразование шаблона, которое приводит к подстроке данной строки. (Это более интересно, когда максимальное расстояние удерживается на низком уровне.) Но это, очевидно, ошибка, так как расстояние редактирования не только прерывается между 30 и 33. – ars

 Смежные вопросы

  • Нет связанных вопросов^_^