Pile divisible

Que sait-on des structures de données qui peuvent maintenir une séquence d'éléments soumis aux deux opérations suivantes?

Appuyez sur (x): ajoutez x à la fin de la séquence et renvoyez un identifiant pour sa position dans la séquence
Extraire (S): étant donné un ensemble d'identificateurs non ordonné, supprimer les éléments dans ces positions de la séquence et renvoyer une liste des éléments supprimés dans l'ordre de séquence

Si vous le souhaitez, vous pouvez considérer cela comme une pile ou une file d'attente avec une opération de fractionnement qui la divise en deux piles: l'opération d'extraction peut être utilisée pour implémenter une opération de pop ou de mise en file d'attente, et la séquence d'extraits d'éléments pourrait également être mise à nouveau dans une autre pile ou file d'attente.

Ce que je sais déjà: on peut maintenir la séquence comme une liste doublement liée, où chaque identifiant n'est qu'un pointeur vers un nœud de liste liée, et chaque nœud stocke également un numéro de position qui permet des comparaisons rapides entre les positions de deux éléments non liés dans la séquence. Il n'est pas difficile de mettre à jour les numéros de position à mesure que la structure de données progresse afin qu'ils soient tous des entiers positifs de valeur maximale , où est le nombre actuel d'éléments dans la liste. Avec cette structure de données, la seule partie difficile d'une opération d'extraction consiste à trier les éléments extraits par leur numéro de position. Une extraction de éléments prend $O(n)$ $n$ $k$ $O(k\sqrt{\log\log k})$ le temps aléatoire attendu en utilisant l'algorithme de tri d'entiers de Han et Thorup de FOCS 2002, par exemple, et une opération de poussée prend un temps constant.

Ce que je ne sais pas: est-il possible de gérer l'extrait en temps et de pousser en temps constant? Existe-t-il de la littérature sur ce problème? Est-ce aussi difficile que le tri entier? $O(k)$

Motivation: c'est l'étape de base nécessaire pour commander les articles dans l'algorithme d'ordonnancement Coffman-Graham, qui a également des applications dans le dessin de graphiques. La partie difficile de Coffman-Graham est un ordre topologique lexicographique. Cela peut être fait en maintenant, pour chaque degré différent, une séquence des sommets avec ce degré dans le sous-graphique induit par les sommets restants. Ensuite, supprimez à plusieurs reprises le premier sommet de la séquence des sommets zéro degré et ajoutez-le à l'ordre topologique; extraire les voisins de des degrés auxquels ils appartenaient auparavant et les pousser sur la séquence pour le degré plus petit suivant. Donc un $v$ $v$ $O(k)$ le temps nécessaire aux opérations d'extraction dans cette structure de données conduirait à une implémentation temporelle linéaire de l'algorithme Coffman-Graham.

Depuis que j'ai posé cette question à l'origine, j'ai trouvé un article de Sethi de 1976 qui permet à l'algorithme Coffman – Graham d'être implémenté en temps linéaire, et je l' ai inclus dans mon article Wikipedia sur l'algorithme Coffman – Graham , de sorte que la motivation d'origine est moins significative. Je suis toujours curieux de savoir quelle est la réponse, cependant.

ds.data-structures

— David Eppstein
source

Si les insertions ne se produisent qu'à la fin de la séquence, vous pouvez conserver à la fois une liste à double lien et une table de hachage des positions des éléments. Insertion: O (1) amorti (il suffit de garder un pointeur sur le dernier élément). Extraction de k éléments: O (k) amorti (pour chaque élément de S, récupérez le pointeur et supprimez-le de la table de hachage, récupérez et supprimez l'élément de la liste et ajoutez-le au résultat de l'extraction).

— Marzio De Biasi

Ce n'est pas l'extraction des éléments de la liste qui prend du temps, c'est leur réorganisation de l'ordre non trié de l'argument pour extraire dans l'ordre de séquence correct.

— David Eppstein

Je pense que c'est au moins aussi difficile que de trier un ensemble d'entiers avec des "conseils aléatoires" de taille polynomiale en . Par conseil aléatoire, je veux dire que pour tout il existe une distribution fixe (dépendant uniquement de ) sur des chaînes de taille poly ( ) et que notre algorithme (modélisé par une machine RAM) a un accès aléatoire à un échantillon unique de . est la structure de données (randomisée) après avoir poussé dans l'ordre, avec une table de hachage qui mappe les entiers aux identificateurs dans le temps attendu . $S \subseteq [n]$ $n$ $n$ ${\cal D}_n$ $n$ $n$ ${\cal D}_n$ ${\cal D}_n$ $[n]$ $O(1)$

