¿Son útiles las estructuras de datos de búsqueda probabilística?

9

Un SkipList proporciona los mismos límites para la búsqueda que un árbol equilibrado con la ventaja de que no es necesario reequilibrar. Dado que SkipList se construye utilizando lanzamientos aleatorios de monedas, estos límites solo se mantienen mientras la estructura de SkipList esté suficientemente "equilibrada". En particular, con probabilidad para alguna constante , la estructura equilibrada podría perderse después de insertar un elemento. $O(\log n)$ $1/n^c$ $c>0$

Digamos que quiero usar una lista de omisión como back-end de almacenamiento en una aplicación web que potencialmente se ejecuta para siempre. Entonces, después de un número polinómico de operaciones, es muy probable que se pierda la estructura equilibrada de SkipList.

¿Es correcto mi razonamiento? ¿Estas estructuras de datos probabilísticos de búsqueda / almacenamiento tienen aplicaciones prácticas y, de ser así, cómo se evita el problema anterior?

Editar: Soy consciente de que hay variantes deterministas de SkipList, que son mucho más complicadas de implementar en comparación con la SkipList aleatoria (clásica).

data-structures search-trees probabilistic-algorithms

— alguien
fuente

1

¿Qué aplicación específica tienes en mente?

— Pratik Deoghare

6

No creo que haya una probabilidad polinómica para perder el "equilibrio". Después de insertar un elemento en una lista de omisión, construye una torre de copias encima lanzando una moneda hasta que salga cara.

Entonces tienes capas con cada vez menos elementos a medida que alcanzas la parte superior. Como una torre tiene una altura con probabilidad , hay un elemento en la altura con probabilidad (límite de unión) de menos de . Por lo tanto, tener un elemento en el nivel tiene una probabilidad menor que . Las torres de altura tienen probabilidad subpolinómica. Deje que sea el nivel máximo, entonces tenemos $k$ $2^{-k}$ $k$ $n/2^k$ $c\log n$ $1/n^c$ $\omega(\log n)$ $M$

mi [METRO] = \sum_{k \geq 1} PAGS r (METRO \geq k) \leq Iniciar sesión (norte) + \sum_{k \leq Iniciar sesión (norte)} norte / / 2^{k} = Iniciar sesión (norte) + 2)

$E[M] = \sum_{k\geq 1} Pr(M\geq k) \leq \log(n) + \sum_{k\le \log(n)} n/2^k = \log(n) + 2.$

Además, en el nivel hay elementos con una probabilidad muy alta, ya que esta es la suma de variables aleatorias independientes y puede usar el límite de Chernov. $k$ $n/2^k$ $n$

Como también puede demostrar que solo realiza un número constante de pasos por nivel (¡con una probabilidad muy alta!), Los costos de búsqueda son logarítmicos.

Por lo tanto, tendría que ser muy desafortunado para terminar con una lista desequilibrada. Tenga en cuenta que 'suerte' aquí es independiente de sus datos, a diferencia de, por ejemplo, en los árboles de búsqueda desequilibrados. Los lanzamientos de monedas en las listas de salto son siempre aleatorios.

Hasta donde yo sé, las listas de omisión son de gran interés práctico, porque es relativamente fácil implementarlas como estructuras de búsqueda sin bloqueo, con los beneficios obvios. Los árboles B, por otro lado, son bastante difíciles de realizar bajo accesos concurrentes.

— adrianN
fuente

La profundidad esperada de los árboles de búsqueda binarios también es logarítmica; ¿Por qué la situación es mejor aquí? (Además, supones permutaciones aleatorias, ¿correcto?)

— Raphael

2

En los árboles de búsqueda, la profundidad depende de los datos. Si lo alimenta con números aleatorios, tiene una profundidad logarítmica con una probabilidad muy alta. Sin embargo, en la práctica, los datos no son aleatorios. Las listas de omisión no usan los datos como fuente de aleatoriedad, por lo que este problema no existe.

— adrianN

1

Las listas de omisión tienen otras propiedades que pueden hacerlas atractivas en situaciones en las que se usan otras operaciones además de insertar / buscar / eliminar.

$O(1)$ $O(1)$

Además, las listas de omisión han sido una forma popular de implementar estructuras de búsqueda concurrentes basadas en comparaciones. Históricamente, los árboles de búsqueda equilibrados no han funcionado tan bien bajo una alta contienda concurrente.

— jbapple
fuente