Apakah beberapa ratus langkah reduksi terlalu banyak untuk mendapatkan bentuk normal Y fac ⌜3⌝?

Karena saya telah mengajarkan dasar kalkulus λ belakangan ini, saya telah menerapkan evaluator kalkulus λ sederhana di Common Lisp. Ketika saya bertanya bentuk normal Y fac 3dalam reduksi urutan normal, dibutuhkan 619 langkah, yang sepertinya agak banyak.

Tentu saja, setiap kali saya melakukan pengurangan serupa di atas kertas, saya tidak pernah menggunakan λ-calculus yang tidak diketik, tetapi menambahkan angka dan fungsi yang beroperasi pada mereka. Dalam hal ini, fac didefinisikan sebagai:

fac = λfac.λn.if (= n 0) 1 (* n (fac (- n 1)))

Dalam hal ini, mempertimbangkan =, *dan -sebagai fungsi kari, hanya dibutuhkan sekitar 50 langkah untuk mencapai Y fac 3bentuk normalnya 6.

Tetapi di evaluator saya, saya menggunakan yang berikut:

true = λx.λy.x
false = λx.λy.y
⌜0⌝ = λf.λx.x
succ = λn.λf.λx.f n f x
⌜n+1⌝ = succ ⌜n⌝
zero? = λn.n (λx.false) true
mult = λm.λn.λf.m (n f)
pred = λn.λf.λx.n (λg.λh.h (g f)) (λu.x) (λu.u)
fac = λfac.λn.(zero? n) ⌜1⌝ (* n (fac (pred n)))
Y = λf.(λf.λx.f (x x)) f ((λf.λx.f (x x)) f)

Dalam 619 langkah, saya beralih dari Y fac ⌜3⌝bentuk normal ⌜6⌝, yaitu λf.λx.f (f (f (f (f (f x))))).

Dari sekilas cepat dari banyak langkah, saya kira itu definisi predyang menjamin pengurangan yang begitu lama, tapi saya masih bertanya-tanya apakah itu hanya bug besar yang jahat dalam implementasi saya ...

EDIT: Saya awalnya bertanya tentang seribu langkah, beberapa di antaranya memang menyebabkan penerapan urutan normal yang salah, jadi saya turun ke 2/3 dari jumlah langkah awal. Seperti yang dikomentari di bawah ini, dengan implementasi saya saat ini, beralih dari aritmatika Gereja ke Peano sebenarnya meningkatkan jumlah langkah ...

Pengodean gereja benar-benar buruk jika Anda ingin menggunakannya pred. Saya akan menyarankan Anda untuk menggunakan beberapa pengkodean yang lebih efisien dalam gaya Peano:

// aritmatika

: p_zero = λs.λz.z
: p_one = λs.λz.s p_zero
: p_succ = λn.λs.λz.sn
: p_null = λn.n (λx. ff) tt
: p_pred = λn.n (λp.p) p_zero
: p_plus = μ! f.λn.λm.n (λp. p_succ (! fpm)) m
: p_subs = μ! f.λn.λm.n (λp. p_pred (! fpm)) m
: p_eq = μ! f.λm.λn. m (λp. n (λq.! fpq) ff) (n (λx.ff) tt)
: p_mult = μ! f.λm.λn. m (λp. p_plus n (! fpn)) p_zero
: p_exp = μ! f.λm.λn. m (λp. p_mult n (! fpn)) p_one
: p_even = μ! f.λm. m (λp. not (! fp)) tt

// angka

: p_0 = λs.λz.z
: p_1 = λs.λz.s p_0
: p_2 = λs.λz.s p_1
: p_3 = λs.λz.s p_2
...

Ini adalah beberapa kode yang diambil dari salah satu perpustakaan lama saya, dan μ!f. …hanya merupakan konstruksi yang dioptimalkan untuk Y (λf. …). (Dan tt, ff, notadalah boolean.)

Saya tidak begitu yakin Anda akan mendapatkan hasil yang lebih baik untuk facsaat ini.

Jika saya berpikir tentang berapa banyak hal yang dilakukan CPU untuk menghitung faktorial 3, katakanlah dengan Python, maka beberapa ratus pengurangan bukanlah masalah besar sama sekali.