Чи може хтось пояснити концепцію, що стоїть у пам'яті Хаскелл?

(зауважте, я ставлю питання тут, оскільки це стосується концептуальної механіки цього, а не проблеми кодування)

Я працював над невеликою програмою, яка використовувала послідовність цифр розрядів у своєму зрівнянні, але я помітила, що якщо я пережила певну кількість, вона стає болісно повільною, гуляючи трохи, натрапила на техніку в Haskell, відому як Memoization, вони показали, що код працює так:

-- 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)

Тож моє запитання до вас, хлопці, як, а точніше, чому це працює?

Це тому, що якимось чином вдається пройти більшу частину списку, перш ніж підрахунок обчислення? Але якщо haskell лінивий, насправді не існує жодного розрахунку, який потрібно наздогнати ... То як це працює?

Просто для пояснення механіки, яка стоїть за фактичним запам'ятовуванням,

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

створює перелік «громовідводів», неоцінених обчислень. Подумайте про такі, як незакриті подарунки, доки ми не торкнемось їх, вони не запустяться.

Тепер, коли ми оцінюємо грудку, ми ніколи не оцінюємо її знову. Це насправді єдина форма мутації в "звичайному" хескеллі.

Тож повертаючись до свого коду, у вас є список титків, і ви все ще робите цю рекурсію дерева, але ви повторно використовуєте список, і коли елемент у списку оцінюється, він ніколи не буде обчислений знову. Таким чином, ми уникаємо рекурсії дерева у функції наївних волокон.

Як дотично цікава примітка, це особливо швидко, коли обчислюється низка фібоначних номерів, оскільки цей список оцінюється лише один раз, що означає, що якщо обчислити memo_fib 10000двічі, другий час має бути миттєвим. Це тому, що Haskell оцінював аргументи лише один раз, і ви використовуєте часткове додаток замість лямбда.

TLDR: Зберігаючи обчислення в списку, кожен елемент списку оцінюється один раз, тому кожне число фібоначчиків обчислюється рівно один раз протягом усієї програми.

Візуалізація:

 [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]

Таким чином, ви можете бачити, як оцінювання THUNK_4відбувається набагато швидше, оскільки його суб-вирази вже оцінені.

Сенс запам'ятовування - ніколи не обчислювати одну і ту ж функцію двічі - це надзвичайно корисно для прискорення обчислень, які є чисто функціональними, тобто без побічних ефектів, оскільки для них процес може бути повністю автоматизований, не впливаючи на правильність. Це особливо необхідно для таких функцій fibo, які призводять до рекурсії дерева , тобто експоненціальних зусиль, коли реалізуються наївно. (Це одна з причин, чому цифри Фібоначчі насправді є дуже поганим прикладом для навчання рекурсії - майже всі демо-реалізації, які ви знайдете в підручниках чи книгах, непридатні для великих вхідних значень.)

Якщо ви простежите потік виконання, ви побачите, що у другому випадку значення for fib xзавжди буде доступним при fib x+1виконанні, а система виконання зможе просто прочитати його з пам'яті, а не через інший рекурсивний виклик, тоді як Перше рішення намагається обчислити велике рішення до появи результатів для менших значень. Це в кінцевому підсумку тому, що ітератор [0..n]оцінюється зліва направо і, отже, почнеться з того часу 0, тоді як рекурсія в першому прикладі починається з nі лише потім запитує про n-1. Це те, що призводить до багатьох, багато непотрібних повторюваних викликів функцій.