tishaishii, твой код работает не совсем так, как я имел в виду. Например,
a 0 b 0 0 0 0 0 0 0 0 0 c c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 d e
превращается в 
a 0 b 0 c c 0 0 0 0 0 0 0 d e
а я хочу получить
a 0 b 0 c c 0 d e

my ($a,$b) = (0,0); map { defined($_) ? ($a++,$b=0) : ($b++&&splice@a,$a++,1) } @a;
defined($a[0])||splice@a,0,1; defined($a[$#a])||splice@a,$#a,1;

Первые результаты тестирования.
Относительное время обработки массива:
Для меня оказалось совершенной неожиданностью, что (преобразование массива в строку)-(регулярное выражение)-(обратное преобразование строк в массив) работает быстро.

arto, у меня, к сожалению, не получилось, чтобы твой код выдал то, что я ожидаю. 
Пробовал на массиве 

Это сообщение отредактировал(а) amg - 23.3.2007, 11:15

Попробовал на реальной задаче (когда элементы массива не одно-, а многосимвольные). Вариант с преобразованием массива в строку здесь здорово проигрывает остальным.

ну вот такой уплотненный код для уплотнения массива получился 



Как пустые элементы подразумевается или undef или 0 или строка нулевой длины

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

да, ошибка была.

sub sq {
    my ($a,$b) = (0,0);
    map { defined($_) ? ($a++,$b=0) : ($b++?splice@_,$a,1:$a++); } @_;
    defined($_[0])||splice@_,0,1; defined($_[$#_])||splice@_,$#_,1;
    return @_;
}

(a,undef,undef,undef,undef,undef,undef,b) =>
 (a,undef,b)

(undef,undef,1,2,3,undef,undef,undef,4,undef,5,undef,undef,6,undef,undef) =>
 (1,2,3,undef,4,undef,5,undef,6)

(undef,undef,a,undef,undef,b,undef) =>
 (a,undef,b)

(undef,undef,a) =>
 (a)

(undef,a,undef) =>
 (a)

Ни какой map и grep по условиям задачи не годится.
Вот пробуй:

почему?

  DB<1> sub sq { my ($a,$b) = (0,0); map { $_ ? ($a++,$b=0) : ($b++?splice@_,$a,1:$a++); } @_; $_[0]||splice@_,0,1; $_[$#_]||splice@_,$#_,1; return @_; }

  DB<2> @arr=qw(0 0 a 0 b 0 0 0 0 0 0 0 c c 0 0 0 0 0 0 0 0 0 c c 0 0 0 0 0 0 c c 0 0 d e 0 0);

  DB<3> print '['.$_.']' foreach sq (@arr);
[a][0][b][0][c][c][0][c][c][0][c][c][0][d][e]
  DB<4>

Я вот тут подумал, что с grep еще красивее получиться может:

в данном случае создается второй массив.

http://forum.vingrad.ru/index.php?showtopi...t&p=1072959

my ($a,$b) = (0,0); map { $_ ? ($a++,$b=0) : ($b++?splice@a,$a,1:$a++); } @a; $_[0]||splice@a,0,1; $_[$#_]||splice@a,$#a,1;  -- где временный массив?

arto, это ты о чем говорил? об моем варианте или.... ?

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


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

Единственно правильные варианты для splice считаю, while($i < @array) с самостоятельным контролем позиции в массиве. Я это реализовал у себя в первом варианте.

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

Возможно что и создается второй массив, но он создаеться внутри perl, и думаю вполне оптимально перераспределяется, тогда как использование splice внутри циклов заставляет перл делать еще один внутренний массив, и возможно не один :(... 

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

Это python более ли менее грамотно работает с оптимизацией памяти, т.к. везде, где можно неявно использует ссылки, а в Perl - проще, там онного нету.