¿Cómo se memoriza esta función de fibonacci?

¿Mediante qué mecanismo se memoriza esta función de fibonacci?

fib = (map fib' [0..] !!)                 
     where fib' 1 = 1                                                        
           fib' 2 = 1                                                        
           fib' n = fib (n-2) + fib (n-1)                    

Y en una nota relacionada, ¿por qué esta versión no?

fib n = (map fib' [0..] !! n)                                               
     where fib' 1 = 1                                                        
           fib' 2 = 1                                                        
           fib' n = fib (n-2) + fib (n-1)                    

El mecanismo de evaluación en Haskell es por necesidad : cuando se necesita un valor, se calcula y se mantiene listo en caso de que se vuelva a solicitar. Si definimos alguna lista, xs=[0..]y luego preguntamos por su elemento número 100 xs!!99, el espacio número 100 de la lista se "completa", manteniendo el número 99ahora, listo para el siguiente acceso.

Eso es lo que está explotando ese truco de "revisar una lista". En la definición normal de Fibonacci doblemente recurrente fib n = fib (n-1) + fib (n-2), la función en sí se llama, dos veces desde arriba, lo que provoca la explosión exponencial. Pero con ese truco, establecemos una lista para los resultados provisionales y revisamos "la lista":

fib n = (xs!!(n-1)) + (xs!!(n-2)) where xs = 0:1:map fib [2..]

El truco es hacer que se cree esa lista y hacer que esa lista no desaparezca (mediante la recolección de basura) entre llamadas a fib. La forma más sencilla de lograrlo es nombrar esa lista. "Si lo nombras, se quedará".

Su primera versión define una constante monomórfica y la segunda define una función polimórfica. Una función polimórfica no puede usar la misma lista interna para diferentes tipos que podría necesitar servir, por lo que no se comparte , es decir, no se memoriza.

Con la primera versión, el compilador está siendo generoso con nosotros, eliminando esa subexpresión constante ( map fib' [0..]) y convirtiéndola en una entidad que se puede compartir por separado, pero no tiene ninguna obligación de hacerlo. ^{y hay casos en los que no queremos que lo haga por nosotros automáticamente.}

( editar :) Considere estas reescrituras:

fib1 = f                     fib2 n = f n                 fib3 n = f n          
 where                        where                        where                
  f i = xs !! i                f i = xs !! i                f i = xs !! i       
  xs = map fib' [0..]          xs = map fib' [0..]          xs = map fib' [0..] 
  fib' 1 = 1                   fib' 1 = 1                   fib' 1 = 1          
  fib' 2 = 1                   fib' 2 = 1                   fib' 2 = 1          
  fib' i=fib1(i-2)+fib1(i-1)   fib' i=fib2(i-2)+fib2(i-1)   fib' i=f(i-2)+f(i-1)

Entonces, la verdadera historia parece ser sobre las definiciones de alcance anidadas. No hay un alcance externo con la primera definición, y la tercera tiene cuidado de no llamar al alcance externo fib3, sino al mismo nivel f.

Cada nueva invocación de fib2parece crear sus definiciones anidadas de nuevo porque cualquiera de ellas podría (en teoría) definirse de manera diferente dependiendo del valor de n(gracias a Vitus y Tikhon por señalar eso). Con la primera definición no hay de nqué depender, y con la tercera hay una dependencia, pero cada llamada separada a fib3llamadas a las fque se tiene cuidado de llamar solo definiciones del alcance del mismo nivel, interno a esta invocación específica de fib3, por lo que lo mismo se xsobtiene reutilizado (es decir, compartido) para esa invocación de fib3.

Pero nada impide que el compilador reconozca que las definiciones internas en cualquiera de las versiones anteriores son de hecho independientes del nenlace externo , para realizar el levantamiento lambda después de todo, lo que resulta en una memorización completa (a excepción de las definiciones polimórficas). De hecho, eso es exactamente lo que sucede con las tres versiones cuando se declaran con tipos monomórficos y se compilan con el indicador -O2. Con declaraciones de tipo polimórfico, fib3exhibe compartición local y fib2no compartición en absoluto.

En última instancia, según el compilador y las optimizaciones del compilador utilizadas, y cómo lo prueba (cargando archivos en GHCI, compilados o no, con -O2 o no, o independiente), y si obtiene un tipo monomórfico o polimórfico, el comportamiento podría cambiar por completo, ya sea que muestre uso compartido local (por llamada) (es decir, tiempo lineal en cada llamada), memorización (es decir, tiempo lineal en la primera llamada y tiempo 0 en llamadas posteriores con el mismo argumento o un argumento menor), o sin compartir en absoluto ( tiempo exponencial).

La respuesta corta es que es cosa de compiladores. :)

No estoy del todo seguro, pero he aquí una suposición fundamentada:

El compilador asume que fib npodría ser diferente en una diferente ny por lo tanto necesitaría recalcular la lista cada vez. Después de todo, los bits dentro de la wheredeclaración podrían depender n. Es decir, en este caso, la lista completa de números es esencialmente una función de n.

La versión sin n puede crear la lista una vez y envolverla en una función. La lista no puede depender del valor de npasado y esto es fácil de verificar. La lista es una constante que luego se indexa. Es, por supuesto, una constante que se evalúa de forma perezosa, por lo que su programa no intenta obtener la lista completa (infinita) inmediatamente. Dado que es una constante, se puede compartir entre las llamadas a funciones.

Se memoriza en absoluto porque la llamada recursiva solo tiene que buscar un valor en una lista. Dado que la fibversión crea la lista una vez de forma perezosa, solo calcula lo suficiente para obtener la respuesta sin hacer cálculos redundantes. Aquí, "lazy" significa que cada entrada en la lista es un procesador (una expresión no evaluada). Al no evaluar el golpe seco, se convierte en un valor, por lo que el acceso a la próxima vez no sin repetir el cálculo. Dado que la lista se puede compartir entre llamadas, todas las entradas anteriores ya están calculadas para cuando necesite la siguiente.

Es esencialmente una forma inteligente y de bajo costo de programación dinámica basada en la semántica perezosa de GHC. Creo que el estándar solo especifica que tiene que ser no estricto , por lo que un compilador compatible podría compilar este código para no memorizar. Sin embargo, en la práctica, todo compilador razonable será vago.

Para obtener más información sobre por qué el segundo caso funciona, lea Comprensión de una lista definida de forma recursiva (fibs en términos de zipWith) .

Primero, con ghc-7.4.2, compilado con -O2, la versión no memorizada no es tan mala, la lista interna de números de Fibonacci todavía se memoriza para cada llamada de nivel superior a la función. Pero no se puede memorizar, ni razonablemente, en las diferentes llamadas de alto nivel. Sin embargo, para la otra versión, la lista se comparte entre llamadas.

Eso se debe a la restricción del monomorfismo.

El primero está limitado por un patrón de enlace simple (solo el nombre, sin argumentos), por lo tanto, por la restricción de monomorfismo debe obtener un tipo monomorfo. El tipo inferido es

fib :: (Num n) => Int -> n

y dicha restricción se establece por defecto (en ausencia de una declaración predeterminada que diga lo contrario) a Integer, fijando el tipo como

fib :: Int -> Integer

Por lo tanto, solo hay una lista (de tipo [Integer]) para memorizar.

El segundo se define con un argumento de función, por lo que sigue siendo polimórfico, y si las listas internas se memorizaran a través de las llamadas, se tendría que memorizar una lista para cada tipo Num. Eso no es práctico.

Compile ambas versiones con la restricción de monomorfismo desactivada o con firmas de tipo idénticas, y ambas exhiben exactamente el mismo comportamiento. (Eso no fue cierto para las versiones anteriores del compilador, no sé qué versión lo hizo primero).

No necesita la función de memoria para Haskell. Solo el lenguaje de programación empirativo necesita esas funciones. Sin embargo, Haskel es lenguaje funcional y ...

Entonces, este es un ejemplo de algoritmo de Fibonacci muy rápido:

fib = zipWith (+) (0:(1:fib)) (1:fib)

zipWith es una función de Prelude estándar:

zipWith :: (a->b->c) -> [a]->[b]->[c]
zipWith op (n1:val1) (n2:val2) = (n1 + n2) : (zipWith op val1 val2)
zipWith _ _ _ = []

Prueba:

print $ take 100 fib

Salida:

[1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040,1346269,2178309,3524578,5702887,9227465,14930352,24157817,39088169,63245986,102334155,165580141,267914296,433494437,701408733,1134903170,1836311903,2971215073,4807526976,7778742049,12586269025,20365011074,32951280099,53316291173,86267571272,139583862445,225851433717,365435296162,591286729879,956722026041,1548008755920,2504730781961,4052739537881,6557470319842,10610209857723,17167680177565,27777890035288,44945570212853,72723460248141,117669030460994,190392490709135,308061521170129,498454011879264,806515533049393,1304969544928657,2111485077978050,3416454622906707,5527939700884757,8944394323791464,14472334024676221,23416728348467685,37889062373143906,61305790721611591,99194853094755497,160500643816367088,259695496911122585,420196140727489673,679891637638612258,1100087778366101931,1779979416004714189,2880067194370816120,4660046610375530309,7540113804746346429,12200160415121876738,19740274219868223167,31940434634990099905,51680708854858323072,83621143489848422977,135301852344706746049,218922995834555169026,354224848179261915075,573147844013817084101]

Tiempo transcurrido: 0.00018s