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

чем меньше, тем лучше, быстрее можно осуществить поиск.


самый быстрый наверное так называемый "бинарный поиск". 

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

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

не совсем так.
делаешь кучу папок с именами по алфавиту (А...Я).
если слово поиска начинается на букву А, то и ищем в папке А.
в этих папках лежат текстовые файлы - это словарь на какую то букву, разбитый на куски.
и по этим кускам осуществляешь бинарный поиск.
   наверное не совсем понятно написал? 

У Кнута это называется выБОРка-поиск (reTRIEvial search).

Но наверно лучше делить на куски с равными размерами

Программа для чтения книг tequillacat делит на куски по 40000 байт
Если словарь загнать в телефон в виде книги, поиск на моём телефоне(Motorola C650) медленный,
но на более современных телефонах скорее всего это будет происходить намного быстрее.

Для словаря куски должны быть меньше.

не вижу в этом смысла. хотя так скорее всего и получится (так удобнее), только последний кусок будет меньше.

и еще у меня почему то сразу в мозгах всплывает отношение "10 : 10". т.е. если в файле 100 строк, то режем его на 10 частей по 10 строк.   

Это сообщение отредактировал(а) dorogoyIV - 18.7.2007, 11:26

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

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

Это я только в качестве примера написал. Конечно, если реальный справочник делать, такие поиски нужны, но тогда получается что данные придется дублировать несколько раз, а у телефона может уже памяти не хватить.

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

можно индексировать, это меньше места займет чем дублирование.

math64, мы с тобой прям одновременно написали   

Это сообщение отредактировал(а) dorogoyIV - 25.7.2007, 14:33