Является ли каждый алгоритм линейного времени алгоритмом потоковой передачи?

14

В этом вопросе о подсчете инверсий я нашел статью, в которой доказывается нижняя оценка сложности пространства для всех (точных) потоковых алгоритмов . Я утверждал, что эта граница распространяется на все линейные алгоритмы времени. Это немного жирным шрифтом, так как в целом, алгоритм линейного времени может перемещаться по желанию (произвольный доступ), что алгоритм потоковой передачи не может; он должен исследовать элементы по порядку. Я могу выполнить несколько проходов, но только постоянно много (для линейного времени выполнения).

Поэтому мой вопрос:

Может ли каждый алгоритм линейного времени быть выражен как алгоритм потоковой передачи с постоянно большим количеством проходов?

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

В зависимости от модели машины, произвольный доступ может даже не быть проблемой с точки зрения времени выполнения. Мне были бы интересны ответы на эти модели:

Машина Тьюринга, плоский ввод
RAM, ввод в виде массива
RAM, вход в виде связанного списка

— Рафаэль
источник

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

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

. таким образом, контрпример мог бы быть проблемой, которая может быть решена с помощью пространства

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

. ответ пока не дал такого примера

s

$s$

O (s)

$O(s)$

o (n)

$o(n)$

Ω (n)

$\Omega(n)$

— Сашо Николов

@SashoNikolov: На самом деле, весь космический вопрос является касательным. Мой вопрос в основном о времени выполнения. Если бы ответ был «да», то нижние оценки (по сложности пространства), доказанные в статье, будут применяться ко всем алгоритмам с линейным временем. То, что нижняя граница находится в пространстве, является случайным, но не является предметом вопроса как таковым.

— Рафаэль

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

». Таким образом, вы должны выбрать меру сложности, о, это не имеет смысла.

μ

$\mu$

— Сашо Николов

@SashoNikolov: я не знал, что у «алгоритма потоковой передачи» были такие проблемы с определением. Учитывая, что они показывают нижнюю границу линейного пространства для потоковых алгоритмов, я предположил, что пространство не является ядром определения. Но я думаю, вы могли бы перевести эту границу на «Нет алгоритма потоковой передачи ...». Тем не менее, как насчет этого определения: «Алгоритм потоковой передачи - это алгоритм, которому дается вход (список) по одному элементу за раз. Для каждого нового элемента он может выполнять вычисления в

. После постоянного множества таких проходов , он должен вывести ответ через дополнительное время

. "

o (n)

$o(n)$

o (n)

$o(n)$

— Рафаэль

@SashoNikolov: Это исключило бы алгоритмы «копировать входные данные и делать что-либо» из понятия, но ограничить его временем

. Это соответствует обычно обозначаемому классу? Если нет, я не думаю, что «потоковое» может быть определено с течением времени или пространственных сложностей в полезных. Это скорее стратегия, очень похожая на Жадность или разделяй и властвуй.

o (n^{2})

$o(n^2)$

— Рафаэль

15

Чтобы потоковые алгоритмы имели смысл, они должны работать со значительно меньшим объемом рабочего пространства, чем сам ввод. Например, если вы разрешите тот же объем рабочего пространства, что и для ввода, вы можете тривиально сформулировать любой алгоритм как «алгоритм потоковой передачи за один проход», который сначала копирует входные данные в рабочее пространство за один проход, а затем использует только работу. Космос.

Я думаю, что типично ограничивать рабочее пространство до максимально полилогарифмического размера ввода, когда речь идет об потоковых алгоритмах. При этом допущении медианный отбор не имеет алгоритма потоковой передачи O (1) в результате Манро и Патерсона [MP80]: любой алгоритм потоковой передачи P- прохода для медианного выбора на N элементах должен хранить Ω ( N ^{1 / P)} ) элементы. С другой стороны, медианный отбор имеет хорошо известный детерминистический алгоритм линейного времени [BFPRT73].

[BFPRT73] Мануэль Блюм, Роберт У. Флойд, Вон Пратт, Рональд Л. Ривест и Роберт Э. Тарьян. Границы времени для выбора. Журнал компьютерных и системных наук , 7 (4): 448–461, август 1973. DOI: 10.1016 / S0022-0000 (73) 80033-9

[MP80] Дж. Ян Мунро и Майк С. Патерсон. Выбор и сортировка с ограниченным хранением. Теоретическая информатика , 12 (3): 315–323, ноябрь 1980 г. DOI: 10.1016 / 0304-3975 (80) 90061-4

