Замечательно. По-моему, посты товарища Nab'a вполне достойны размещения в каком нить FAQ.
Вот кстати, иногода бывает такая ситуация:


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

Спасибо конечно 

А по существу, то,  наверно вот так :

Ещё, как вариант:

korob2001, отличный вариант! Супер!   

Нравится мне этот форум! Есть над чем подумать.
Вот, например, здесь предложили несколько вариантов решения практически важной задачи: выяснить, присутствует ли в списке данный элемент. Мне часто приходится иметь дело с огромными списками, поэтому я эти варианты поисследовал на предмет эффективности. Привожу результаты, может, кому-нибудь еще будет интересно.

Результаты:

Я для себя запомню два варианта: "korob2001" - совершенно неожиданный, но очень эффективный, и "Nab1" - не быстрый, но зато не требующий дополнительной памяти.

amg, ты манияк от перла   Оптимизатор блин 

Кстати мне не понятны результаты вариантов diverd и sharq, они по идее аналогичны моему, но отжирают памяти порядочно . 

Конечно они быстрее, но ...  Видно какое-то оптимизирующее кеширование применяется... И похоже что одинаковое.


Это сообщение отредактировал(а) Nab - 13.9.2006, 03:57

Кстати в моем первом варианте, вопрос не до конца продуман



Ведь в реальности получается что все время потрачено на заполнение и конвертирование одной формы списка в другую, хеш. Хотя у большинства это было просто заполнение массива. Я бы наверно предпочел сразу формировать хеш а не первоначальный список, но идея даже не в этом... 
Так как в список уникальных значений всего 4 то хеш в конечном итоге получиться всего из 4 элементов, и поиск по нему будет мизерно быстр  тут нужно или заполнять список уникальными значениями, типа i++ или сразу из них же формировать хеш, думаю результат будет другим . попробуешь? для чистоты эксперимента?

Вариант 1


Вариант 2


можно пргнать с уникальным списком все варианты 

Ага, когда компутер сначала надолго замолкает, а потом начинает молотить диском, впадая в глухой своп, поневоле станешь оптимизатором.

Мне вот тоже непонятно, почему вариант "Nab1" не требует памяти, хотя, на первый взгляд, должен, а "diverd" - требует, хотя, казалось бы, и незачем. В общем, много еще нужно учиться.

ЗЫ Это я на предыдущий пост...

Это сообщение отредактировал(а) amg - 12.9.2006, 12:23

 Нет, время на заполнение первоначального массива не учитывалось.
 Дополнительное время (см. ниже) тратится, видимо, на формирование хэша с более, чем 4 элементами. А поиск по хэшу я уже проверял, он пренебрежимо быстр и для очень больших хэшей (удивительно, однако). 
С удовольствием!  Фактически, изменились первые две строчки, в 1-й замедление (можно понять, почему), во 2-й - ускорение (непонятно почему)

amg, интересно с помощью чего ты время тестировал? 
Попробуй Benchmark и повторов этак 10_000, привиди код и результаты.
А с помощью Memchmark замереть память - не совсем хорошо, т.к.


А на счет вариантов мое мнение - вариант korob2001 - красивый, быстро работает из-за регулярных выражений, но есть недостатки, н-р - не найдешь индекс, найденного эелемента.
Мой вариант - это стандартный  в данной ситуации, в стиле Perl, но также есть недостатки.
Вариант Nab (последний) - это вариант языка Си, прелести Perl нет. А первый вариант - map для этого не используется.
List::Util - хороший модуль, но он загружается в память и для небольшой задачи это не нужно!
Обычным перебором - хорошо, но не красиво   

Итог - вариант стоит использовать тот, кот. в данный ситуации будет наиболее приемлем.
Н-р, я использую всегда красивый вариант, если не требуется оптимального решения! Поэтому grep и regexp - это то, что надо.

  

Все верно ребята вы говорите  

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

Ну и конечно о красоте  Прелесть перла, что это можно сделать не одним способом   А красота у всех разная ... 
Хотя мои решения с map не такое уж страшное, и как оказалось и в нем есть рациональное зерно 

PS: amg, а покаж ка, как ты мерял?

amg, хочу сказать, не удивляйся, что время поиска по хеш-таблице не зависит от количества элементов. Если посмотреть на цели, с которыми разрабатывались хеш-таблицы, то именно эта цель и преследовалась, а именно: время поиска не должно зависеть от количества элементов, то есть должно быть константным. На языке алгоритмического анализа это записывается так: O(n) = const =)) Я не знаю никакой другой структуры данных, у которой алгоритмическая сложность была бы величиной постоянной. Так что все работает, как и должно =)

Кстати, amg если будет желаение, можешь попробовать компилировать шаблон только один раз, т.е. добавить модификатор "о" к регулярному выражению. Ведь у нас всё равно не меняется значение переменной $number.

Использовал два способа. 1. Тупое замерение времени до и после куска кода:
 2. Benchmark
 
Результаты (больше проценты - быстрее).
 На большом массиве результаты обоих способов похожи (естественно). Любопытно, что на маленьком массиве все совсем по-другому. Быстрее всех становится вариант "sharq". Этот вариант хорош еще и тем, что он самый "читабельный" (для меня).

Ничего лучше я, к сожалению, не нашел. Другой способ, мне известный, - запускаю top с интервалом обновления 0.2 с и пристально вглядываюсь в быстро мелькающие цифры - весьма неудобен и утомителен.

Совершенно согласен, это самое правильное, если заранее знаешь, что будешь проводить поиск.
 Еще какое! То, что Ваш вариант с map не использует дополнительную память, может оказаться критическим преимуществом. Почему не использует - буду еще разбираться.
Это - уже, см. выше.

Добавлено @ 12:21 

Спасибо! Буду знать.

Добавлено @ 12:28 
Спасибо! Попробовал. Есть ускорение, особенно при многократном поиске внутри небольших массивов.

P.S. Прошу у всех прощения за многословие.