Esistono algoritmi del mondo reale che superano notevolmente le prestazioni nella classe sottostante? [chiuso]

Ieri sera stavo discutendo con un altro programmatore che anche se qualcosa potrebbe essere O (1), un'operazione che è O (n) potrebbe sovraperformarla se c'è una grande costante nell'algoritmo O (1). Non era d'accordo, quindi l'ho portato qui.

Ci sono esempi di algoritmi che superano notevolmente quelli della classe sottostante? Ad esempio, O (n) è più veloce di O (1) o O (n ² ) è più veloce di O (n).

Matematicamente questo può essere dimostrato per una funzione con limiti superiori asintotici, quando si ignorano i fattori costanti, ma esistono tali algoritmi in natura? E dove troverei esempi di questi? Per quali tipi di situazioni vengono utilizzati?

Ricerche in tabelle di dati fisse molto piccole. Una tabella hash ottimizzata può essere O (1) e tuttavia più lenta di una ricerca binaria o persino di una ricerca lineare a causa del costo del calcolo dell'hash.

Moltiplicazione di matrici. L'algoritmo O naïve (n ^ 3) è spesso usato in pratica più veloce di O (n ^ 2.8) di Strassen per le matrici di piccole dimensioni; e Strassen è usato al posto dell'algoritmo O (n ^ 2.3) Coppersmith – Winograd per matrici più grandi.

Un semplice esempio è la differenza tra vari algoritmi di ordinamento. Mergesort, Heapsort e alcuni altri sono O (n log n) . Quicksort è il caso peggiore O (n ^ 2) . Ma spesso Quicksort è più veloce, e in effetti si comporta in media come O (n log n) . Maggiori informazioni .

Un altro esempio è la generazione di un singolo numero di Fibonacci. L'algoritmo iterativo è O (n) , mentre l'algoritmo basato su matrice è O (log n) . Tuttavia, per la prima coppia di migliaia di numeri di Fibonacci, l'algoritmo iterativo è probabilmente più veloce. Questo dipende anche dall'implementazione ovviamente!

Gli algoritmi con una migliore prestazione asintotica possono contenere operazioni costose che non sono necessarie con un algoritmo con prestazioni peggiori ma operazioni più semplici. Alla fine, la notazione O ci dice qualcosa sulle prestazioni solo quando l'argomento su cui opera aumenta drammaticamente (si avvicina all'infinito).

Nota: si prega di leggere i commenti di @ back2dos di seguito e di altri guru, in quanto sono in effetti più utili di quello che ho scritto - Grazie per tutti i collaboratori.

Penso dalla tabella qui sotto (presa da: notazione Big O , cerca "The Pessimistic Nature of Algorithms:"), puoi vedere che O (log n) non è sempre meglio di dire, O (n). Quindi, immagino che il tuo argomento sia valido.

Per valori pratici di n, sì. Questo emerge molto nella teoria CS. Spesso esiste un algoritmo complicato che ha prestazioni big-Oh tecnicamente migliori, ma i fattori costanti sono così grandi da renderlo impraticabile.

Una volta ho avuto il mio professore di geometria computazionale che descriveva un algoritmo per triangolare un poligono in tempo lineare, ma ha finito con "molto complicato. Non credo che nessuno l'abbia effettivamente implementato" (!!).

Inoltre, i mucchi di fibonacci hanno caratteristiche migliori rispetto ai mucchi normali, ma non sono molto popolari perché in pratica non si comportano bene come i mucchi normali. Questo può arrivare ad altri algoritmi che usano i cumuli - per esempio, i percorsi più brevi di Dijkstra sono matematicamente più veloci con un mucchio di fibonacci, ma di solito non in pratica.

Confronta l'inserimento in un elenco collegato e l'inserimento in un array ridimensionabile.

La quantità di dati deve essere abbastanza grande affinché la lista collegata O (1) sia utile.

Un elenco collegato ha un sovraccarico aggiuntivo per i puntatori e le dereferenze successive. Un array ridimensionabile deve copiare i dati in giro. Quella copia è O (n), ma in pratica molto veloce.

La notazione Big-Oh viene utilizzata per descrivere il tasso di crescita di una funzione, quindi è possibile che un algoritmo O (1) sia più veloce, ma solo fino a un certo punto (il fattore costante).

Notazioni comuni:

