Chaque algorithme à temps linéaire est-il un algorithme de streaming?

14

Plus à cette question sur le comptage d'inversion , j'ai trouvé un article qui prouve une limite inférieure sur la complexité de l'espace pour tous les algorithmes de streaming (exacts) . J'ai affirmé que cette limite s'étend à tous les algorithmes de temps linéaire. C'est un peu audacieux car en général, un algorithme de temps linéaire peut sauter à volonté (accès aléatoire) qu'un algorithme de streaming ne peut pas; il doit enquêter sur les éléments dans l'ordre. Je peux effectuer plusieurs passes, mais seulement constamment plusieurs (pour une exécution linéaire).

Par conséquent ma question:

Chaque algorithme de temps linéaire peut-il être exprimé comme un algorithme de streaming avec constamment de nombreuses passes?

L'accès aléatoire semble empêcher une (simple) construction de prouver une réponse positive, mais je n'ai pas non plus été en mesure de trouver un contre-exemple.

Selon le modèle de la machine, l'accès aléatoire peut même ne pas être un problème, au niveau de l'exécution. Je serais intéressé par les réponses pour ces modèles:

Machine de Turing, entrée plate
RAM, entrée sous forme de tableau
RAM, entrée sous forme de liste chaînée

— Raphael
source

comme vous le voyez dans les réponses, les «algorithmes de streaming» impliquent souvent de minuscules (espace polylog). mais étant donné votre motivation, je pense que la question devrait être: chaque algorithme de temps linéaire qui utilise

mots de l'espace de travail peut-il être converti en un algorithme de streaming qui utilise l' espace des mots

. un contre-exemple serait donc un problème qui peut être résolu avec un espace

avec un accès aléatoire alors que tout algorithme de streaming à passage constant nécessite un espace

. aucune réponse n'a encore donné un tel exemple

s

$s$

O (s)

$O(s)$

o (n)

$o(n)$

Ω (n)

$\Omega(n)$

— Sasho Nikolov

@SashoNikolov: En fait, toute la question de l'espace est tangentielle. Ma question concerne principalement l'exécution. Si la réponse était "oui", alors les limites inférieures (sur la complexité de l'espace) prouvées dans l'article s'appliqueraient à tous les algorithmes de temps linéaire. Le fait que la limite inférieure se situe dans l'espace est accessoire, mais ce n'est pas l'objet de la question en soi.

— Raphael

Je ne comprends pas. Il est trivial de faire d'un algorithme de temps linéaire un "streaming en un seul passage" avec un espace illimité. Votre question n'a de sens que si sous la forme "un algorithme à accès aléatoire à temps linéaire peut-il être rendu continu en continu tout en préservant approximativement la mesure de complexité

". Vous devez donc choisir une mesure de complexité, dont cela n'a aucun sens.

μ

$\mu$

— Sasho Nikolov

@SashoNikolov: Je ne savais pas que "l'algorithme de streaming" avait de tels problèmes de définition. Étant donné qu'ils montrent un espace linéaire limite inférieure pour les algorithmes de streaming, j'ai supposé que l'espace n'était pas le cœur d'une définition. Mais je suppose que vous pourriez traduire cela en "Il n'y a pas d'algorithme de streaming ...". Cependant, qu'en est-il de cette définition: "Un algorithme de streaming est un algorithme qui reçoit l'entrée (liste) un élément à la fois. Pour chaque nouvel élément, il peut effectuer un calcul en

. Après constamment plusieurs de ces passes , il doit produire une réponse après un délai supplémentaire de

. "

o (n)

$o(n)$

o (n)

$o(n)$

— Raphael

@SashoNikolov: Cela exclurait les algorithmes "copier l'entrée et faire n'importe quoi" de la notion, mais la limiterait au temps

. Cela correspond-il à la classe habituellement désignée? Sinon, je ne pense pas que le "streaming" puisse être défini dans le temps ou dans des complexités spatiales utiles. C'est plutôt une stratégie, un peu comme Greedy ou divide & conquer.

o (n^{2})

$o(n^2)$

— Raphael

15

Pour que les algorithmes de streaming soient significatifs, ils doivent travailler avec une quantité d'espace de travail beaucoup plus petite que l'entrée elle-même. Par exemple, si vous autorisez la même quantité d'espace de travail que l'entrée, vous pouvez déclarer trivialement n'importe quel algorithme comme un «algorithme de streaming en un seul passage» qui copie d'abord l'entrée dans l'espace de travail en un seul passage, puis utilise uniquement le travail espace.

Je pense qu'il est typique de restreindre l'espace de travail à tout au plus polylogarithmique dans la taille d'entrée lorsque l'on parle d'algorithmes de streaming. Dans cette hypothèse, la sélection médiane n'a pas d'algorithme de diffusion en continu O (1) par le résultat de Munro et Paterson [MP80]: tout algorithme de diffusion en continu P pour la sélection médiane sur N éléments doit stocker Ω ( N ^{1 / P} ) éléments. D'autre part, la sélection médiane a un algorithme déterministe de temps linéaire bien connu [BFPRT73].

[BFPRT73] Manuel Blum, Robert W. Floyd, Vaughan Pratt, Ronald L. Rivest et Robert E. Tarjan. Limites de temps pour la sélection. Journal of Computer and System Sciences , 7 (4): 448–461, août 1973. DOI: 10.1016 / S0022-0000 (73) 80033-9

[MP80] J. Ian Munro et Mike S. Paterson. Sélection et tri avec stockage limité. Informatique théorique , 12 (3): 315–323, novembre 1980. DOI: 10.1016 / 0304-3975 (80) 90061-4

— Tsuyoshi Ito
source

6

Dans le modèle de streaming, vous êtes uniquement autorisé à stocker des données supplémentaires constantes ou poly-logarithmiques lors de la numérisation via l'entrée. Si vous envisagez un algorithme de temps linéaire
qui suit le paradigme diviser pour régner , vous devez stocker plus d'informations et / ou vous devez parcourir vos données autant de fois que la profondeur de la récursivité.

Un exemple est l' algorithme DC3 pour construire le tableau de suffixes d'un texte (donné comme tableau dans le modèle RAM). Afin de construire un tableau de suffixes, vous regroupez les caractères en triplets, vous obtenez donc un texte avec de nouveaux super-caractères . Vous pouvez le faire avec un décalage de , ce qui donne trois nouveaux textes . Fait intéressant, vous pouvez calculer le tableau de suffixes si vous avez le tableau de suffixes de en temps linéaire. D'où l'algorithme a besoin $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)$