Étant donné que la configuration, pour une instance du problème de tri d'entiers, nous pouvons émettre un extrait ( ) (en fait, nous avons besoin des identifiants de mais ce mappage peut être effectué en fois par élément en utilisant le table de hachage qui fait partie de l'avis) et l'entrée sera triée dans le temps nécessaire pour exécuter l'extraction. $S \subseteq [n]$ $S$ $S$ $O(1)$

Ainsi, le message est que, à moins que certaines informations latérales "libres" qui ne dépendent que de la limite supérieure des entiers puissent faciliter le tri des entiers, l'extraction est aussi difficile que le tri des entiers.

Cela implique-t-il une relation entre les deux problèmes sans le modèle étrange? Cette notion de conseil aléatoire est-elle connue? C'est un peu comme un protocole MA, mais le message de Merlin n'est pas autorisé à dépendre de l'entrée et nous nous soucions du temps d'exécution d'Arthur.

— Sasho Nikolov
source

Pousser sur nécessite du temps , donc avoir un accès gratuit à est comme avoir le calcul déjà fait au début de l'algorithme. Comme vous pouvez trier entiers tirés de en temps , il n'y a aucune raison de s'attendre à ce que le tri avec un accès gratuit à cette structure de données prenne plus de temps .

[n]

$[n]$

D_{n}

$\mathcal{D}_n$

Ω (n)

$\Omega(n)$

D_{n}

$\mathcal{D}_n$

Ω (n)

$\Omega(n)$

k

$k$

[n]

$[n]$

O (n + k)

$O(n+k)$

O (k)

$O(k)$

— Dave

Vous avez un calcul donné gratuitement, mais l'accès n'est pas gratuit: chaque requête est facturée comme un pas de temps. Pouvez-vous concevoir afin de pouvoir trier entiers avec des requêtes dans une chaîne tirée de ?

Ω (n)

$\Omega(n)$

D_{n}

${\cal D}_n$

k

$k$

O (k)

$O(k)$

D_{n}

${\cal D}_n$

— Sasho Nikolov

Voici la raison pour laquelle je ne trouve pas cette réponse entièrement convaincante. Si vous n'avez qu'un seul ensemble S d'entiers que vous voulez trier, tout est temps linéaire (il suffit de compter le tri en O (n + k)). Mais si vous essayez d'utiliser cette structure de données pour simuler une séquence de nombreux petits tris (pour que le tri par comptage ne soit pas assez bon), seul le premier de ces petits tris est complètement sans contrainte: après cela, vous avez supprimé certains des éléments de [n], donc chaque séquence que vous triez doit être disjointe des précédentes. Il semble donc difficile de réduire le travail de tri.

— David Eppstein

@David Eppstein: pour les tris vous pouvez prendre des copies de la structure de données initiale. Bien sûr, le modèle étrange de "conseils aléatoires" n'est pas entièrement convaincant, nous aimerions une réduction au sens habituel. Mais le message que je transmettais est qu'un temps de requête implique qu'un algorithme de tri d'entiers peut bénéficier de conseils indépendants de son entrée d'une manière efficace d'accès à la mémoire. C'est contre-intuitif pour moi, mais mon intuition est faible ici. BTW, je pensais que n'est pas le type de temps linéaire dont vous êtes satisfait?

ℓ

$\ell$

ℓ

$\ell$

O (k)

$O(k)$

O (n + k)

$O(n+k)$

— Sasho Nikolov

Si vous copiez la structure de données une fois pour chaque utilisation, vous utilisez le temps pour effectuer une copie pour chaque tri, ce qui n'entraîne pas un tri plus rapide. Si vous interrogez simplement des positions dans une chaîne représentant comme vous semblez le suggérer, il n'est pas clair que cela soit suffisant pour trier en temps . La structure des données peut changer pendant une opération d'extraction et l'exécution sur une version statique peut augmenter le temps d'exécution.

Ω (n)

$\Omega(n)$

D_{n}

$\mathcal{D}_n$

O (k)

$O(k)$

— Dave