Есть хеш %all вида:

12 3 = 1
12 4 = 1
1245 = 1
1236 = 1
123 6 8 89 =1
...

Есть строка $a="1   2    3";


Как сделать функцию, которая будет проверять наличие строки $a в хеше %all,
не учитывая пробелы в строке и хеше? Однако значения в хеше нельзя менять навсегда, так как он дальше используется с этими пробелами. Проблема в том, что хеш очень большой и строки в нем длинные. Необходимо оптимизировать поиск.

Это сообщение отредактировал(а) Suppir - 21.4.2010, 08:21

хм....

amg ближе всех оказался к истине!

А в чем же настоящая истина? 

Хочу заметить, что решение amg находит даже те ключи хеша, которые не равны строке $a (с условием, что из неё и из ключа уберут пробелы), а содержат эту строку. То есть если $a='123', то найдутся и ключи, равные '12345' и '555123555'.
Чтобы обеспечить равенство, можно использовать:


Кроме того не вижу смысла использовать each(), когда можно использовать keys() - раз уж мы все равно ведём поиск только среди ключей.

keys создаст дополнительный массив из ключей хэша, а это лишний расход и памяти, и времени.

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

нужно просто изменить структуру хеша, и тогда все будет находиться по простому exist

А Вы предложите умное решение, а то рекомендация "просто изменить структуру хеша" не очень информативна 

Ну создаст он временный массив с указателями на строки. Ничего вы из-за этого не потеряете. А со временем, так вообще фигня какая-то.

Мой вариант простой и без выпендрежа)

Господа! Ну почему вам так не нравится функция each? ^ 

Еще раз процитирую кусочек самого первого поста:

Сейчас потестировал на хэше из 2_500_000 элементов с длиной ключей 70 символов.
Функция KSURi на моем компьютере работает 11 с и скрипт требует 630 М памяти. Если в этой функции просто заменить
for my $k ( keys %$hash ) {
на 
while ( (my $k) = each %$hash ) {
то будет 9 с и 350 М.
Выигрыш по времени действительно невелик, но по памяти существенен.

Я, может неправильно, понял топикстартера так, что нужно искать не совпадение строки с ключом (без пробелов), а наличие подстроки в ключе. Пэтому постарался сделать так, чтобы в цикле было только одно регулярное выражение (видимо, подготовительные операции для этого публика и приняла за выпендреж). Чтобы определять наличие подстроки в функции KSURi, туда нужно внести еще одно регулярное выражение, т.е. $str eq $k заменить на $k =~ /$str/, а это даст еще лишние 2 с.

Кстати, KSURi, судя по прибавке памяти, получается (перл 5.8), что keys создает все же массив ключей, а не массив ссылок на них. Хотя в данной ситуации ( for (keys %hash) ), казалось бы, можно было ограничиться массивом ссылок. Может, в более новых перлах так?

Ребята, я сделал эту функцию без хеша. Просто перебором по двум массивам и сравнением измененных элементов этих массивов.
Вариант с хешем отбирал очень много оперативки.

элементарно

Как выяснилось, даже один хэш не влазит в память, а Вы предлагаете завести еще один такой же. 

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

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

Это сообщение отредактировал(а) Suppir - 27.4.2010, 08:14