Страница: 1 | 2 | 3 | 4 |
|
Вопрос: Рус-яп словарь. Что выбрать для БД?
|
Добавлено: 23.06.05 10:43
|
|
Номер ответа: 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 слов. Причем все эти слова тоже проиндексированы.
Ладно, будем думать.
В любом случае, признателен за обсуждение. Ваши советы меня на кое-что натолкнули.
Ответить
|
Номер ответа: 37 Автор ответа: HOOLIGAN
Вопросов: 0 Ответов: 1066
|
Профиль | | #37
|
Добавлено: 29.06.05 12:00
|
Получается, что ты делаешь не словарь, а разговорник.
Никаких проблем не вижу в том, что может быть 3-4 слова во фразе, или 7-8 слов.
Сделай гибрид разговорника и словаря. Те слова, которые подпадают под схему с 33 файлами (по буквам), пусть лежат в этих файлах. Те же фразы и предложения, что могут быть соотнесены с несколькими статьями, вынеси в отдельный файл. Условно файл разговорника. И применяй к этому файлу отдельный поиск. Чем больше слов в предложении, тем быстрее оно будет найдено в этом файле. Это свойство многих алгоритмов поиска.
Вообще, по-моему тут нет никакой проблемы. Задача совершенно детская, а ты на ровном месте из неё делаешь проблему ) Что такое 500000 слов? Что такое 20000 предложений по 7-8 слов?
Чтобы проверить наличие слова в одном из 33 файлов, и если оно не найдено, ещё и предложение найти в другом файле - на это надо доли секунды. В чём проблема? Файл предложений пугает? Его размер будет порядка 2 Мб, если 8 слов по 10 букв и 20 байт на указатели статей. Что тут сложного - не пойму
Ответить
|
Номер ответа: 39 Автор ответа: HOOLIGAN
Вопросов: 0 Ответов: 1066
|
Профиль | | #39
|
Добавлено: 29.06.05 16:49
|
CyRax, возьми большой файл, к примеру 500 Мб, открой его CreateFile, и затем CreateFileMapping и MapViewOfFile.
И посмотри, какое будет распределение памяти (в таскменеджере можно поглядеть) ДО и ПОСЛЕ выполнения этих трёх функций. А потом будешь утверждать, что Это как раз и есть грузить в память
А потом попытайся сделать то же с ReadFile'ом. Если получится. Тогда поймешь, кто грузит файл в память, ReadFile или MapViewOfFile.
Ответить
|
Номер ответа: 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. Два соответствующих способа. Откроешь таскменеджера и посмотришь, при каком способе память выделяется, при каком нет. Кидать?
Ответить
|
Номер ответа: 45 Автор ответа: HOOLIGAN
Вопросов: 0 Ответов: 1066
|
Профиль | | #45
|
Добавлено: 29.06.05 19:43
|
Видимо, ты спутал скорость проецирования со скоростью работы с файлом, открытым этим способом. Скорость работы ниже, чем если зачитать его в память ReadFile'ом. Т.к. скорость ограничена вращением винта. На размерах (для средней машины) порядка до 50 - 70 Мб рулит ReadFile, больше - MapView, т.к. при больших файлах быстрее крутить винт, чем дождаться от Винды, пока она высвободит для твоего процесса пару-тройку сотен Мб озу. Если вообще она сможет столько выделить.
Ответить
|
Страница: 1 | 2 | 3 | 4 |
Поиск по форуму