Algoritmi di ordinamento che accettano un comparatore casuale

Gli algoritmi di ordinamento generici generalmente richiedono un set di dati per l'ordinamento e una funzione di confronto che può confrontare due singoli elementi. Se il comparatore è una relazione d'ordine¹, l'output dell'algoritmo è un elenco / array ordinato.

Mi chiedo però quali algoritmi di ordinamento funzionerebbero effettivamente con un comparatore che non è una relazione d'ordine (in particolare uno che restituisce un risultato casuale su ogni confronto). Per "lavoro" intendo qui che continuano a restituire una permutazione del loro input e corrono alla loro complessità temporale tipicamente quotata (al contrario di degradare sempre allo scenario peggiore, o andare in un ciclo infinito o elementi mancanti). L'ordinamento dei risultati sarebbe tuttavia indefinito. Ancora meglio, l'ordinamento risultante sarebbe una distribuzione uniforme quando il comparatore è un lancio di moneta.

Dal mio rozzo calcolo mentale sembra che un tipo di unione andrebbe bene con questo e mantenga lo stesso costo di runtime e produca un ordinamento casuale equo. Penso che qualcosa come una specie veloce sarebbe comunque degenerato, forse non finirà, e non sarebbe giusto.

Quali altri algoritmi di ordinamento (diversi da unisci ordinamento) funzionerebbero come descritto con un comparatore casuale?

1. Per riferimento, un comparatore è una relazione d'ordine se è una funzione propria (deterministica) e soddisfa gli assiomi di una relazione d'ordine:

   • è deterministico: compare(a,b)per un particolare ae brestituisce sempre lo stesso risultato.
   • è transitivo: compare(a,b) and compare(b,c) implies compare( a,c )
   • è antisimmetrico compare(a,b) and compare(b,a) implies a == b

(Supponiamo che tutti gli elementi di input siano distinti, quindi la riflessività non è un problema.)

Un comparatore casuale viola tutte queste regole. Esistono tuttavia comparatori che non sono relazioni d'ordine ma non sono casuali (ad esempio potrebbero violare forse solo una regola e solo per elementi particolari dell'insieme).

Quindi, in sostanza, vuoi sapere se esiste un algoritmo di ordinamento che non si degraderebbe dal suo caso medio se avesse una funzione di confronto simile a:

int Compare(object a, object b) { return Random.Next(-1,1); }

... dove Random.Next () è un metodo che produrrà un numero intero generato casualmente tra un limite inferiore e superiore inclusi.

La risposta è in realtà che la maggior parte degli algoritmi di ordinamento di base funzionerà secondo il loro caso medio, perché obbediscono ad almeno una delle due seguenti condizioni:

1. Un confronto tra due elementi unici non viene mai effettuato due volte nell'ordinamento e / o
2. In ogni iterazione dell'ordinamento, viene determinata la posizione corretta di almeno un elemento e quindi l'elemento non viene mai più confrontato.

Ad esempio, SelectionSort scorre l'elenco secondario di elementi non ordinati, trova l'elemento "minimo" e / o "maggiore" (confrontando ciascuno con il massimo finora), lo posiziona nella posizione corretta e si ripete. Di conseguenza, anche con un comparatore non deterministico, alla fine di ogni iterazione l'algoritmo avrà trovato un valore che ritiene minimo o maggiore, lo scambia con l'elemento nella posizione che sta cercando di determinare e non considera mai quell'elemento di nuovo, quindi obbedisce alla Condizione 2. Tuttavia, A e B possono essere confrontati più volte durante questo processo (come esempio più estremo, considera diversi passaggi di SelectionSort su un array che è ordinato in ordine inverso), quindi viola la Condizione 1 .

MergeSort obbedisce alla Condizione 1 ma non a 2; man mano che i sotto-array vengono uniti, gli elementi nello stesso sotto-array (sul lato sinistro o destro) non vengono confrontati tra loro perché è già stato stabilito che gli elementi su quel lato dell'array sono in ordine tra loro; l'algoritmo confronta solo l'elemento meno immerso di ciascun subarray con l'altro per determinare quale è minore e dovrebbe andare successivamente nell'elenco unito. Ciò significa che due oggetti unici A e B verranno confrontati tra loro al massimo una volta, ma l'indice "finale" di un determinato elemento nell'intera raccolta non è noto fino a quando l'algoritmo non è completo.

InsertionSort obbedisce solo alla Condizione 1, anche se la sua strategia e complessità complessive assomigliano più a SelectionSort. Ogni elemento non ordinato viene confrontato con elementi ordinati, il più grande per primo, fino a quando non ne viene trovato uno inferiore all'elemento in esame. l'elemento viene inserito in quel punto e quindi viene considerato l'elemento successivo. Il risultato è che l'ordine relativo di qualsiasi A e B è determinato da un confronto, e ulteriori confronti tra tale A e B non vengono mai eseguiti, ma la posizione finale di qualsiasi elemento non può essere conosciuta fino a quando non vengono considerati tutti gli elementi.

