Tulis program sesingkat mungkin (panjang diukur dalam bytes) memenuhi persyaratan berikut:
- tidak ada input
- output ke stdout
- eksekusi akhirnya berakhir
- jumlah total byte keluaran melebihi jumlah Graham
Asumsikan bahwa program berjalan sampai penghentian "normal" pada komputer ideal 1 dapat mengakses sumber daya tak terbatas, dan bahwa bahasa pemrograman umum dimodifikasi jika perlu (tanpa mengubah sintaks) untuk memungkinkan ini. Karena asumsi-asumsi ini, kita dapat menyebutnya semacam eksperimen Gedanken.
Untuk memulai, berikut adalah program Ruby 73-byte yang menghitung f ω + 1 (99) dalam hierarki yang berkembang cepat :
f=proc{|k,n|k>0?n.times{n=f[k-1,n]}:n+=1;n};n=99;n.times{n=f[n,n]};puts n
1 EDIT: Lebih tepatnya, misalkan kita mengambil sistem yang ada dan memodifikasinya hanya untuk tidak memiliki batas atas pada ukuran penyimpanan (tetapi selalu terbatas). Waktu pelaksanaan instruksi tidak seharusnya dimodifikasi, tetapi mesin dianggap ideal karena tidak akan memiliki batas atas pada masa operasinya.
Jawaban:
GolfScript (
4947 karakter)Lihat Lifetime of a worm untuk banyak penjelasan. Singkatnya, ini mencetak angka yang lebih besar dari f ω ω (2).
sumber
Haskell,
59575563Cara kerjanya:
%
cukup ambil fungsi dan buatn-1
waktu di atass
; yaitu%3
mengambil fungsif
dan mengembalikan fungsin
yang sama dengan menerapkannyaf
ke 3,n-1
kali berturut-turut. Jika kita mengulangi penerapan fungsi tingkat tinggi ini, kita mendapatkan urutan fungsi yang tumbuh cepat - dimulai dengan eksponensial, itu persis urutan ukuran hutan panah Knuth:((%3)%(3^))1 n = (3^)n = 3ⁿ = 3↑n
((%3)%(3^))2 n = ((3^)%3)n = (3↑)ⁿ⁻¹ $ 3 = 3↑↑n
((%3)%(3^))3 n = (((3^)%3)%3)n = (3↑↑)ⁿ⁻¹ $ 3 = 3↑↑↑n
dan seterusnya.
((%3)%(3^))n 3
adalah3 ↑ⁿ 3
, yang adalah apa yang muncul dalam perhitungan ke nomor Graham. Yang tersisa untuk dilakukan adalah menyusun fungsi(\n -> 3 ↑ⁿ 3) ≡ flip((%3)%(3^))3
lebih dari 64 kali, di atas 4 (jumlah panah yang dimulai dengan perhitungan), untuk mendapatkan angka yang lebih besar dari angka Graham. Jelas bahwa logaritma (fungsi yang sangat lambat!)g₆₅
Masih lebih besar daripadag₆₄=G
, jadi jika kita mencetak angka itu, panjang outputnya melebihiG
.⬛
sumber
print$((flip((%3)%(3*))3)%2)1
, ada kesalahan run-time - dapatkah Anda mengatakan mengapa? Ini berhasil ketika2
diubah ke1
(output adalah 81).Int
dengan cepat. Pada sistem 64-bit, yang menghabiskan terlalu banyak memori untuk direproduksi, tetapi tentu saja masih tidak memungkinkan untuk dijangkauG
. Saya membutuhkan tipe (big-int)Integer
, jadi saya tidak bisa menggunakan!!
; tunggu ...%
.((%3)%(3*))2 n
sebenarnya tumbuh lebih cepat dari yang Anda katakan ( hal yang baik ), tetapi Haskell-fu saya tidak cukup untuk memahami mengapa. Karenan = 0, 1, 2, ...
, alih-alih memberi3, 3^3, 3^(3^3), ...
, ia memberi3, 3^(3+1), 3^((3^(3+1))+1), ...
.((%3)%(3*))n 3
adalah lebih besar daripada3 ↑ⁿ 3
". Atau maksud Anda sesuatu yang lain? Ngomong-ngomong, saya mengubah definisi sehingga semuanya setara (setidaknya saya kira begitu, untuk malas memeriksanya sekarang ...) daripada lebih besar. Dan jika Anda mengubah66
ke65
, itu benar-benar menghasilkanG
sendiri, bukankah itu bagus?Pyth ,
2928 byteMenentukan lambda untuk hiper-operasi dan menyebutnya secara berulang. Seperti definisi untuk nomor Graham, tetapi dengan nilai yang lebih besar.
Ini:
Mendefinisikan lambda, kira-kira sama dengan python
Ini memberikan fungsi hiper-operasi, g (G, H) = 3 ↑ G + 1 (H + 1).
Jadi, misalnya, g (1,2) = 3 ↑ 2 3 = 7.625.597.484.987, yang dapat Anda uji di sini .
V<x><y>
mulai loop yang mengeksekusi tubuhy
,,x
kali.=gZT
adalah badan loop di sini, yang setara denganZ=g(Z,10)
Kode:
Harus secara berulang memanggil hiperoperasi di atas 64 kali, memberikan Nomor Graham.
Namun, dalam jawaban saya, saya telah mengganti satu digit
T
, yang diinisialisasi ke 10, dan meningkatkan kedalaman rekursi menjadi 99. Menggunakan Notasi Graham Array , Nomor Graham adalah [3,3,4,64], dan nomor saya output program yang lebih besar [10,11,11,99]. Saya juga menghapus)
yang menutup loop untuk menyimpan satu byte, sehingga mencetak setiap nilai berturut-turut dalam 99 iterasi.sumber
Python (111 + n), n = panjang (x)
Meskipun yang ini tidak sesingkat program Ruby penjawab, saya tetap akan mempostingnya, untuk mengesampingkan kemungkinan ini.
Ini menggunakan fungsi Ackermann, dan memanggil fungsi Ackermann dengan m dan n menjadi nilai dari panggilan lain ke fungsi Ackermann, dan berulang 1000 kali.
Ini mungkin lebih besar dari jumlah Graham, tetapi saya tidak yakin, karena tidak ada yang tahu persis panjangnya. Ini dapat dengan mudah diperpanjang, jika tidak lebih besar.
sumber
return
pernyataan ataulambda
.exec'x=A(x,x);'*x;print x
, maka programnya ok dan outputnya kira-kira f_ (ω + 1) (x) (anggap kode fungsi Ackermann sudah benar), yang memiliki lebih dari G byte bahkan untuk x = 99, katakan . (Dalam program Ruby saya,f[m,n]
adalah versiA(m,n)
.)eval
sebagai gantiexec
, baris terakhir Anda bisa sajaf=lambda x:A(x,x);print eval('f('*x+'x'+')'*x)
. Selain itu, definisi A (m, n) Anda perlu dikoreksi per komentar stan.Ruby,
545250 byteRuby,
858176716864635957 byteHirarki yang tumbuh sangat cepat dengan f (a + 1)> f ω + 1 (a).
Ruby, 61 byte
Pada dasarnya fungsi Ackermann dengan twist.
Ruby,
6359 byteRuby lain,
7471 bytePada dasarnya Ackermann berfungsi untuk dirinya sendiri 99 kali.
sumber
Python: 85
Yang mungkin bisa dipersingkat menjadi 74 +
length(X)
:Di mana
X
angka besar yang sesuai sehingga hiperoperasi yang dihasilkan3, 3
lebih besar dari angka Grahams (jika angka ini kurang dari99999999999
beberapa byte disimpan).Catatan: Saya menganggap kode python dieksekusi pada interpreter interaktif sehingga hasilnya dicetak ke stdout, jika tidak tambahkan
9
byte ke setiap solusi untuk panggilan keprint
.sumber
Javascript, 83 byte
Solusi fungsi Ackermann lainnya.
sumber
JavaScript, 68 byte, namun tidak bersaing untuk menggunakan ES6
a
fungsinya mirip dengan notasi panah atas dengan basis 9.b
fungsi adalah: b (x) = b x (9).b(99)
adalah ~ f ω +1 (99), dibandingkan dengan nomor Graham <f ω + 1 (64).sumber