Ricorsione - è "dividi e conquista" o "riutilizzo del codice"

La ricorsione - come tutti sappiamo - è uno di quei problemi - che avvolgere la testa sembra come raggiungere una "pietra miliare" nel tuo viaggio di programmazione.

Ma quando si tratta di usarlo effettivamente nei problemi del mondo reale - conoscere la meccanica della ricorsione NON è abbastanza - bisogna anche capire la natura dei problemi in cui la ricorsione è la soluzione più adatta.

Quindi la mia domanda è questa ...

• quali sono i "modelli di problema" che richiedono la soluzione della ricorsione?
• la ricorsione è una forma di strategia di "divisione e conquista" o una forma di "riutilizzo del codice" - oppure è un modello di progettazione a sé stante
• puoi darci un esempio di un problema del mondo reale in cui la ricorsione viene in mente come una soluzione immediata

-- AGGIORNARE --

molte risposte si riferiscono a "problemi reali" come attraversamento di alberi, fattoriali, ecc. Preferirei "i veri problemi reali" - lascia che ti dia un esempio ...

Avevamo un GRANDE blocco di testo (circa 30 MB di testo come un elenco collegato di structs) e dovevamo crearne un indice per la ricerca di testo completo. Dovevamo mantenere l'intero indice in memoria e reindicizzare il testo ogni 10 minuti.

Ogni 10 minuti confronteremmo l'intero testo (due elenchi collegati, riga per riga) con un pezzo di testo appena generato - per vedere quale riga è stata modificata - e quindi indicizzeremmo solo quella riga - in quel modo potremmo evitare di dover reindicizzare il testo INTERO. Ricorda: dovevamo trovare i punti diff tra due elenchi collegati da 30 MB.

Uno dei miei colleghi ha escogitato un fantastico programma che ha usato la ricorsione HEAVY per confrontare le linee - e quindi raccogliere le posizioni in cui i mandrini differivano in un array - sì, lo so che sembra sconcertante - come potrebbe essere utile la ricorsione qui - ma lo ha fatto.

Il punto è: come ha potuto vedere che questo problema potrebbe essere risolto in modo intelligente con un uso intenso della ricorsione?

• quali sono i "modelli di problema" che richiedono la soluzione della ricorsione?

Non direi che esiste un modello di problema per l'uso della ricorsione. Ogni funzione che può essere implementata con ricorsione può anche essere implementata in modo iterativo, spesso spingendo e facendo scoppiare una pila.

È una questione di espressione e anche di prestazione. Gli algoritmi iterativi spesso hanno prestazioni migliori e sono più facili da ottimizzare. Tuttavia, gli algoritmi ricorsivi beneficiano di un'espressione più chiara e quindi sono spesso più facili da leggere, comprendere e implementare.

Alcune cose non possono nemmeno essere espresse senza ricorsione, ad esempio liste infinite. I cosiddetti linguaggi funzionali dipendono fortemente dalla ricorsione, in quanto è il loro modo di esprimersi naturale. Il detto è: "La programmazione ricorsiva è una programmazione funzionale eseguita correttamente".

• la ricorsione è una forma di strategia di "divisione e conquista" o una forma di "riutilizzo del codice" - oppure è un modello di progettazione a sé stante

Non lo definirei un modello di progettazione. È una questione di espressione. A volte un'espressione ricorsiva è semplicemente più potente e più espressiva e porta quindi a un codice migliore e più pulito.

• puoi darci un esempio di un problema del mondo reale in cui la ricorsione viene in mente come una soluzione immediata

Tutto ciò che deve attraversare gli alberi sarà adeguatamente espresso da un algoritmo ricorsivo.

la ricorsione è una forma di strategia di "divisione e conquista" o una forma di "riutilizzo del codice" - oppure è un modello di progettazione a sé stante

Nessuno dei due. Dividi e conquista usa la ricorsione. Ma la ricorsione non è necessariamente una divisione e conquista poiché quest'ultima significa dividere un problema in due (o più) parti e risolverle simmetricamente. In ricorsione, non lo fai.

Il riutilizzo del codice non è completamente correlato e un modello di progettazione entra in gioco a un livello molto più elevato. Ad esempio, persino divide & conquistare (anche un modello di livello superiore rispetto alla ricorsione) non è ancora considerato un modello di progettazione - piuttosto, è un modello algoritmico .

puoi darci un esempio di un problema del mondo reale in cui la ricorsione viene in mente come una soluzione immediata

Traversata di alberi. O più generalmente attraversamento grafico. Ciò include in particolare l'attraversamento di una struttura di cartelle.

E ovviamente tutto ciò che usa divide & conquistare o programmazione dinamica poiché entrambi sono espressi naturalmente in termini di ricorsione.

what are the "problem patterns" that call for the solution of recursion

Derivato dall'auto-somiglianza dei frattali, direi che l'uguaglianza di sé o l'identità di sé (o comunque si chiama) è un tipico modello di problema per la ricorsione. Vale a dire un problema può essere suddiviso in sotto-problemi che hanno la stessa struttura del problema principale.

