Помогите создать условие.

У меня есть массив:
@massiv = qw(4 10 16 20);
Каким образом создать условие так, чтобы проверялось сразу принадлежность каждого значения массива ?

т.е например:

  

Это сообщение отредактировал(а) AlexanderI - 20.7.2006, 10:35

неее, пользуйся лучше хешем... 

или вот так   
 

Тут вкралась ошибочка, смотрите топик ниже

Правильно вот так:
 
Хотя в данном конкретном случае это никак не влияет, мы проверяем существование ключа а не его истиннось, но ради принципа всеже этот вариант вернее...

Это сообщение отредактировал(а) Nab - 17.8.2006, 12:56

В крайнем случае можно изобразить что-то типа  

Это сообщение отредактировал(а) Throne - 20.7.2006, 15:45

еще как вариант с форейчем:

вот еще вариантец

  

Это сообщение отредактировал(а) Ramirez - 21.7.2006, 10:19

Почитай про логические операторы 

это из другой оперы - это ты проверяешь определен ли энный элемент массива, где эн=$cifra
 

AlexanderI, 



  
 

;)
 

Nab, т.е. в твоем варианте прокатит:

$cifra = 4, а какой-нить элемент массива @massiv 345 или 4me  

   

Ну вот началось   
я так и знал что начнеться  
блин и в праздник обижают   

все знают как помочь беде   

ну ладно, так и быть скажу    ....



или
 

2 Nab:
Переведи, плз, 2-ю строчку

Ууу, ее сложно в двух словах объяснить, но я попытаюсь 

В левой части выражения мы формируем срез хеша предсталенный в виде массива. И каждому элементу которого в правой части присваиваем 1.

Срез хеша это приблизительно вот так:



Так как нас интересует присваивание то этот срез хеша попадает в левую часть. В правую попадает вот такое выражение:



оператор x - это повторитель, он повторяет элемент (число, строку) указанный как левый операнд... правый операнд определяет количество этих самых элементов.
В нашем случае, это массив, который в  скалярном контексте  возвращает количество своих элементов.

Вообще это один из самых простых способов заполнить хеш или массив повторяющимся или дефолтным значением.

Я не скажу что это очень сложно, но осваивается с трудом .

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



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

Ну вот вроде и все, надеюсь понятно объяснил   
Если что спрашивайте...

Это сообщение отредактировал(а) Nab - 9.9.2006, 01:04

Супер!!!

1. Правильно я понимаю, что


2. Про 1 x @mass я так и думал. Тока не понятно, зачем? Почему просто не сказать @{%hash}{@mass} = 1;?

3. Где написано, что в конструкции @{%hash}{@mass} сначала выполняется %hash{@mass}, а затем уже результат преобразовывается к массиву (или списку)?

4. Наскока я мог понять из прочтенного, список и массив -- разные вещи. (1, 2, 3) -- список, @x = (1, 2, 3) -- массив, в который скопированы элементы списка. Это верно?

5. Меня удручает, что не могу найти четких правил о семантике языка. Например, где однозначно говорится, в чем отличия в интерпретации @%hash{@mass} и @{%hash}{@mass}. Где?

Если не сложно, конечно =)

Так, сразу приношу извинения кого ввел в заблуждение:

Конструкция '1 x 10' создаст строку из десяти единичек. В нашем же случае нужны отдельные элементы, посему их нужно екранировать...  
Вот верный код:




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



Аналогично предыдущему... Сначала самому проверить, а потом писать. С учетом того что я тоже ошибся 



С чего ты это взял? Эта конструкция вообще не верна.



Нет    Список и массив одно и тоже...



Аналогично первому, сначала проверить на жизнеспособность а потом писать...

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

Купи LamaBook И очень рекомендую Perl CookBook... Как раз в ней это все есть....

Замечательно. По-моему, посты товарища 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. Прошу у всех прощения за многословие.

Многословие в тему, потому прощения просить не нужно.   

А ты попробуй к списку и массиву обратиться в скалярном контексте, и увидишь разницу

думаю за два года он уже это сам понял 

Да а я чо то на даты и не глядел , просто лазил читал решил свое слово вставить 

И какова она?

Время не столь важно...

Археологи)