O (1) - Il numero di iterazioni (a volte è possibile fare riferimento a questo come tempo dell'utente trascorso dalla funzione) non dipende dalla dimensione dell'input ed è infatti costante.

O (n) - Il numero di iterazioni aumenta in proporzione lineare alla dimensione dell'input. Significato: se l'algoritmo scorre attraverso qualsiasi input N, 2 * N volte, viene comunque considerato O (n).

O (n ^ 2) (quadratico) - Il numero di iterazioni è la dimensione di input al quadrato.

Le librerie Regex sono di solito implementate per eseguire il backtracking che presenta tempi esponenziali nel caso peggiore anziché la generazione di DFA che presenta una complessità di O(nm).

Il backtracking ingenuo può essere un performer migliore quando l'input rimane sul percorso veloce o fallisce senza la necessità di backtracking eccessivo.

(Sebbene questa decisione non sia solo basata sulle prestazioni, è anche consentire riferimenti a ritroso).

Un O(1)algoritmo:

def constant_time_algorithm
  one_million = 1000 * 1000
  sleep(one_million) # seconds
end

Un O(n)algoritmo:

def linear_time_algorithm(n)
  sleep(n) # seconds
end

Chiaramente, per qualsiasi valore di ncui n < one_million, O(n)l'algoritmo dato nell'esempio sarà più veloce rispetto al O(1)algoritmo.

Mentre questo esempio è un po 'faceto, è equivalente nello spirito al seguente esempio:

def constant_time_algorithm
  do_a_truckload_of_work_that_takes_forever_and_a_day
end

def linear_time_algorithm(n)
  i = 0
  while i < n
    i += 1
    do_a_minute_amount_of_work_that_takes_nanoseconds
  end
end

tu necessario conoscere le costanti e coefficienti nella vostra Oespressione, e si deve conoscere la gamma prevista n, al fine di determinare a priori quale algoritmo finirà per essere più veloce.

Altrimenti tu necessario confrontare i due algoritmi con valori compresi nnell'intervallo previsto per determinare a posteriori quale algoritmo sia risultato più veloce.

Ordinamento:

L'ordinamento per inserzione è O (n ^ 2) ma supera gli altri algoritmi di ordinamento O (n * log (n)) per un numero limitato di elementi.

Questo è il motivo per cui la maggior parte delle implementazioni di ordinamento utilizza una combinazione di due algoritmi. Ad esempio, utilizzare l'ordinamento per unire le grandi matrici fino a quando non raggiungono un array di determinate dimensioni, quindi utilizzare l'ordinamento per inserimento per ordinare le unità più piccole e unirle nuovamente con l'ordinamento per unione.

Vedi Timsort l'attuale implementazione predefinita dell'ordinamento Python e Java 7 che utilizza questa tecnica.

Il algoritmo di unificazione utilizzato nella pratica è esponenziale nel peggiore dei casi, per alcuni input patologici.

Esiste un algoritmo di unificazione polinomiale , ma in pratica è troppo lento.

Bubblesort in memoria può sovraperformare quicksort quando il programma viene scambiato su disco o è necessario leggere ogni elemento dal disco durante il confronto.

Questo dovrebbe essere un esempio a cui può riferirsi.

Spesso gli algoritmi più avanzati presuppongono una certa quantità di configurazione (costosa). Se devi eseguirlo solo una volta, potresti stare meglio con il metodo della forza bruta.

Ad esempio: la ricerca binaria e la ricerca della tabella hash sono entrambe molto più veloci per ricerca una ricerca lineare, ma richiedono di ordinare rispettivamente l'elenco o creare la tabella hash.

L'ordinamento ti costerà N log (N) e la tabella hash costerà almeno N. Ora se hai intenzione di fare centinaia o migliaia di ricerche, è comunque un risparmio ammortizzato. Ma se hai solo bisogno di fare una o due ricerche, potrebbe avere senso semplicemente fare la ricerca lineare e risparmiare i costi di avvio.

La decrittazione è spesso 0 (1). Ad esempio, lo spazio chiave per DES è 2 ^ 56, quindi la decrittografia di qualsiasi messaggio è un'operazione a tempo costante. È solo che hai un fattore di 2 ^ 56 lì, quindi è una costante davvero grande.

Mi vengono in mente diverse implementazioni di set. Uno dei più ingenui è implementarlo su un vettore, il che significa removeche anche containse quindi addprendere anche O (N).
Un'alternativa è implementarlo su un hash di uso generale, che associa gli hash di input ai valori di input. Un'implementazione di questo tipo esegue con O (1) per add, containseremove .

Se supponiamo che N sia circa 10, la prima implementazione è probabilmente più veloce. Tutto quello che deve fare per trovare un elemento è confrontare 10 valori con uno.
L'altra implementazione dovrà iniziare ogni sorta di trasformazioni intelligenti, che possono essere molto più costose, rispetto a fare 10 confronti. Con tutto il sovraccarico, potresti anche avere dei cali della cache e quindi non importa davvero quanto velocemente la tua soluzione sia in teoria.

Ciò non significa che l'implementazione peggiore a cui puoi pensare supererà una decente, se N è abbastanza piccolo. Significa semplicemente per N sufficientemente piccolo, che un'implementazione ingenua, con ingombro ridotto e sovraccarico può effettivamente richiedere meno istruzioni e causare meno errori di cache rispetto a un'implementazione che mette al primo posto la scalabilità e sarà quindi più veloce.

Non puoi davvero sapere quanto è veloce qualcosa in uno scenario del mondo reale, fino a quando non lo metti in uno e lo misuri semplicemente. Spesso i risultati sono sorprendenti (almeno per me).

Sì, per N. adeguatamente piccolo Ci sarà sempre una N, sopra la quale avrai sempre l'ordinamento O (1) <O (lg N) <O (N) <O (N log N) <O (N ^ c ) <O (c ^ N) (dove O (1) <O (lg N) significa che in un algoritmo O (1) verranno eseguite meno operazioni quando N è adeguatamente grande e c è una costante fissa maggiore di 1 ).

Supponiamo che un particolare algoritmo O (1) esegua esattamente f (N) = 10 ^ 100 (a googol) operazioni e un algoritmo O (N) esegua esattamente g (N) = 2 N + 5 operazioni. L'algoritmo O (N) fornirà prestazioni maggiori finché N non sarà più o meno un googol (in realtà quando N> (10 ^ 100 - 5) / 2), quindi se ti aspettavi che N fosse compreso tra 1000 e un miliardo di subirebbe una penalità maggiore usando l'algoritmo O (1).

O per un confronto realistico, supponiamo che si stiano moltiplicando i numeri di n cifre. L' algoritmo Karatsuba è al massimo 3 n ^ (lg 3) operazioni (ovvero circa O (n ^ 1.585)) mentre l' algoritmo Schönhage – Strassen è O (N log N log log N) che è un ordine più veloce , ma per citare wikipedia:

In pratica l'algoritmo di Schönhage – Strassen inizia a sovraperformare i metodi più vecchi come la moltiplicazione di Karatsuba e Toom – Cook per numeri oltre 2 ^ 2 ^ 15 a 2 ^ 2 ^ 17 (da 10.000 a 40.000 cifre decimali). [4] [5] [6 ]

Quindi, se si moltiplicano i numeri di 500 cifre insieme, non ha senso utilizzare l'algoritmo "più veloce" per grandi argomenti O.

EDIT: Puoi trovare determinare f (N) rispetto a g (N), prendendo il limite N-> infinito di f (N) / g (N). Se il limite è 0, allora f (N) <g (N), se il limite è infinito, allora f (N)> g (N), e se il limite è un'altra costante, allora f (N) ~ g (N) in termini di notazione O grande.

Il metodo simplex per la programmazione lineare può essere esponenziale nel peggiore dei casi, mentre algoritmi di punti interni relativamente nuovi possono essere polinomiali.

Tuttavia, in pratica, non si presenta il caso peggiore esponenziale per il metodo simplex: il metodo simplex è veloce e affidabile, mentre i primi algoritmi di punti interni erano troppo lenti per essere competitivi. (Ora ci sono algoritmi di punti interni più moderni che sono competitivi - ma anche il metodo simplex è ...)

L'algoritmo di Ukkonen per la creazione di tentativi di suffisso è O (n log n). Ha il vantaggio di essere "on-line", ovvero puoi aggiungere in modo incrementale più testo.

Recentemente, altri algoritmi più complessi hanno affermato di essere più veloci nella pratica, soprattutto perché il loro accesso alla memoria ha una località più elevata, migliorando così l'utilizzo della cache del processore ed evitando le stalle della pipeline della CPU. Vedi, ad esempio, questo sondaggio , che afferma che il 70-80% del tempo di elaborazione viene impiegato in attesa di memoria e questo documento che descrive l'algoritmo "wotd".

I tentativi di suffisso sono importanti in genetica (per abbinare le sequenze geniche) e, un po 'meno importante, nell'implementazione dei dizionari Scrabble.

C'è sempre l'algoritmo più veloce e più breve per qualsiasi problema ben definito . Tuttavia, è solo teoricamente l'algoritmo (asintoticamente) più veloce.

Data una descrizione di un problema P e un'istanza per quel problema io , enumera tutte le possibili algoritmi A e prove Pr , controllando per ciascuna di tali coppie se Pr è una prova valida che A è l'algoritmo asintoticamente veloce per P . Se trova una tale prova, che poi esegue una su I .

La ricerca di questa coppia a prova di problema ha una complessità O (1) (per un problema risolto P ), quindi si utilizza sempre l'algoritmo asintoticamente più veloce per il problema. Tuttavia, poiché questa costante è così indicibilmente enorme in quasi tutti i casi, questo metodo è completamente inutile nella pratica.

Molti linguaggi / framework usano una corrispondenza dei pattern ingenua per abbinare le stringhe anziché KMP . Cerchiamo stringhe come Tom, New York piuttosto che ababaabababababaababababababab.