Qualcuno può spiegare il concetto alla base della memorizzazione di Haskell?

(nota che sto ponendo la domanda qui perché riguarda la meccanica concettuale di essa, piuttosto che un problema di codifica)

Stavo lavorando a un piccolo programma, che utilizzava una sequenza di numeri di fibonacci nella sua equasion, ma ho notato che se ho superato un certo numero è diventato dolorosamente lento, googling un po 'mi sono imbattuto in una tecnica in Haskell conosciuta come Memoization, hanno mostrato il funzionamento del codice in questo modo:

-- Traditional implementation of fibonacci, hangs after about 30
slow_fib :: Int -> Integer
slow_fib 0 = 0
slow_fib 1 = 1
slow_fib n = slow_fib (n-2) + slow_fib (n-1)

-- Memorized variant is near instant even after 10000
memoized_fib :: Int -> Integer
memoized_fib = (map fib [0 ..] !!)
   where fib 0 = 0
         fib 1 = 1
         fib n = memoized_fib (n-2) + memoized_fib (n-1)

Quindi la mia domanda per voi ragazzi è: come o piuttosto perché funziona?

È perché in qualche modo riesce a scorrere la maggior parte dell'elenco prima che il calcolo raggiunga? Ma se haskell è pigro, non c'è davvero alcun calcolo che deve recuperare ... Quindi, come funziona?

Giusto per spiegare i meccanismi alla base della reale memorizzazione,

memo_fib = (map fib [1..] !!)

produce un elenco di "thunk", calcoli non valutati. Pensa a questi come regali non aperti, finché non li tocchiamo, non correranno.

Ora, una volta valutato un thunk, non lo valutiamo mai più. Questa è in realtà l'unica forma di mutazione nell'hashell "normale", i thunks mutano una volta valutati per diventare valori concreti.

Quindi, tornando al tuo codice, hai un elenco di thunk e fai ancora questa ricorsione dell'albero, ma ricerchi usando l'elenco e una volta valutato un elemento nell'elenco, non viene più calcolato. Pertanto, evitiamo la ricorsione dell'albero nella funzione ingenua fib.

Come nota tangenzialmente interessante, questo è particolarmente veloce su una serie di numeri di fibonnaci calcolati poiché tale elenco viene valutato solo una volta, il che significa che se si calcola memo_fib 10000due volte, la seconda volta dovrebbe essere istantanea. Questo perché Haskell ha valutato gli argomenti in base alle funzioni una sola volta e stai usando un'applicazione parziale invece di una lambda.

TLDR: memorizzando i calcoli in un elenco, ogni elemento dell'elenco viene valutato una volta, pertanto ogni numero di fibonnacci viene calcolato esattamente una volta nell'intero programma.

visualizzazione:

 [THUNK_1, THUNK_2, THUNK_3, THUNK_4, THUNK_5]
 -- Evaluating THUNK_5
 [THUNK_1, THUNK_2, THUNK_3, THUNK_4, THUNK_3 + THUNK_4]
 [THUNK_1, THUNK_2, THUNK_1 + THUNK_2, THUNK_4, THUNK_3 + THUNK_4]
 [1, 1, 1 + 1, THUNK_4, THUNK_3 + THUNK_4]
 [1, 1, 2, THUNK_4, 2 + THUNK4]
 [1, 1, 2, 1 + 2, 2 + THUNK_4]
 [1, 1, 2, 3, 2 + 3]
 [1, 1, 2, 3, 5]

Quindi puoi vedere come la valutazione THUNK_4è molto più veloce poiché le sue sottoespressioni sono già state valutate.

Il punto della memoizzazione non è mai quello di calcolare la stessa funzione due volte: questo è estremamente utile per accelerare i calcoli che sono puramente funzionali, cioè senza effetti collaterali, perché per quelli il processo può essere completamente automatizzato senza influire sulla correttezza. Ciò è particolarmente necessario per funzioni come fibo, che portano alla ricorsione dell'albero , cioè allo sforzo esponenziale, se attuate in modo ingenuo. (Questo è uno dei motivi per cui i numeri di Fibonacci sono in realtà un pessimo esempio per insegnare la ricorsione - quasi tutte le implementazioni demo che trovate in tutorial o libri sono inutilizzabili per valori di input di grandi dimensioni.)

Se segui il flusso di esecuzione, vedrai che nel secondo caso, il valore per fib xsarà sempre disponibile quando fib x+1viene eseguito e il sistema di runtime sarà in grado di leggerlo semplicemente dalla memoria anziché tramite un'altra chiamata ricorsiva, mentre il la prima soluzione tenta di calcolare la soluzione più grande prima che siano disponibili i risultati per valori più piccoli. Questo in definitiva perché l'iteratore [0..n]viene valutato da sinistra a destra e quindi inizierà con 0, mentre la ricorsione nel primo esempio inizia con ne solo allora chiede informazioni n-1. Questo è ciò che porta a molte, molte chiamate di funzione duplicate non necessarie.