Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java ME (J2ME) > Работа с большими ресурсами

Автор: math64 16.7.2007, 13:50

Хочу написать словарь для телефона. Использую 4 ресурса: английские слова, русские слова, индексы переводов на русский, индексы переводов на английский. Целиком списки слов даже на эмуляторе не открываются, поэтому их приходится рубить на части. Какой наиболее оптимальный размер куска? Как лучше организовать поиск? Хотелось бы искать не только по первым буквам и учётом/без учёта case sensitive. Может быть есть готовые библиотеки?

Автор: dorogoyIV 16.7.2007, 14:57

Цитата Какой наиболее оптимальный размер куска? чем меньше, тем лучше, быстрее можно осуществить поиск. Цитата Как лучше организовать поиск? самый быстрый наверное так называемый "бинарный поиск".

Автор: math64 16.7.2007, 15:10

Менший размер куска --> больше ресурсов -> меньше степень сжатия jar, больше времени на поиск ресурса внутри j2me, а возможно есть ограничение на количество ресурсов.

Автор: math64 17.7.2007, 08:25

Бинарный поиск можно провести, только если данные находятся в ОЗУ, или имется произвольный доступ. Т.е. его можно использовать только для определения нужного куска - при этом кусков не должно быть слишком много - нужно хранить в ОЗУ первое слово каждого куска.

Автор: dorogoyIV 17.7.2007, 09:10

Цитата(math64 @  17.7.2007,  08:25 ) Бинарный поиск можно провести, только если данные находятся в ОЗУ, или имется произвольный доступ. Т.е. его можно использовать только для определения нужного куска - при этом кусков не должно быть слишком много - нужно хранить в ОЗУ первое слово каждого куска. не совсем так. делаешь кучу папок с именами по алфавиту (А...Я). если слово поиска начинается на букву А, то и ищем в папке А. в этих папках лежат текстовые файлы - это словарь на какую то букву, разбитый на куски. и по этим кускам осуществляешь бинарный поиск.    наверное не совсем понятно написал?

Автор: math64 18.7.2007, 09:20

Цитата(dorogoyIV @  17.7.2007,  09:10 ) делаешь кучу папок с именами по алфавиту (А...Я). У Кнута это называется выБОРка-поиск (reTRIEvial search). Но наверно лучше делить на куски с равными размерами Программа для чтения книг tequillacat делит на куски по 40000 байт Если словарь загнать в телефон в виде книги, поиск на моём телефоне(Motorola C650) медленный, но на более современных телефонах скорее всего это будет происходить намного быстрее. Для словаря куски должны быть меньше.

Автор: dorogoyIV 18.7.2007, 11:00

Цитата(math64 @  18.7.2007,  09:20 ) Но наверно лучше делить на куски с равными размерами не вижу в этом смысла. хотя так скорее всего и получится (так удобнее), только последний кусок будет меньше. и еще у меня почему то сразу в мозгах всплывает отношение "10 : 10". т.е. если в файле 100 строк, то режем его на 10 частей по 10 строк.

Автор: darf 19.7.2007, 11:25

Цитата делаешь кучу папок с именами по алфавиту (А...Я). если слово поиска начинается на букву А, то и ищем в папке А. в этих папках лежат текстовые файлы - это словарь на какую то букву, разбитый на куски. и по этим кускам осуществляешь бинарный поиск.    наверное не совсем понятно написал?   Пример такого подхода можешь посмотреть в отрывке из моей книги. http://www.piter.com/book.phtml?978591180327 Пункт "Городской телефонный справочник" Там речь идет о телефонном справочнике большого города, но для словаря принцип тот же.

Автор: math64 24.7.2007, 15:37

В http://www.piter.com/book.phtml?978591180327 поиск только по номеру телефона (нет поиска по имени и адресу) - не очень интересно. Кроме того, при разработке в Linux позникают ошибки - там перевод строки '\n' без '\r', а системная кодировка может быть UTF8. Буду делить на куски по 256 слов (2K-4K), ограничение числа слов в словаре - 65536 (индекс 2 байта), коэффициент сжатия jar - 55%. Выбирается нужный кусок, грузится в память и уже в памяти ищется нужное слово. Если при повторном поиске нужен тот же кусок, который уже есть в  памяти, грузить его не надо. Если достаточно памяти, можно организовать кэш из загрушенных кусков.

Автор: darf 25.7.2007, 11:18

Цитата В http://www.piter.com/book.phtml?978591180327 поиск только по номеру телефона (нет поиска по имени и адресу) - не очень интересно. Это я только в качестве примера написал. Конечно, если реальный справочник делать, такие поиски нужны, но тогда получается что данные придется дублировать несколько раз, а у телефона может уже памяти не хватить.

Автор: math64 25.7.2007, 14:27

Дублировать не обязательно.  1. Можно создать отдельно список телефонов, список фамилий и список адресов и таблицы соответствия между ними (дублирование только в  таблицах соответствия). 2. Создать индекс с помощью lucene или какой-либо другой аналогичной программы. Получившийся индексный файл небольшой по срабнению с данными и влезет в телефон. Но сама lucene большая для телефона (около 500K) и написана для J2SE. Если был бы её порт для J2ME (только поиск по индексу+обфускация для уменьшения размера) - то всё было бы OK.

Автор: dorogoyIV 25.7.2007, 14:27

Цитата(darf @  25.7.2007,  11:18 ) но тогда получается что данные придется дублировать несколько раз, а у телефона может уже памяти не хватить. можно индексировать, это меньше места займет чем дублирование. math64, мы с тобой прям одновременно написали

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)