Quali sono i motivi per apprendere algoritmi / strutture dati differenti che servono allo stesso scopo?

Mi sono chiesto di questa domanda da quando ero uno studente universitario. È una domanda generale, ma elaborerò con esempi di seguito.

Ho visto molti algoritmi - ad esempio, per i problemi di flusso massimo, conosco circa 3 algoritmi che possono risolvere il problema: Ford-Fulkerson, Edmonds-Karp e Dinic, con Dinic che ha la migliore complessità.

Per le strutture di dati - ad esempio heap - ci sono heap binari, heap binomiali e heap di Fibonacci, con l'heap di Fibonacci che presenta la migliore complessità complessiva.

Ciò che mi confonde è: ci sono dei motivi per cui dobbiamo conoscerli tutti? Perché non solo imparare e familiarizzare con la migliore complessità?

So che è il migliore se li conosciamo tutti, voglio solo sapere ci sono ragioni "più valide", come alcuni problemi / algoritmi possono essere risolti solo usando A ma non B , ecc.

C'è un libro di testo in attesa di essere scritto ad un certo punto, con il titolo provvisorio Strutture di dati, algoritmi e compromessi . Quasi ogni algoritmo o struttura di dati che probabilmente imparerai a livello universitario ha alcune funzionalità che lo rendono migliore per alcune applicazioni rispetto ad altre.

Prendiamo l'ordinamento come esempio, poiché tutti hanno familiarità con gli algoritmi di ordinamento standard.

Prima di tutto, la complessità non è l'unica preoccupazione. In pratica, i fattori costanti contano, ed è per questo che (diciamo) l'ordinamento rapido tende ad essere usato più dell'ordinamento dell'heap anche se l'ordinamento rapido ha una terribile complessità nel caso peggiore.

In secondo luogo, c'è sempre la possibilità che ti trovi in ​​una situazione in cui stai programmando con strani vincoli. Una volta ho dovuto eseguire l'estrazione quantile da una raccolta di campioni di dimensioni modeste (circa 1000) il più velocemente possibile, ma era su un piccolo microcontrollore che aveva pochissima memoria di lettura-scrittura di riserva, quindi ha escluso la maggior parte di ordina algoritmi. L'ordinamento Shell è stato il miglior compromesso, poiché era sub-quadratico e non richiedeva memoria aggiuntiva.$O(n \log n)$

In altri casi, le idee di un algoritmo o di una struttura di dati potrebbero essere applicabili a un problema specifico. L'ordinamento delle bolle sembra essere sempre più lento dell'ordinamento di inserzione su hardware reale, ma l'idea di eseguire un passaggio di bolle a volte è esattamente ciò di cui hai bisogno.

Considera, ad esempio, una sorta di visualizzazione 3D o videogioco su una moderna scheda video, in cui desideri disegnare gli oggetti in ordine dal più vicino alla fotocamera al più lontano dalla fotocamera per motivi di prestazioni, ma se non ottieni l'ordine esatto, l'hardware se ne occuperà. Se ti sposti nell'ambiente 3D, l'ordine relativo degli oggetti non cambierà molto tra i fotogrammi, quindi eseguire un passaggio di bolle ogni fotogramma potrebbe essere un compromesso ragionevole. (Il motore Source di Valve lo fa per gli effetti particellari.)

Esistono persistenza, concorrenza, località della cache, scalabilità in un cluster / cloud e una serie di altre possibili ragioni per cui una struttura di dati o un algoritmo può essere più appropriata di un'altra, anche alla luce della stessa complessità computazionale per le operazioni a cui tieni.

Detto questo, ciò non significa che dovresti memorizzare un gruppo di algoritmi e strutture di dati per ogni evenienza. La maggior parte della battaglia si sta rendendo conto che c'è un compromesso da sfruttare in primo luogo, e sapendo dove cercare se pensi che potrebbe esserci qualcosa di appropriato.

A parte il fatto che ci sono miriadi di misure di costo (tempo di esecuzione, utilizzo della memoria, errori nella cache, previsioni errate sulle filiali, complessità di implementazione, fattibilità della verifica ...) su miriadi di modelli di macchine (TM, RAM, PRAM, ...) , il caso medio contro il caso peggiore e le considerazioni relative all'ammortamento che si contrappongono, spesso ci sono anche differenze funzionali oltre l'ambito delle specifiche di base del libro di testo.

Qualche esempio:

• Mergesort è stabile dove Quicksort non lo è.
• Gli alberi di ricerca binari forniscono iterazione in ordine, gli hashtable no.
• Bellman-Ford è in grado di gestire pesi con bordi negativi, Dijkstra no.

Ci sono anche considerazioni didattiche da fare:

• Quanto è facile capire una soluzione più coinvolta prima di una più semplice? (Alberi AVL (e loro analisi) senza BST; Dinic senza Ford-Fulkerson; ...)
• Vedi gli stessi principi e schemi quando sei esposto a una sola soluzione per problema rispetto a quando sei esposto a molte soluzioni?
• L'esposizione a una sola soluzione per problema fornisce una formazione sufficiente (verso la padronanza)?
• Dovresti conoscere l'ampiezza di quali soluzioni sono state trovate (in modo da impedirti di reinventare la ruota ancora e ancora¹)?
• Se esposto a una sola soluzione per problema, capirai altre soluzioni che trovi in ​​natura (diciamo, in una biblioteca di programmazione del mondo reale)?

1. Questo è qualcosa che vediamo molto dai tipi di programmatori che non hanno una ricca cassetta degli attrezzi CS a loro disposizione.

Nel mondo reale , a un certo punto probabilmente lavorerai su un software che è stato scritto da un team di altre persone. Alcuni di questi software saranno stati scritti prima della tua nascita!

Al fine di comprendere gli algoritmi / le strutture di dati utilizzati, è molto utile conoscere un gran numero di algoritmi / strutture di dati, comprese le opzioni che non sono più considerate "allo stato dell'arte".

Dovrai anche lavorare su algoritmi che non sono standard e vengono utilizzati solo nell'applicazione su cui stai lavorando. Quando devi migliorare questi algoritmi, scoprirai che il tuo cervello è stato riempito con metodi utili per migliorare gli algoritmi, poiché hai studiato come altre persone hanno migliorato gli algoritmi.

Questo è ciò che distingue qualcuno che ha studiato informatica a parte qualcuno che ha appena imparato a programmare. Nella maggior parte dei lavori in cui ho lavorato, quando ho studiato informatica ho potuto risolvere un problema che un programmatore "imparato dai libri" non poteva, ma il 95% delle volte ho scoperto che aver studiato informatica non mi ha dato alcun vantaggio rispetto ad altri programmatori esperti .

Molte persone hanno giustamente menzionato che spesso non esiste un algoritmo migliore - dipende dalla situazione.

C'è anche la possibilità che un giorno ti imbatterai in una situazione sconosciuta. Più algoritmi conosci, più possibilità avrai di conoscerne uno che è quasi una soluzione che puoi usare come base.

Molte grandi risposte, solo qualcosa che penso manchi, anche se la risposta di Raphael menziona in qualche modo questo.

Anche la facilità di implementazione è qualcosa da prendere in considerazione.
Questo di solito non è un problema con gli algoritmi di ordinamento, perché la maggior parte delle piattaforme / lingue ne ha già implementato uno (e spesso migliore di quello che potresti fare), ma potrebbero non essere disponibili algoritmi più insoliti.
A seconda del problema, potrebbe non essere necessario l'algoritmo migliore in assoluto se il tempo di implementazione è di 1 giorno contro 2 settimane.