Nell'attraversamento degli alberi menzionato, ogni sottoalbero è un albero pieno in sé, proprio come l'albero principale, e l'albero principale può essere un sottoalbero all'interno di un altro albero.

Quindi immagino che il tuo collega abbia scoperto le proprietà di uguaglianza del tuo problema di indicizzazione. Oppure ha fatto il contrario e ha trasformato il problema in una rappresentazione eguale.

Bene, la ricorsione può essere facilmente compresa se si tenta di trasformare i loop imperativi in ​​funzioni funzionali. Comunque, proviamo a dare risposte a tutte le domande:

quali sono i "modelli di problema" che richiedono la soluzione della ricorsione?

Se hai una struttura ad albero o un algoritmo avrai bisogno di ricorsione. Se il tuo codice imperativo si occupa di uno stack, avrai bisogno di ricorsione. Se un determinato passaggio nel tuo algoritmo dipende dai passaggi precedenti (think loop), devi ricorrere. Bisogno qui deve essere interpretato come può usare.

la ricorsione è una forma di strategia di "divisione e conquista" o una forma di "riutilizzo del codice" - oppure è un modello di progettazione a sé stante

Nessuna. Dividi e conquista usa la ricorsione, ma può essere implementato con stack. Il riutilizzo del codice si riferisce a qualcos'altro. I modelli di progettazione sono più complicati della semplice ricorsione.

puoi darci un esempio di un problema del mondo reale in cui la ricorsione viene in mente come una soluzione immediata

Analisi e tutto ciò che riguarda le strutture ad albero. Persino strutture ad albero implicite.

Se esiste un modo per semplificarlo in modo che sia facile, questo può essere l'indizio che la ricorsione potrebbe funzionare. È possibile prendere l' ordinamento e la ricerca di esempi in cui esistono rispettivamente soluzioni ricorsive come Merge Sort e Binary Search .

Qualcosa da tenere a mente è come alcuni problemi possano essere risolti male con la ricorsione come un fattoriale.

Per quanto riguarda un esempio del mondo reale in cui utilizzerei la ricorsione, cercare un libro da uno scaffale può essere fatto abbastanza facilmente in modo ricorsivo. Guardo solo il libro e, se non è quello che voglio, passo al prossimo. Mi fermo quando trovo il libro o raggiungo la fine della riga. Il ciclo su come controllare un libro e passare a quello successivo potrebbe essere fatto in modo ricorsivo. Forse questo è troppo reale di un esempio.

quali sono i "modelli di problema" che richiedono la soluzione della ricorsione?

In termini molto generali, la ricorsione è richiesta quando si risolve un problema in cui f (x) = f (g (x)) . A meno che tu non stia bene con la ricorsione infinita, g (x) non dovrebbe valutare in x .

la ricorsione è una forma di strategia di "divisione e conquista" o una forma di "riutilizzo del codice" - oppure è un modello di progettazione a sé stante

Nessuno dei precedenti. È solo un modo per fare la stessa cosa ripetutamente, a volte in base alle variazioni dell'input. Il concetto è stato molto più lungo dei modelli di progettazione, del riutilizzo del codice o persino dei computer, del resto.

puoi darci un esempio di un problema del mondo reale in cui la ricorsione viene in mente come una soluzione immediata

Fattori, sequenza di Fibonacci, attraversamento di alberi e molti altri problemi possono essere risolti con la ricusione. La ricorsione nel senso di una funzione che chiama se stessa non è necessariamente il modo migliore per implementare quel tipo di cose; ci sono altri modi per ottenere lo stesso effetto (ad esempio, uno stack e un loop) che potrebbe essere più desiderabile.

Quando scrivi un algoritmo ricorsivo, di solito traduci una definizione ricorsiva del problema nel codice. Quindi non è nemmeno necessario sapere come verrà eseguito.

È ciò che accade nella programmazione funzionale. In effetti, si specifica cosa (definizione) anziché come . In altre parole, si definisce la base e quindi si definisce il problema nel termine di un sotto-problema.

Ad esempio, considera l' Factorialalgoritmo

• Definisci la base: Factorial (1) = 1;
• Definisci Fattoriale n: Fattoriale (n) = n * Fattoriale (n-1);

Quindi, quando si verifica un problema, si dovrebbe pensare se è possibile definirlo in modo ricorsivo o meno, se è possibile definirlo in modo ricorsivo, è quasi risolto.

Tuttavia, qualsiasi funzione ricorsiva non dovrebbe essere una definizione ricorsiva. È possibile definire la base e correlare (definire) la soluzione del problema principale alla soluzione (definizione) dei sotto-problemi. Ma per questa relazione potresti aver bisogno di una procedura.

Un esempio è MergeSortin cui mergepotrebbe essere una procedura imperativa per mettere in relazione la definizione o la soluzione dell'ordinamento dell'intero array con il tipo di sotto-array.