— Цуёси Ито
источник

6

В потоковой модели вам разрешено хранить только постоянные или полулогарифмические дополнительные данные при сканировании через входные данные. Если вы рассматриваете алгоритм линейного времени,
который следует парадигме « разделяй и властвуй» , вам нужно хранить больше информации и / или вы должны сканировать свои данные столько раз, сколько глубина рекурсии.

Одним из примеров является алгоритм DC3 для построения суффиксного массива текста (заданного как массив в модели RAM). Чтобы создать массив суффиксов, вы группируете символы в триплеты, поэтому вы получаете текст с новыми суперсимволами . Вы можете сделать это со смещением , что приводит к трем новым текстам $T$ $0,1,2$ . Интересно, что вы можете вычислить массив суффиксов, если у вас есть массив суффиксов за линейное время. Следовательно, алгоритм нуждается $T_1,T_2,T_3$ $T_1\cdot T_2$

t (n) = t (2 / 3 n) + O (n)

$t(n)= t(2/3 \;n) + O(n)$

время. Эта рекурсия решает четко $t(n)=O(n)$ . Я не понимаю, как это можно превратить в алгоритм потоковой передачи.

Другой хорошо известный пример - классический алгоритм выбора линейного времени .

— A.Schulz
источник

Вот еще один возможный пример. Для построения кучи требуется O (n) и внутренне используется подпрограмма heapify () на основе «разделяй и властвуй».

— Массимо Кафаро

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

— Сашо Николов

O (n)

$O(n)$

«Я не понимаю, как это можно превратить в алгоритм потоковой передачи», заставил меня поверить, что вы что-то говорите, кроме «этот алгоритм не выполняет потоковую передачу без изменений»

— Сашо Николов

4

Я интерпретирую ваш вопрос следующим образом. Давайте исправим некоторые вычислительные проблемы $P$

$R(P)$ $P$
$S(P)$ $P$

$R(P)$ $S(P)$ может быть .

$n$ $[1, n-1]$ $O(\log n)$ $O(1)$ $\omega(\log n)$

$O(1/\log^2 n)$ , Затем Chakrabarti et al. показать, что если мы ограничим все проходы в одном направлении, мы имеем $ps = \Omega(\sqrt{n})$ , где $p$ это количество проходов и $s$ это космическая сложность. С другой стороны, Magniez et al. дать простой алгоритм, который использует $O(\log^2 n)$ пространство, имеет полиномиально малую вероятность ложного срабатывания, и делает один проход вперед и один назад.

— Сашо Николов
источник

1

Даже в простейшем определении «алгоритма потоковой передачи» (алгоритм, который после каждой инкрементальной итерации источника приводит к немедленному знанию следующей инкрементальной части результата), я могу представить несколько линейных алгоритмов, которые не вести себя так. Алгоритмы хеширования являются большими; FNV-1a является линейным по отношению к количеству байтов в источнике, но мы не знаем какой-либо части окончательного хэша, пока не будет обработан полный источник.

RadixSort, иначе BucketSort - это O (N) (технически O (NlogM), где M - максимальное значение в N элементах, которое считается небольшим), и должно выполняться полностью, чтобы гарантировать, что любой отдельный элемент находится на своем последнем месте.

Чтобы быть «потоковым» алгоритмом, в самом простом случае алгоритм должен иметь следующие два свойства, ни одно из которых явно не ограничено по времени:

Лучше, чем O (N) сложность пространства (указано эквивалентно, весь источник не должен быть известен, и весь результат не должен быть сохранен)
Отношение O (N) I / O (алгоритм выдает количество выходов, линейно пропорциональных его входам)

Таким образом, основной класс алгоритмов этого потока - это алгоритмы, которые выполняют «проекции» (инкрементные преобразования одного входа в X> 0 выходов).

— Keiths
источник

Почему бы

O (\log n)

$O(\log n)$ использование пространства не будет в порядке? Статьи, связанные в другом вопросе, играют с множеством потоковых алгоритмов, которые используют

ω (1)

$\omega(1)$ Космос.

— Рафаэль

logN тоже хорошо; Дело в том, что алгоритм не должен знать сразу все входные или выходные данные.

— KeithS

Ω (n)

$\Omega(n)$ Требование к пространству не означает, что ему нужен весь ввод данных (т.е. это не алгоритм потоковой передачи). Но я понимаю вашу точку зрения.

— Рафаэль