temps. Cette récursivité résout clairement à $t(n)=O(n)$ . Je ne vois pas comment cela peut être transformé en un algorithme de streaming.

Un autre exemple bien connu est l' algorithme classique de sélection en temps linéaire.

— A.Schulz
source

Voici un autre exemple possible. La construction d'un tas prend O (n) et utilise en interne le sous-programme heapify () basé sur la division et la conquête.

— Massimo Cafaro

mais ce n'est pas une preuve, n'est-ce pas? vous dites simplement qu'une simulation naïve ne fonctionnera pas. mais il y a parfois des algorithmes surprenants

— Sasho Nikolov

@SashoNikolov: Ce que je dis, c'est que je ne considère pas l'algorithme DC3 comme un algorithme de streaming, car il nécessite beaucoup de mémoire de travail. Vous pouvez peut-être modifier l'algorithme en un algorithme de streaming, mais le résultat ne serait pas le DC3. Je n'ai pas discuté de l'existence d'un algorithme de streaming

pour la construction d'un tableau de suffixes. Ce serait une question complètement différente.

O (n)

$O(n)$

— A.Schulz

"Je ne vois pas comment cela peut être transformé en un algorithme de streaming" m'a fait croire que vous dites autre chose "cet algorithme n'est pas en streaming sans modification"

— Sasho Nikolov

4

J'interprète votre question comme suit. Fixons un problème de calcul . Nous définissons: $P$

est le plus petit espace de travail qu'un algorithme d'accès aléatoire temporel linéaire pour puisse avoir. Je pense que le modèle exact n'a pas beaucoup d'importance, mais disons que nous avons un mot RAM qui reçoit l'entrée sous forme de tableau en lecture seule à accès aléatoire. $R(P)$ $P$
$S(P)$ est le plus petit espace de travail qu'un algorithme séquentiel pour puisse avoir; ici, nous supposons que l'algorithme (qui est à nouveau modélisé comme une machine RAM de mots) se déroule en pas de temps: à chaque pas de temps, une cellule du tableau d'entrée est donnée, l'algorithme effectue un traitement, enregistre des informations dans son stockage local, et passe ensuite au pas de temps suivant. Le tableau est "bouclé" un nombre constant de fois de cette manière. $P$

Je pense donc que vous demandez quelle est la différence entre et $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)$

— Sasho Nikolov
source

1

Même dans la définition la plus simple d '"algorithme de streaming" (un algorithme qui, après chaque itération incrémentielle sur la source, entraîne la connaissance immédiate de la prochaine partie incrémentielle du résultat), je peux penser à quelques algorithmes linéaires qui ne le font pas se comporter de cette façon. Les algorithmes de hachage sont importants; FNV-1a est linéaire par rapport au nombre d'octets dans la source, mais nous ne connaissons aucune partie du hachage final tant que la source complète n'a pas été traitée.

RadixSort aka BucketSort est O (N) (techniquement O (NlogM) où M est la valeur maximale dans les N éléments, qui est considérée comme petite), et doit fonctionner dans son intégralité pour garantir que chaque élément individuel est à sa place finale.

Pour être un algorithme de "streaming", au plus simple, un algorithme doit avoir les deux propriétés suivantes, dont aucune n'est expressément limitée dans le temps:

Meilleure que la complexité de l'espace O (N) (déclaré de manière équivalente, la source entière n'a pas à être connue et le résultat entier n'a pas à être stocké)
Relation E / S O (N) (l'algorithme produit un certain nombre de sorties linéairement proportionnelles à ses entrées)

Par conséquent, la principale classe d'algorithmes qui diffusent est celle des algorithmes qui effectuent des "projections" (transformations incrémentielles d'une entrée vers X> 0 sorties).

— KeithS
source

O (\log n)

$O(\log n)$

ω (1)

$\omega(1)$

logN est très bien aussi; le fait était que l'algorithme ne devrait pas avoir besoin de connaître la totalité de l'entrée ou de la sortie à la fois.

— KeithS

Ω (n)

$\Omega(n)$