Có phải vài trăm bước giảm quá nhiều để có được dạng Y bình thường ⌜3⌝ không?

Khi tôi đang giảng dạy cơ sở của λ-tính toán gần đây, tôi đã thực hiện một trình đánh giá calcul-tính toán đơn giản trong Common Lisp. Khi tôi hỏi hình thức bình thường Y fac 3trong việc giảm thứ tự thông thường, phải mất 619 bước, có vẻ hơi nhiều.

Tất nhiên, mỗi lần tôi thực hiện các phép giảm tương tự trên giấy, tôi không bao giờ sử dụng phép tính λ được tính toán mà chỉ thêm các số và hàm hoạt động trên chúng. Trong trường hợp này, fac được định nghĩa như sau:

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

Trong trường hợp này, xem xét =, *và -như tách lạng bộ chức năng, nó chỉ mất khoảng 50 bước để có được Y fac 3mẫu bình thường của nó 6.

Nhưng trong đánh giá của tôi, tôi đã sử dụng như sau:

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)

Trong 619 bước, tôi chuyển từ Y fac ⌜3⌝dạng bình thường thành ⌜6⌝, cụ thể là λf.λx.f (f (f (f (f (f x))))).

Từ việc lướt nhanh qua nhiều bước, tôi đoán đó là định nghĩa về predviệc đảm bảo giảm thời gian dài như vậy, nhưng tôi vẫn tự hỏi liệu nó có thể là một lỗi khó chịu lớn trong quá trình thực hiện của tôi không ...

EDIT: Ban đầu tôi đã hỏi về một nghìn bước, một số bước thực sự gây ra việc thực hiện không đúng thứ tự thông thường, vì vậy tôi đã giảm xuống còn 2/3 số bước ban đầu. Như đã nhận xét bên dưới, với cách triển khai hiện tại của tôi, việc chuyển từ số học Church sang số học Peano thực sự làm tăng số bước

Mã hóa nhà thờ là thực sự xấu nếu bạn muốn sử dụng pred. Tôi sẽ khuyên bạn nên sử dụng một số mã hóa hiệu quả hơn theo kiểu Peano:

// mỹ phẩm

: 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 (.pp.p) p_zero
: p_plus = μ! f.λn.λm.n (λp. p_succ (! fpm)) m
: p_sub = μ! 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_bao = μ! f.λm.λn. m (λp. p_mult n (! fpn)) p_one
: p_even = μ! f.λm. m (λp. không (! fp)) tt

// số

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

Đây là một số mã được lấy từ một trong những thư viện cũ của tôi và μ!f. …chỉ là một cấu trúc được tối ưu hóa cho Y (λf. …). (Và tt, ff, notlà các phép toán luận.)

Tôi không thực sự chắc chắn rằng bạn sẽ có được kết quả tốt hơn facmặc dù.

Nếu tôi nghĩ về việc CPU có bao nhiêu thứ để tính giai thừa của 3, hãy nói bằng Python, thì việc giảm vài trăm không phải là vấn đề lớn.