Algorithms
Comments 22
+4
К сожалению до любого ближайшего заведения 640 километров :)
+2
«Макдоналдс (729.2 км — 141 час и 38 мин. пешком)»

Понимаю, что пока в Киеве нет заведений, но может не пугать людей жутким временем ходьбы (если время >N минут то не показывать время вообще) :)
0
Мда) 4184.1 км — 812 час и 45 мин. пешком
Долго идти придется
0
Может они там какие-то неправильные? Ну там картопля вместо картошки и т.п.
+1
Почему сразу для школоты? Например, если я ищу «Шоколадница» и набрал вместо первой «о» букву «л» (промазал не глядя на клавиатуре), то я не против, чтобы поиск поправил это на нужный вариант, а не заставлял удалять все или выбирать нужную букву курсором.

А Вы? ;)
0
тут совсем немного юмора, просто это первая мысль по примeнению, а так спасибо, очень интересная статья.
0
Спасибо, интересная статья.

Можете уточнить:
1. какие фонетические группы у Вас получились для кириллицы?
2. Не совсем понятно как у вас расширяется (а еще интереснее как изначально создавался) словарь (places и places-index)
+1
Базовый словарь places и places-index формируется на основании описаний заведений которые забиваются руками.
places хранит данные которые мы возвращаем в качестве результатов, по сути мы по нему не ищем.
places-index формируется на основании кириллическоего и/или английского названия заведения + набора синонимов.

Каждую фразу (вариант названия) перед загрузкой в индекс мы пытаемся расширить так:
1. Если фраза содержит '-' (например му-му), то создадим два варианта — без '-' и с заменой на пробел.
2. Если фраза содержала русские символы то дополнительно создадим тринслитерированный вариант

например для му-му получим:
му-му => { муму, му му, mumu, mu mu }

Для кириллицы мы объединили только (а, о, у) и (е, и)
+1
— мк.дональдс
— ничего не нашли :(

Собственно тупую транслитерацию он не понял
+1
я думаю это и была транслитерация английской надписи русским алфавитом :)
Mc.Donalds
0
Как-то не очень ясно, зачем было расписывать вещи вроде i << 1, которые любой компилятор сделает сам, если не замечена важнейшая особенность расстояния Левенштейна — достаточно хранить всего две, в данном случае, строки матрицы. Это даст выигрыш и по скорости и по памяти. Плюс код не потокобезопасен.

Да и если вы используете soundex, то какой смысл вообще в редакционном расстоянии?
Даже если есть реальная необходимость его использования, то сначала достаточно поискать точное вхождение soundex кода хеш-поиском, например, а потом если не повезет — уже подбирать варианты.

Это я все к чему. 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос. К слову, за десятки миллисекунд мы отыскивали нечетким поиском подходящую ДНК секвенцию в базе на десятки гигабайт.
0
Да, конечно, соглашусь «i << 1» это перебор, это скорее привычка так писать.
И про две строки матрицы — тоже хороша идея, мы не делали токого рада оптимизаций, потому что пока производительность нас устраивает.

> Плюс код не потокобезопасен.
Зачем использовать этот объект в нескольких потоках? Вы сэкономите совсем немного памяти и получите расходы на синхронизацию.

> Да и если вы используете soundex, то…
Мы совсем его не используем.

> 8 миллисекунд на запрос к базе из 2.5к слов — это пугающий результат. Масштабируемость у вас линейная и всего 312к слов дадут секунду на запрос.
Да, вы правы, но в нашем случае словарь не будет линейно расти с ростом числа заведений в базе и врядли достигнет такого размера.
Если уж словарь большой сперва можно воспользоваться n-граммным индексом.
Ну и конечно в коде много мест которые можно пооптимизировать, наподобии двух строк матрицы про которые вы написали )

А каким индексом вы пользовались при поиске по базе ДНК? У вас все влезало в память или кешировали часть данных?
0
Погуглите еще на тему daitch-mokotoff кода. Он применим и для русского языка.
0
По сути предлагаемого подхода сказать нечего. А вот по поводу самого сайта — интересная, красивая реализация. Мы нечто подобное делали тут (тогда еще не было геолокации на уровне браузера, поэтому мы определяли местоположение с помощью стартапа Wi2Geo). Только вот в проекте InTheCity была целая редколегия которая обзванивала все заведения и составляла их TTX в итоге получалось нечто вроде: inthecity.ru/#/places/restaurants/YAkitoriya_Arbatskaya

У Вас я обнаружил вместо TTX краткое описание (пример: edatuda.ru/#!chain/yakitoriya):
Демократичный и непретенциозный суши-бар
Якитория — один из ветеранов среди многочисленных московских суши-баров. Уже более десяти лет она не теряет своей популярности. И неудивительно, ведь соотношение цена-качество в Якитории порадует всех.

Честно говоря зная Якиторию я с таким описанием не могу согласиться. Демократичным (по крайней мере по ценам) его не назовешь средний чек не ниже чем в том же Тануки или Нияме. Но и «непретенциозным» тоже никак назвать нельзя потому что внутреннее обстановка там одна из самых удачных среди суши баров (чего только аквариумы с рыбой которую периодически вылавливают и уносят на кухню) стоят и очки которые выдают для просмотра 3D меню.

Может стоит дать пользователям предлагать свои описания заведениям? А так же было бы не плохо дать возможность задавать пользовательские: теги, рейтинги и отзывы не фейсбуке, а в ваш движок что бы потом можно было выводить как на афишах/меню.ру.
Only those users with full accounts are able to leave comments.  , please.