Сверхбыстрый поиск
 

Добрый вечер!
Мне нужно реализовать очень быстрый поиск в маленькой таблице из сорока элементов.
Поиск по таблице будет прогоняться десятки-сотни тысяч раз подряд, поэтому нужен быстрый алгоритм.
Пораскинув мозгами я пришёл к выводу, что без хэш-таблицы тут не обойтись... (к правильному выводу пришёл я?)
Каков наиболее быстрый алгоритм поиска в хэш-таблице? Что мне использовать?
Или же есть что-то, работающее быстрее в данной ситуации, чем хэш-поиск.

Таблица фиксированная, в процессе поиска меняться не будет, её можно изначально упорядочить наиболее удобным образом (рекомендации?).

Зависят от типа данных по которому идет поиск.
Приведи пример записи таблицы.

В таблице два поля: строка и множество (паскалевский перечислимый тип).
Т.е. одна запись таблицы выглядит, например, так:
DEFENITION | ccDef
где DEFENITION - строка - ключ, по которой ведётся поиска, а ccDef - элемент множетства ( ccDef, ccTor, {...} , ccAss, ccOp ) - данные, которые мы ищем по ключу.

ManHack, думаю хэшь стоит использовать если строки большого размера.

Строки маленькие, до десяти символов.
Что можно сделать, чтобы не возникало коллизий?

ganselo, а раз не хэш, тогда что? что будет работать быстрее поиска по хэш-таблице в такой ситуации?

кажись только хеш по самому различаемому (из 40 статичных строчек) символу + длина строчки (если различается)

Как вы связываете зрение и слух - Если уши отрезать, папаха на глаза упадёт ;-)
По хэшу тоже надо как-то искать - т.е. это не ответ на вопрос об алгоритме поиска. Тем более, хэш надо вычислять на каждом шаге. Есть большое подозрение, что на таком небольшом количестве данных тупой перебор со сравненим окажется самым выгодным.

Нужно придумать идеальную хеш-функцию для слов ARRAY, BY, BEGIN, CASE далее по списку (чтобы значения хеш-функции для различных слов из списка не совпадали)
Я придумал так:
for i := 1 to length (Stroka) do
result := result + Stroka[i]*31; (символы строки складываются и каждый раз домножается на 31)
hash := result mod SizeOfHashTable;

но в таком случае у меня совпали значение хеш-функции для DIV и NIL.
Что можно придумать лучшее, чтобы значения не совпадали?

Как использовать повторное хеширование?

ИМХО первая буква XOR вторая
а сочетание {первая, втроая, последняя} - вобще уникальное

первая XOR вторая - не подходит, т.к. REPEAT и RECORD, например.
первая XOR последняя, первая XOR вторая XOR последняя, длина слова XOR первая XOR последняя, длина слова XOR вторая XOR последняя, XOR всех букв - все они дают коллизии на данном множестве из 34 слов.
Пишу так:
Какие ещё будут идеи?

Пишется под 32-разрядный процессор?

Тогда первые 4 байта сравнивать без всяких хешей, к коротким словам естественно перед этим добавить нули/пробелы.

Если известно какие слова будут попадаться чаще, их поместить в начало таблицы.

без xor, сочетание {первая, вторая, последняя} - хотя в один байт это не упихать

Сделал так:
(коды заглавных латинских букв заведомо двузначные)

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

их 26 штук, попробуй * 26