Стислий вміст гілки
Автор: DalekiyObriy
« : 2010-05-26 20:15:04 »
Можливо я не так висловився, йдеться про пошук слів, які вказано лише суфіксом, як от «-шевый», який в пошуку розпізнається, як «плюшевий» (суфікс тут не в граматичному сенсі а в більш загальному - закінчення слова). Збагнув. І за яким алгоритмом воно його знаходить? Я так зрозумів, що це не для кожної статті дописана окрема «милиця», так?
ні, я б повісився!  високоевристичний скрипт (на пітоні) пробігає і намагається розкривати суфікси для пошуку, результат не 100% але досить високий
Автор: Re.
« : 2010-05-26 17:34:05 »
Можливо я не так висловився, йдеться про пошук слів, які вказано лише суфіксом, як от «-шевый», який в пошуку розпізнається, як «плюшевий» (суфікс тут не в граматичному сенсі а в більш загальному - закінчення слова). Збагнув. І за яким алгоритмом воно його знаходить? Я так зрозумів, що це не для кожної статті дописана окрема «милиця», так?
Автор: DalekiyObriy
« : 2010-05-26 17:20:44 »
замшевый Даруйте, але, напевно, я сліпий: де там вказано суфікс? :-/
Можливо я не так висловився, йдеться про пошук слів, які вказано лише суфіксом, як от «-шевый», який в пошуку розпізнається, як «плюшевий» (суфікс тут не в граматичному сенсі а в більш загальному - закінчення слова).
Автор: Re.
« : 2010-05-26 15:46:21 »
замшевый Даруйте, але, напевно, я сліпий: де там вказано суфікс? :-/
Автор: DalekiyObriy
« : 2010-05-26 14:23:25 »
2) оскільки ці словникі мають купу суфіксів, то треба хороший формат, який би дозволяв мати ключові слова для пошуку (xdxf здається підходить) Тоді виникає питання: Ваш словник якось розрізняє ці суфікси від несуфіксів?
ображаєте? як би не відрізняв то можна було б сирці словників загнати в xdxf і по всьому замшевый3) оскільки ці словникі мають купу скорочень і службових слів (по яким ми шукати не хочемо) потрібне додаткове оброблювання Якщо є список цих скорочень і службових слів, то гадаю, це не проблема. [/quote] частково є список, частково вони позначені стилями
Автор: Re.
« : 2010-05-25 22:23:26 »
2) оскільки ці словникі мають купу суфіксів, то треба хороший формат, який би дозволяв мати ключові слова для пошуку (xdxf здається підходить) Тоді виникає питання: Ваш словник якось розрізняє ці суфікси від несуфіксів? 3) оскільки ці словникі мають купу скорочень і службових слів (по яким ми шукати не хочемо) потрібне додаткове оброблювання Якщо є список цих скорочень і службових слів, то гадаю, це не проблема.
Автор: DalekiyObriy
« : 2010-05-25 22:01:42 »
Пощо туди писати, якщо тут є?  Спасибі. Пофіг куди писати, аби не мовчати і не мучатись Сьогодні підняв межу до 100, сподіваюсь цього буде досить. Щодо Stardict знайшов цікавий румунський проект. Там використовують базу даних як словник. Не певен, що скрипт sql4dic.py Вам підійде відразу, але його назва говорить сама за себе. 1) по-перше якщо вже робити по-справжньому, то я б використав формат xdxf 2) оскільки ці словникі мають купу суфіксів, то треба хороший формат, який би дозволяв мати ключові слова для пошуку (xdxf здається підходить) 3) оскільки ці словникі мають купу скорочень і службових слів (по яким ми шукати не хочемо) потрібне додаткове оброблювання 4) в мене вже є скрипт який робить xdxf-словничок Кримського на базі xml (який є фактично сирцем бази), але він не займається суфіксами, скороченнями, підтримкою двох мов тощо... скрипт цей на 40 рядків (python), тому брати чиєсь інше за основу напевне не має сенсу якщо хочете погратися з ним (і взнати купу павуків, які супроводжують пошук по таким словникам ), пишіть
Автор: Re.
« : 2010-05-24 19:11:35 »
ну то завжди ж можна написати про це на http://r2u.org.ua/forum, або мені листа, або навіть тут, пощо мовчати і мучитись? Пощо туди писати, якщо тут є? Спасибі. Щодо Stardict знайшов цікавий румунський проект. Там використовують базу даних як словник. Не певен, що скрипт sql4dic.py Вам підійде відразу, але його назва говорить сама за себе.
Автор: DalekiyObriy
« : 2010-05-24 15:46:20 »
підняв межу до 70, кількість запитів без використання шаблонів, що впираються в неї, тепер менше десятка на день ...це єдине, що мене дратує. ну то завжди ж можна написати про це на http://r2u.org.ua/forum, або мені листа, або навіть тут, пощо мовчати і мучитись?
Автор: Re.
« : 2010-05-24 12:37:25 »
дик: pdf2html | html2sql Ага, + чимало людино-годин. але я не зовсім розумію навіщо кінцевому користувачеві sql? Вважаєте, що базу намагається поцупити кінцевий користувач? Власне, кінцевому користувачу лише й сайт потрібен. а от якщо Ви візьметесь зробити *повноцінний* набір словничків для (q)stardict, то можна про це серйозно поговорити, бо горбуху, яка буде в (q)stardict шукати лише половину слів я робити не хочу, а на справжню роботу часу не вистачає... Гаразд, спробую.
Автор: DalekiyObriy
« : 2010-05-23 21:12:18 »
Ось цього в тому pdf і бракує. дик: pdf2html | html2sql але я не зовсім розумію навіщо кінцевому користувачеві sql? а от якщо Ви візьметесь зробити *повноцінний* набір словничків для (q)stardict, то можна про це серйозно поговорити, бо горбуху, яка буде в (q)stardict шукати лише половину слів я робити не хочу, а на справжню роботу часу не вистачає...
Автор: Re.
« : 2010-05-23 20:10:33 »
Ось цього в тому pdf і бракує.
Автор: DalekiyObriy
« : 2010-05-23 17:05:45 »
Щодо бази — це її структура, словом, не Вам же це пояснювати.
\d src
Table "public.src"
Column | Type | Modifiers
--------------+-----------------------------+------------------------------------------------------------
word_id | integer | not null default nextval('src_word_id_seq'::regclass)
word_str | character varying |
state | integer | default 0
word_str_ru | character varying |
word_str_uk | character varying |
word_str_rub | character varying |
ts_uk | tsvector |
ts_ru | tsvector |
last_edit_tm | timestamp without time zone |
Indexes:
"src_pkey" PRIMARY KEY, btree (word_id) CLUSTER
"src_state" btree (state)
"ts_ru_idx" gist (ts_ru)
"ts_uk_idx" gist (ts_uk)
Автор: Re.
« : 2010-05-23 00:16:11 »
а що саме з бази даних цікавить (можна це перенести в приват)? бо я якраз не проти піти на пенсію і віддати це все господарство комусь молодшому з купою енергії, що зробить з проекту нарешті гарну цяцю Дуже сумнівно, що я потягну цей проект (як я розумію, він базується на postgresql, drupal, php тощо, жодного з переліченого я не використовував на промисловому рівні). Якщо Вам таке підходить, то, звичайно, не соромтесь — пишіть у приват. Щодо бази — це її структура, словом, не Вам же це пояснювати.
Автор: DalekiyObriy
« : 2010-05-22 21:42:53 »
Чесно пишучи, мене б самого більше цікавила сама база даних, аніж якийсь там pdf.
а що саме з бази даних цікавить (можна це перенести в приват)? бо я якраз не проти піти на пенсію і віддати це все господарство комусь молодшому з купою енергії, що зробить з проекту нарешті гарну цяцю До того ж, словників усе дедалі більше, тобто й результатів відповідно. Я нічого поганого не бачу, в тому, що користувач шукає одне слово, яке по тридцять раз трапляється в одному словнику і шукати його по всім одночасно. Звісно, цим не потрібно зловживати, але інколи потрібно. І, звісно, обмеження повинні бути, але не такі маленькі. Я не думаю, що навантаження буде менше, якщо я по кожному словнику буду шукати окремо. Власне, вам видніше, чи сервер це витримає, але це єдине, що мене дратує. я з кожним новим словником межу піднімаю, але окрім того, як правило, аналізую журнал на кількість (і якість) запитів, які в неї впираються... щоправда я давно цього не робив вже, підняв межу до 50, ще подивлюсь на журнал наступні пару днів... хочу лише додати, що сайт крутиться на віртуальному сервері і там ще схоже декілька десятків інших проектів, так що ресурси (ЦП і ОП) досить обмежені
|
