| Вопрос: Рус-яп словарь. Что выбрать для БД? | Добавлено: 23.06.05 10:43 |
Автор вопроса:  Ruslan_x
|
| Ответы | Всего ответов: 52 |
|
Номер ответа: 31 Автор ответа:  Ruslan_x Вопросов: 7 Ответов: 41 |
Профиль | | #31 | Добавлено: 28.06.05 16:25 |
|
По-моему, я написал ещё больше, интересно, дочитает кто-нибудь до конца или нет
 )Я уж точно дочитал.
HOOLIGAN, огромное спасибо за конкретную помощь. Пойду изучать материал. |
||
|
Номер ответа: 32 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #32 | Добавлено: 28.06.05 16:33 |
|
Главное - это не использование какого-нибудь ультрамодного и разрекламированного средства типа .net или скулосервера.
Правильно ли я вас понял, что вы не рекомендуете использовать VB.NET? А что тогда - VB6.0? |
||
|
Номер ответа: 33 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #33 | Добавлено: 28.06.05 16:51 |
|
Сразу возник еще один вопрос. А если нужное слово не находится в самом начале?
----------------------- Дело в том, что в моем словаре очень много фраз, выражений и целых предложений в качестве примеров. Все эти фразы являются самостоятельными словарными статьями. Далеко не будем ходить, возьмем тот же "арбуз". Помимо прочего, есть в словаре реальная статья "ломоть арбуза - SUIKA-NO-HITOKIRE". По идее, я должен найти эту статью по слову "арбуз". Но в вашей схеме я пойду в файл "а.txt" и найду только те фразы с арбузами, которые на этот арбуз и начинаются, т.е. арбуз вкусный арбуз красный арбуз полосатый... А "ломоть арбуза" будет преспокойно лежать в файле "л.txt". Как же я до него доберусь? |
||
|
Номер ответа: 34 Автор ответа: HOOLIGAN Вопросов: 0 Ответов: 1066 |
Профиль | | #34 | Добавлено: 28.06.05 18:29 |
|
Тогда тебе нужно определиться, "ломоть арбуза" - это что? ЛОМОТЬ арбуза или ломоть АРБУЗА? Если второй вариант, то почему он должен лежать в файле "л"? Ключевое слово в этой фразе - арбуз, поэтому и лежать должен с арбузами.
В любом словаре (бумажном), можно встретить такие фразы: Арбуз - suika/ ~ красный - suika krasnaya/ ~а ломоть - suika no hitokire/ Ключевое слово ставится спереди. тот, кто ищет ломоть арбуза, не раскроет словарь на букве "л", он в соответствии с логикой откроет словарь на букве "а", соответствующей ключевому слову в фразе. Поэтому данная фраза и должна добавляться туда, где "а". Это один взгляд на проблему. Есть другой взгляд: а почему бы и не добавить строку в файл "л" ? Конечная статья у тебя одна, фраза, по которой ты её будешь искать - тоже одна, и где бы она не лежала, она будет указывать на одну и ту же статью. Ну и пусть себе лежит в "л". Чтобы определиться, какой способ лучше, нужно знать структуру японского языка, как строятся фразы, какая из фраз правильнее: "ломоть арбуза" или "арбуза ломоть". Из японского знаю только сайонара, поэтому тут я тебе не помощник. Можно плюнуть на всё и внести обе строки. Вырастут вдвое твои файлы. Думаю, это практически не скажется никак на скорости поиска. Зато будет уверенность, что и та и другая фраза будут найдены. Естественно, они обе указывают на одну статью. Можно такие двусмысленные строки вынести в отдельный файл и искать в нем отдельным быстрым алгоритмом поиска. А что касается на чем делать - на чем угодно, хоть на vb хоть на жабе. Главное это оптимальный алгоритм, а не язык, на котором он реализован. А что даёт VB.Net ? Ну есть в нем тысячи готовых классов, совершенно бесполезных в данном случае. Но зато их много
|
||
|
Номер ответа: 35 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #35 | Добавлено: 28.06.05 20:16 |
|
тот, кто ищет ломоть арбуза, не раскроет словарь на букве "л", он в соответствии с логикой откроет словарь на букве "а", соответствующей ключевому слову в фразе
Вот это-то мне в бумажных словарях и не нравится. Действительно в бумажном словаре этот "ломоть арбуза" можно найти только на букве "а". А это ужасно неудобно. Казалось бы логично начинать с первого слова, т.е с буквы "л". К тому же не всегда ясно какое слово является ключевым. Например, в словаре есть и другая статья "ломоть хлеба". Так эта статья в бумажном словаре шла вместе со словом "ломоть". ломоть арбуза ---> ищем на букву "а" ломоть хлеба ---> ищем на букву "л" Логично? Нет. Можно плюнуть на всё и внести обе строки. Вырастут вдвое твои файлы.
К сожалению, это вряд ли поможет. Потому как вырастут файлы очень сильно и это уже накладно. Во-первых очень много фраз, состоящих не из 2-х, а из 3-4 слов. Типичный пример: "уйти в отставку по личным мотивам" Эта фраза проиндексирована по 4-м словам: "уйти", "отставка", "личный", "мотив" Добавлять эту фразу во все буквы - как-то неэлегантно получится. Во-вторых, в словаре есть еще где-то 20 тыс. предложений. В каждом предложении в среднем где-то 7-8 слов. Причем все эти слова тоже проиндексированы. Ладно, будем думать. В любом случае, признателен за обсуждение. Ваши советы меня на кое-что натолкнули. |
||
|
Номер ответа: 36 Автор ответа: MorpheusВопросов: 224 Ответов: 3777 |
Web-сайт: Профиль | | #36 | Добавлено: 28.06.05 20:38 |
| посмотри на примере Lingvo 9 | ||
|
Номер ответа: 37 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #37 | Добавлено: 29.06.05 12:00 |
|
Получается, что ты делаешь не словарь, а разговорник.
Никаких проблем не вижу в том, что может быть 3-4 слова во фразе, или 7-8 слов. Сделай гибрид разговорника и словаря. Те слова, которые подпадают под схему с 33 файлами (по буквам), пусть лежат в этих файлах. Те же фразы и предложения, что могут быть соотнесены с несколькими статьями, вынеси в отдельный файл. Условно файл разговорника. И применяй к этому файлу отдельный поиск. Чем больше слов в предложении, тем быстрее оно будет найдено в этом файле. Это свойство многих алгоритмов поиска. Вообще, по-моему тут нет никакой проблемы. Задача совершенно детская, а ты на ровном месте из неё делаешь проблему ) Что такое 500000 слов? Что такое 20000 предложений по 7-8 слов?
Чтобы проверить наличие слова в одном из 33 файлов, и если оно не найдено, ещё и предложение найти в другом файле - на это надо доли секунды. В чём проблема? Файл предложений пугает? Его размер будет порядка 2 Мб, если 8 слов по 10 букв и 20 байт на указатели статей. Что тут сложного - не пойму 
|
||
|
Номер ответа: 38 Автор ответа: CyRax  Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #38 | Добавлено: 29.06.05 15:49 |
|
Более того, вообще не грузить его в память ReadFile'ом, а сделать MapView.
Это как раз и есть грузить в память. А для того чтобы были перекрёсные ссылки просто оберни каждое слово в какой то тип или вообще построй заголовок отдельно от данных. Второй вариант будет быстрее, но первый удобней при добавлении записей. |
||
|
Номер ответа: 39 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #39 | Добавлено: 29.06.05 16:49 |
|
CyRax, возьми большой файл, к примеру 500 Мб, открой его CreateFile, и затем CreateFileMapping и MapViewOfFile.
И посмотри, какое будет распределение памяти (в таскменеджере можно поглядеть) ДО и ПОСЛЕ выполнения этих трёх функций. А потом будешь утверждать, что Это как раз и есть грузить в память А потом попытайся сделать то же с ReadFile'ом. Если получится. Тогда поймешь, кто грузит файл в память, ReadFile или MapViewOfFile. |
||
|
Номер ответа: 40 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #40 | Добавлено: 29.06.05 17:34 |
| Во всяком случае на больших файлах оно довольно таки на долго замирает. 500 метров я не пробовал, а пробовал 1.5, 4 и 50 метров. В последнем случае задержка достигает 6 секунд. Что он по твоему делает всё это время? Подозреваю что это как раз и есть грузить в память. | ||
|
Номер ответа: 41 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #41 | Добавлено: 29.06.05 18:49 |
|
Это твои подозрения и не более того. Чтобы утверждать наверняка, убедись.
В последнем случае задержка достигает 6 секунд Задержка чего? Где код? Функция MapViewOfFile выполняется 6 секунд???? Это что, на РК-86? |
||
|
Номер ответа: 42 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #42 | Добавлено: 29.06.05 18:58 |
|
The MapViewOfFile function maps a view of a file into the address space of the calling process
Mapping a file makes the specified portion of the file visible in the address space of the calling process Если хочешь посмотреть разницу между ReadFile и MapViewOfFile, скину тебе на мыло программку, открывающую файл 50 Мб, сортирующую его содержание и складывающую сортированное в другой файл. С двумя кнопками:ReadFile и MapViewOfFile. Два соответствующих способа. Откроешь таскменеджера и посмотришь, при каком способе память выделяется, при каком нет. Кидать? |
||
|
Номер ответа: 43 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #43 | Добавлено: 29.06.05 19:18 |
|
Код обычный, ничего лишнего. CreateFile с флагом чтения, CreateFileMapping и MapViewOfFile. Скорость проецирования зависит от размера файла. Чем больше размер, тем дольше создаётся проекция. Никаких предпосылок, только личные наблюдения, а не подозрения, как ты ошибочно предположил.
Это что, на РК-86
Там Windows не пойдёт. Хотя если ты устанавливал, можешь сам проверить. |
||
|
Номер ответа: 44 Автор ответа: CyRax Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #44 | Добавлено: 29.06.05 19:29 |
|
Нет, мне не нужно, я уже им не пользуюсь.
Сначала пробовал его использовать для чтения данных из структурированного хранилища, но отказался из за низкой скорости проецирования. |
||
|
Номер ответа: 45 Автор ответа: HOOLIGANВопросов: 0 Ответов: 1066 |
Профиль | | #45 | Добавлено: 29.06.05 19:43 |
| Видимо, ты спутал скорость проецирования со скоростью работы с файлом, открытым этим способом. Скорость работы ниже, чем если зачитать его в память ReadFile'ом. Т.к. скорость ограничена вращением винта. На размерах (для средней машины) порядка до 50 - 70 Мб рулит ReadFile, больше - MapView, т.к. при больших файлах быстрее крутить винт, чем дождаться от Винды, пока она высвободит для твоего процесса пару-тройку сотен Мб озу. Если вообще она сможет столько выделить. | ||