Esiste un algoritmo di "ordinamento" che restituisce una permutazione casuale quando si utilizza un comparatore a gettoni?

Ispirato da questa domanda in cui chi chiede sapere se il tempo di esecuzione cambia quando il comparatore utilizzato in un algoritmo di ricerca standard viene sostituito da un discreto lancio di monete, e anche dall'incapacità di Microsoft di scrivere un generatore di permutazione uniforme, la mia domanda è quindi :

Esiste un algoritmo di ordinamento basato sul confronto che, a seconda della nostra implementazione del comparatore:

1. restituisce gli elementi in ordine ordinato quando si utilizza un comparatore reale (ovvero, il confronto fa quello che ci aspettiamo in un algoritmo di ordinamento standard)
2. restituisce una permutazione uniformemente casuale degli elementi quando il comparatore viene sostituito da un lancio di moneta equo (ovvero, restituisce x < y = truecon probabilità 1/2, indipendentemente dal valore di xe y)

Il codice per l'algoritmo di ordinamento deve essere lo stesso. È solo il codice all'interno del confronto "scatola nera" che può cambiare.

Il seguente algoritmo deterministico (senza il comparatore) funziona per una tupla di input :$(a_1,\dots,a_n)$

1. Do la Fisher-Yates Shuffle usare il comparatore con una certa coppia statica (ad esempio ) (campionamento per accettazione-rifiuto facendo) come un coin flip. Se il comparatore emette 1 la prima volta, utilizzarlo invertito per evitare un loop di rifiuto infinito nel caso deterministico.$a_1 < a_2$$1$
2. (speedup opzionale: prova una singola coppia volte, dove n è la lunghezza o il tuo input. Se una qualsiasi delle due uscite differisce, restituisci la permutazione ottenuta in (1))$n$$n$
3. Ordina il tuo array usando unisci ordinamento.

Data una relazione di ordine deterministico come comparatore, questo algoritmo ordina un array nel tempo poiché il shuffle Fisher-Yates viene eseguito in O ( n ) usando i "bit casuali" non casuali di O ( log n ) (ad es. Chiamate al comparatore ) in ogni passaggio e unisci l'ordinamento ha la stessa complessità asintotica. Il risultato di (1) è totalmente inutile in questo caso, ma poiché è seguito da un tipo reale, questo non fa male.$\mathcal{O}(n \log n)$$\mathcal{O}(n)$$\mathcal{O}(\log n)$

Dato un vero lancio della moneta come comparatore (1) consente l'array con uguale probabilità per ogni permutazione e se davvero devi fare (3) (hai lasciato fuori (2) o (2) non è riuscito a determinare la casualità), questo non è danno perché la distribuzione del suo risultato dipende solo dall'ordine del suo input che è uniformemente distribuito tra tutte le permutazioni a causa di (1), quindi anche il risultato dell'intero algoritmo è distribuito uniformemente. Il numero di volte in cui ogni campionamento di accettazione-rifiuto deve essere ripetuto viene distribuito geometricamente (respingi con probabilità ) e quindi ha un valore atteso<2. Ogni ripetizione utilizza al massimolognbit, quindi l'analisi di runtime è quasi la stessa del caso deterministico, ma otteniamo solo unruntime previstodiO(nlogn), con possibilità di non termine (termina soloquasi sicuramente).$< \frac{1}{2}$$< 2$$\log n$$\mathcal{O}(n \log n)$

---

Come ha sottolineato Joe: se non ti piace il test per il primo bit in (1), fai (3) quindi (1) e usa che è sempre 0 , poiché l'array è già ordinato nel caso deterministico. Inoltre, devi sottrarre il tuo numero casuale dal limite superiore dell'intervallo nel loop, poiché il limite superiore per il numero casuale produce la permutazione identica. Ma tieni presente che (2) è proibito allora, perché devi sempre fare la riproduzione casuale nel caso del riscatto.$a_n < a_1$$0$

---

Puoi anche usare le stesse chiamate al tuo comparatore per (1) e (3), ma poi dimostrare che il risultato è distribuito uniformemente è almeno molto più difficile, se possibile affatto.

---

Il seguente algoritmo non ha fasi distinte per la riproduzione casuale e l'ordinamento, ma è asintoticamente più lento. È essenzialmente un ordinamento per inserzione con ricerca binaria . Userò per indicare l'input e b k = ( b k , 1 , … , b k , k ) per indicare il risultato dopo il k -esimo giro:$a=(a_1,\dots,a_n)$$b_k=(b_{k,1},\dots,b_{k,k})$$k$

1. Impostare $b_{1,1} = a_1$
2. Se allora b 2 = ( a 2 , a 1 ) e ( c , d ) : = ( 2 , 1 ) altrimenti b 2 = ( a 1 , a 2 ) e ( c , d ) : = ( 1 , 2 ) . In entrambi i casi a d$a_2 < a_1$$b_2 = (a_2,a_1)$$(c,d):= (2,1)$$b_2 = (a_1,a_2)$$(c,d):= (1,2)$ sarà sempre 0 (ovvero falso) per un comparatore non casuale.$a_d < a_c$$0$
3. Per ottenere per k ≥ 3, ottenere prima b k - 1 .$b_{k}$$k \geq 3$$b_{k-1}$
4. Sia e k ′ = 2 l , ovvero k ′ è la potenza minima di 2 non inferiore a k .$l=\lceil log_2 k \rceil$$k' = 2^l$$k'$$2$$k$
5. Lasciate . Per ogni j ∈ { 1 , … , l } let i j = { i j - 1 + 2 l - j i j - 1 + 2 l - j > k - 1 ∧ a d < a c i j - 1 i j - 1 + 2 l $i_0 = 0$$j \in \{1,\dots,l\}$ $$i_j = \begin{cases} i_{j-1} + 2^{l-j} & i_{j-1} + 2^{l-j} > k-1 \wedge a_d < a_c\\ i_{j-1} & i_{j-1} + 2^{l-j} > k-1 \wedge \neg (a_d < a_c)\\ i_{j-1} + 2^{l-j} & i_{j-1} + 2^{l-j} \leq k-1 \wedge b_{k-1,i_{j-1} + 2^{l-j}} < a_k \\ i_{j-1} & i_{j-1} + 2^{l-j} \leq k-1 \wedge \neg(b_{k-1,i_{j-1} + 2^{l-j}} < a_k) \\ \end{cases}$$
6. $i_l > k$$b_k=(b_{k-1,1},\dots,b_{k-1,i_l -1},a_k,b_{k-1,i_l},\dots,b_{k-1,k-1})$
7. $b_n$

$k-1$$k$

Si noti che questo algoritmo è inefficiente in entrambe le modalità rispetto allo shuffle Fisher-Yates e unisci l'ordinamento poiché l'inserimento di un elemento in una posizione arbitraria è costoso se l'utilizzo di un array e la ricerca binaria richiedono tempo lineare se si utilizza un elenco. Ma forse una modifica dell'ordinamento heap o dell'albero in un modo simile potrebbe portare a un algoritmo più veloce.

$n \leq 2$$A/2^B$$1/n!$$n > 2$$1/n!$$A/2^B$