QuickSort obbedisce ad entrambiCondizioni. Ad ogni livello, un perno viene scelto e disposto in modo tale che il lato "sinistro" contenga elementi inferiori al perno e il lato "destro" contenga elementi maggiori del perno. Il risultato di quel livello è QuickSort (a sinistra) + pivot + QuickSort (a destra) che sostanzialmente significa che la posizione dell'elemento pivot è nota (un indice maggiore della lunghezza del lato sinistro), il pivot non viene mai confrontato con nessun altro elemento dopo che è stato scelto come perno (potrebbe essere stato confrontato con elementi pivot precedenti, ma quegli elementi sono anche noti e non sono inclusi in alcun subarrays), E qualsiasi A e B che finiscono su lati opposti del perno non sono mai rispetto. Nella maggior parte delle implementazioni di QuickSort puro, il caso base è un elemento, a quel punto il suo indice corrente è il suo indice finale e non vengono effettuati ulteriori confronti.

$(2/3)^{N-1}$). All'aumentare del valore assoluto massimo del risultato del comparatore, la probabilità che uno qualsiasi di questi confronti ritorni negativo o zero diminuisce verso 0,5, rendendo la possibilità di terminare l'algoritmo molto meno probabile (la possibilità di 99 gettoni lancia tutte le teste di atterraggio , che è sostanzialmente ciò a cui si riduce, è 1 in 1,2 * 10 ³⁰ )

EDIT A LATER LONG TIME: Ci sono alcuni "tipi" progettati specificamente come esempi di cosa non fare che incorporano un comparatore casuale; forse il più famoso è BogoSort. "Dato un elenco, se l'elenco non è in ordine, mescola l'elenco e ricontrolla". Teoricamente alla fine colpirà la giusta permutazione di valori, proprio come il "BubbleSort non ottimizzato" sopra, ma il caso medio è tempo fattoriale (N! / 2), e a causa del problema del compleanno (dopo sufficienti permutazioni casuali tu diventare più probabilità di incontrare permutazioni duplicate rispetto a quelle uniche) c'è una possibilità diversa da zero che l'algoritmo che non si completa ufficialmente non è limitato nel tempo.

$O(n^2)$

$n$

Modifica: il problema è più interessante come ho pensato per la prima volta, quindi ecco un ulteriore commento:

$compare$$compare(x,y)=true$$1/2$$false$$1/2$

insert x [] = [x]
insert x y:ys = if x < y then x:y:ys
                else y:insert x ys

sort_aux l e = match l with
                 [] -> e
                 x:xs -> sort_aux xs (insert x ys)

sort l = sort_aux l []

$\sum_{k=1}^{n} f(k)$$n$$l$$f(k)$$insert$$k$$:$

$compare$

$O(2n)$$O(n^2)$

Sarebbe divertente calcolare i tempi di esecuzione medi per i diversi altri algoritmi data questa funzione di confronto uniforme.

Mergesort con un comparatore casuale equo non è giusto. Non ho una prova, ma ho prove empiriche MOLTO forti. (Fiera significa uniformemente distribuito.)

module Main where

import Control.Monad
import Data.Map (Map)
import qualified Data.Map as Map
import System.Random (randomIO)

--------------------------------------------------------------------------------

main :: IO ()
main = do
  let xs = [0..9]
  xss <- replicateM 100000 (msortRand xs)
  print $ countFrequencies xss

msortRand :: [a] -> IO [a]
msortRand = msort (\_ _ -> randomIO)

countFrequencies :: (Ord a) => [[a]] -> [Map a Int]
countFrequencies [] = []
countFrequencies xss = foldr (\k m -> Map.insertWith (+) k 1 m) Map.empty ys : countFrequencies wss
  where
    ys = map head xss
    zss = map tail xss
    wss = if head zss == []
      then []
      else zss

--------------------------------------------------------------------------------

msort :: (Monad m) => (a -> a -> m Bool) -> [a] -> m [a]
msort (<) [] = return []
msort (<) [x] = return [x]
msort (<) xs = do
  ys' <- msort (<) ys
  zs' <- msort (<) zs
  merge (<) ys' zs'
  where
    (ys, zs) = split xs

merge :: (Monad m) => (a -> a -> m Bool) -> [a] -> [a] -> m [a]
merge (<) [] ys = return ys
merge (<) xs [] = return xs
merge (<) (x:xs) (y:ys) = do
  bool <- x < y
  if bool
    then liftM (x:) $ merge (<) xs (y:ys)
        else liftM (y:) $ merge (<) (x:xs) ys

split :: [a] -> ([a], [a])
split [] = ([], [])
split [x] = ([x], [])
split (x:y:zs) = (x:xs, y:ys)
  where
    (xs, ys) = split zs

Una domanda molto correlata trova risposta in Tutti i tipi di permutazioni (perla funzionale) di Christiansen, Danilenko e Dylus. Eseguono un algoritmo di ordinamento nella monade elenco , che simula essenzialmente il non determinismo, restituendo tutte le permutazioni di un determinato elenco di input. La proprietà interessante è che ogni permutazione viene restituita esattamente una volta.

Citando dall'abstract:

...

In questo articolo esaminiamo la combinazione di non determinismo e ordinamento in una luce diversa: data una funzione di ordinamento, la applichiamo a un predicato non deterministico per ottenere una funzione che enumera le permutazioni dell'elenco di input. Arriviamo in fondo alle proprietà necessarie degli algoritmi di ordinamento e dei predicati in gioco e discutiamo delle variazioni del non determinismo modellato.

Inoltre, formuliamo e dimostriamo un teorema che afferma che, indipendentemente dalla funzione di ordinamento che utilizziamo, la funzione di permutazione corrispondente elenca tutte le permutazioni dell'elenco di input. Usiamo teoremi liberi, che sono derivati ​​dal tipo di una sola funzione, per provare l'affermazione.