Чи кожен алгоритм лінійного часу є алгоритмом потокового?

14

Над цим питанням про підрахунок інверсії я знайшов документ, який доводить нижню межу складності простору для всіх (точних) потокових алгоритмів . Я стверджував, що ця межа поширюється на всі лінійні алгоритми часу. Це трохи сміливо, як і взагалі, лінійний алгоритм часу може стрибати за бажанням (випадковий доступ), який алгоритм потокового потоку не може; він повинен досліджувати елементи в порядку. Я можу виконувати кілька проходів, але тільки постійно багато (для лінійного виконання).

Тому моє запитання:

Чи може кожен алгоритм лінійного часу виражатись як алгоритм потокового потоку з постійно численними пропусками?

Випадковий доступ, здається, перешкоджає (простої) конструкції, що підтверджує позитивну відповідь, але я не зміг придумати зустрічний приклад.

Залежно від моделі машини, випадковий доступ може навіть не бути проблемою для виконання. Мені будуть цікаві відповіді на ці моделі:

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

— Рафаель
джерело

як ви бачите у відповідях, "алгоритми потокової передачі" часто мають на увазі крихітний (полілогічний простір). але з огляду на вашу мотивацію, на мою думку, має бути таке питання: чи може кожен лінійний алгоритм часу, який використовує слів робочої області, перетворити на алгоритм потокового передачі, що використовує простір слів . таким чином, контрприклад може бути проблемою, яку можна вирішити з простором з випадковим доступом, тоді як будь-який алгоритм потокової передачі з постійним проходом вимагає простору. жоден відповідь ще не дав такого прикладу

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)$

Ще одним відомим прикладом є класичний алгоритм вибору лінійного часу .

— А.Шульц
джерело

Ось ще один можливий приклад. Побудова купи займає O (n) і використовує внутрішньо підпрограму на основі ділення та підкорення.

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

але це не доказ, чи не так? ти просто кажеш, що наївне моделювання не буде працювати. але іноді бувають дивовижні алгоритми

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

@SashoNikolov: Що я говорю, це те, що я не розглядаю алгоритм DC3 як алгоритм потокового передачі, оскільки він вимагає багато робочої пам'яті. Можливо, ви можете змінити алгоритм на потоковий алгоритм, але результатом буде не DC3. Я не обговорював, чи існує алгоритм потокової передачі

для побудови суфіксного масиву. Це було б зовсім інше питання.

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)$ $ps = \Omega(\sqrt{n})$ $p$ $s$ $O(\log^2 n)$

— Сашо Ніколов
джерело

1

Навіть у найпростішому визначенні "алгоритму потокової передачі" (алгоритму, який після кожної інкрементальної ітерації на джерелі призводить до негайного знання наступної інкрементальної частини результату), я можу придумати кілька лінійних алгоритмів, які не поводитись так. Алгоритми хешування - великий; FNV-1a лінійна до кількості байтів у джерелі, але ми не знаємо жодної частини остаточного хеша, поки не буде оброблено повне джерело.

RadixSort aka BucketSort - це O (N) (технічно O (NlogM), де M - максимальне значення N елементів, що вважається малим), і повинен виконуватись у повному обсязі, щоб гарантувати, що будь-який окремий предмет знаходиться на останньому місці.

Щоб бути "потоковим" алгоритмом, найпростіше, алгоритм повинен мати такі дві властивості, жодна з яких не є чітко обмеженими часом:

Краще, ніж O (N) складність простору (заявляється рівнозначно, не потрібно знати все джерело і весь результат не потрібно зберігати)
Співвідношення O (N) вводу / виводу (алгоритм створює кількість виходів лінійно пропорційним його входам)

Тому основним класом алгоритмів, які передаються, є алгоритми, які виконують "проекції" (покрокові перетворення одного входу на X> 0 виходів).

— KeithS
джерело

O (\log n)

$O(\log n)$

ω (1)

$\omega(1)$

logN теж добре; справа в тому, що алгоритму не потрібно одразу знати весь вхід або вихід.

— KeithS

Ω (n)

$\Omega(n)$