Montón: proporcione un algoritmo de tiempo para fusionar listas ordenadas en una lista ordenada

Lo más probable es que esta pregunta se haga antes. Es del problema 6.5-8 de CLRS (2nd Ed)

Proporcione un algoritmo de tiempo para fusionar listas ordenadas en una lista ordenada, donde es el número total de elementos en todas las listas de entrada. (Pista: Utilice un min-montón para fusión -way.)k n $O(n \lg k)$$k$$n$$k$

Como hay listas ordenadas y un total de valores, supongamos que cada lista contiene números , además cada una de las listas está ordenada en orden estrictamente ascendente, y los resultados también se almacenarán en orden ascendente orden.n $k$$n$$\frac{n}{k}$

Mi pseudocódigo se ve así:

    list[k]   ; k sorted lists
    heap[k]   ; an auxiliary array to hold the min-heap
    result[n] ; array to store the sorted list
    for i := 1 to k                 ; O(k)
    do
        heap[i] := GET-MIN(list[i]) ; pick the first element 
                                    ; and keeps track of the current index - O(1)
    done
    BUILD-MIN-HEAP(heap) ; build the min-heap - O(k)
    for i := 1 to n
    do
        array[i] := EXTRACT-MIN(heap)   ; store the min - O(logk)
        nextMin := GET-MIN(list[1])     ; get the next element from the list 1 - O(1)
        ; find the minimum value from the top of k lists - O(k)
        for j := 2 to k                 
        do
            if GET-MIN(list[j]) < nextMin
                nextMin := GET-MIN(list[j]) 
        done
        ; insert the next minimum into the heap - O(logk)
        MIN-HEAP-INSERT(heap, nextMin)
    done

Mi complejidad general se convierte en . No pude encontrar ninguna manera de evitar el bucle dentro del bucle para encontrar el siguiente elemento mínimo de las listas k. ¿Hay alguna otra forma de evitarlo? ¿Cómo obtener un algoritmo ?O ( k ) O ( n ) O ( n lg k $O(k) + O(k) + O(n(k + 2 \lg k)) \approx O(nk+n \lg k) \approx O(nk)$$O(k)$$O(n)$$O(n \lg k)$

El propósito del montón es darle el mínimo, por lo que no estoy seguro de cuál es el propósito de este ciclo for for j := 2 to k.

Mi opinión sobre el pseudocódigo:

lists[k][?]      // input lists
c = 0            // index in result
result[n]        // output
heap[k]          // stores index and applicable list and uses list value for comparison
                 // if i is the index and k is the list
                 //   it has functions - insert(i, k) and deleteMin() which returns i,k
                 // the reason we use the index and the list, rather than just the value
                 //   is so that we can get the successor of any value

// populate the initial heap
for i = 1:k                   // runs O(k) times
  heap.insert(0, k)           // O(log k)

// keep doing this - delete the minimum, insert the next value from that list into the heap
while !heap.empty()           // runs O(n) times
  i,k = heap.deleteMin();     // O(log k)
  result[c++] = lists[k][i]
  i++
  if (i < lists[k].length)    // insert only if not end-of-list
    heap.insert(i, k)         // O(log k)

La complejidad del tiempo total es, por lo tanto,$O(k * \log k + n * 2 \log k) = O(n \log k)$

También puede, en lugar de deleteMiny insert, tener un getMin( ) y un ( ), lo que reducirá el factor constante, pero no la complejidad.O ( log k $O(1)$incrementIndex$O(\log k)$

Ejemplo:
(usando el valor en lugar del índice y el índice y el montón de la lista representados como una matriz ordenada para mayor claridad)

Input: [1, 10, 15], [4, 5, 6], [7, 8, 9]

Initial heap: [1, 4, 7]

Delete 1, insert 10
Result: [1]
Heap: [4, 7, 10]

Delete 4, insert 5
Result: [1, 4]
Heap: [5, 7, 10]

Delete 5, insert 6
Result: [1, 4, 5]
Heap: [6, 7, 10]

Delete 6, insert nothing
Result: [1, 4, 5, 6]
Heap: [7, 10]

Delete 7, insert 8
Result: [1, 4, 5, 6, 7]
Heap: [8, 10]

Delete 8, insert 9
Result: [1, 4, 5, 6, 7, 8]
Heap: [9, 10]

Delete 9, insert nothing
Result: [1, 4, 5, 6, 7, 8, 9]
Heap: [10]

Delete 10, insert 15
Result: [1, 4, 5, 6, 7, 8, 9, 10]
Heap: [15]

Delete 15, insert nothing
Result: [1, 4, 5, 6, 7, 8, 9, 10, 15]
Heap: []

Done

En primer lugar, creo que su suposición de que todas las listas que tienen entradas no es válida si el tiempo de ejecución del algoritmo depende de la longitud de la lista más larga .$n/k$

En cuanto a su problema, el siguiente algoritmo debería hacer el truco:

1. Coloque los primeros elementos de las listas en un montón mínimo de tamaño . Recuerde que para cada elemento de la lista al que pertenece. ( )k l m O ( k lg k $H$$k$$l_m$$O(k\lg k)$
2. Para de a hacer: 1 $i$$1$$n$
   • Extraiga el mínimo de y guárdelo en el ( )$m$$H$$result[i]$$O(\lg k)$
   • Inserte el sucesor directo de en (si lo hay) en ( )$m$$l_m$$H$$O(\lg k)$

El tiempo de ejecución es obviamente en y el algoritmo ordena correctamente el .$O(k\lg k + n \lg k)=O(n\lg k)$$result$

Prueba (o al menos, una idea para una prueba). Considere el siguiente bucle invariante: el elemento -ésimo para insertar en el es siempre el mínimo del montón mínimo en el paso y, por lo tanto, el se ordena correctamente después de la iteración -ésima.$i$$result$$H$$i$$result[1..i]$$i$

Esto es cierto antes de la primera iteración: Primero, mostramos que el primer elemento para insertar en el está en : Supongamos hacia una contradicción que el primer elemento para insertar en el (es decir, el elemento más pequeño en general, ) fue No es un primer elemento. Luego, en la lista que contiene , el primer elemento debe ser distinto de (como se supone, no es un primer elemento). Como están ordenados nuestras listas, tenemos incluso , pero esto es una contradicción, ya que elegimos ser la general$result$$H$$result$$r_1$$l$$r_1$$l[1]$$r_1$$r_1$$l[1] < r_1$$r_1$elemento más pequeño Obviamente, el mínimo de todos los primeros elementos es el que se inserta en el .$result$

La invariante se mantiene después de una iteración: procedemos de la misma manera. Suponga que el elemento -ésima para insertar (llaman ) no estaban en . Por construcción, tiene como máximo un elemento de cada lista, y una vez que contiene un elemento de una lista , todos sus predecesores en ya se extrajeron de y (por hipótesis) se insertaron correctamente en el . Por lo tanto, se supone que es el sucesor de algún elemento en la lista . Pero esto es, como arriba, una contradicción, ya que$i$$r_i$$H$$H$$m$$l$$l$$H$$result$$r_i$$m$$l$$l$ está ordenado, y por lo tanto, las reservas invariantes.

Al finalizar, tenemos el correctamente ordenado.$result[1..n]$