Не в поиске, а при вводе ключа, а далее будет использоваться вычисленное значение либо аналогичное хешкоду, либо в виде прямого адреса. А ввод и преобразование введенного ключа есть и в стандартном поиске. Про экономию памяти у нас вообще речи не было. Был недостаток в виде расточительного ее использованию под таблицы, который в процессе обсуждения был устранен.

С этого места подробнее, а то непонятно почему претензия к массиву с миллионом адресов введенному вместо индексов выдается за неработоспособность? 

Я вообще не понимаю о каком ручном управлении Вы говорите. Хотите сказать, что алгоритм должен самозародиться или он все-же должен программистами быть реализован?

Ну, Вы уж  извините, что без разрешения, но так работают все редакторы умеющие ставить переносы. Так что предъявите претензии разработчикам

С биологической точки зрения человек вообще кусок протоплазмы набитый бактериями в башке которого бегают биоэлектричекие потенциалы. Но любят человеков не за это

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

Хеш-таблицей называется структура данных, позволяющая хранить пары вида «ключ» — «хеш-код» и поддерживающая операции поиска, вставки и удаления элемента. Хеш-таблицы применяются с целью ускорения поиска, например, при записи текстовых полей в базе данных может рассчитываться их хеш-код, и данные могут помещаться в раздел, соответствующий этому хеш-коду. Тогда при поиске данных надо будет сначала вычислить хеш-код текста, и сразу станет известно, в каком разделе их надо искать. То есть искать надо будет не по всей базе, а только по одному её разделу, а это ускоряет поиск.

Бытовым аналогом хеширования в данном случае может служить размещение слов в словаре в алфавитном порядке. Первая буква слова является его хеш-кодом, и при поиске просматривается не весь словарь, а только слова, начинающиеся на нужную букву.

Не мудрено, я с Лукомором досчитал до 512... 

Вот именно. Я то все время ориентируюсь на хеширование с преобразованием текста в уникальное длинное целое двоичное число, которое для использования в HTML, переводится в цепочку символов. Эти хеши хранятся в таблице. Вот, повторюсь -

Поэтому предлагаемый способ представляет собой вариант хеш-функции, которых существует не одна, отличающийся более широкими возможностями ассоциативного доступа к данным и требуемый объем перекодировочного массива из длинных чисел в удобоваримые адреса является ничтожным по сравнению с хеш-таблицами

А тут много вариантов, начиная с применения в качестве еще одного варианта хеш-функции в стандартном поиске без прочих новаций. С ними надо просто поэкспериментировать

Применяется, включая учет фонетики. Но, действительно, фиг  ней с ружьей, это тоже лучше оставить для экспериментов

В символьный формат оно переводится для визуализации

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

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

Легко. Можно остановиться на том, что мы предложили еще одну хеш-функцию преобразующую слова в уникальный код. Кстати мне непонятно, почему этот способ не применяется, а применяются те, что вызывают коллизии

В короткой хеш-таблице преобразующей длинные значения в их короткие порядковые номера.