Bisakah satu mengotomatiskan analisis algoritmik?

Adakah yang berpikir tentang kemungkinan bahasa pemrograman, dan kompiler, sehingga kompiler dapat secara otomatis melakukan analisis asimptotik kasus terburuk? Kasus penggunaan yang ada dalam pikiran saya adalah bahasa pemrograman tempat saya menulis kode, dan kompilasi. Kompilator memberi tahu saya bahwa kode saya berjalan di O (n ^ 2) (misalnya). Ini melakukan ini dengan melakukan apa yang dilakukan oleh orang pintar yang melakukan analisis algoritmik, mungkin menghitung loop dan sebagainya.

Karena menghentikan masalah masalah, dan karena seseorang dapat memiliki program yang bekerja dengan cara menyambungkan, misalnya algoritma Levin untuk SAT yang berjalan dalam waktu polinomial iff P = NP, saya menduga bahwa seseorang mungkin harus merancang bahasa pemrograman agar cukup membatasi untuk memungkinkan sesuatu seperti ini. Apakah ada hasil negatif, yang mengesampingkan beberapa jenis bahasa pemrograman dari memiliki kompiler seperti itu.
Saya juga akan tertarik pada sistem yang tidak memberikan analisis asimptotik yang tepat, tetapi batas atas yang "menarik".
Saya secara khusus TIDAK tertarik pada kotak hitam dan metode statistik yang mengambil sampel dari input dengan panjang tertentu, dan mencari tahu berapa lama program ini berlangsung. Metode-metode ini sangat menarik, tetapi bukan itu yang saya cari. Saya tertarik pada metode yang tepat yang dapat memberikan perkiraan batas.

Saya akan sangat berterima kasih jika seseorang dapat mengarahkan saya ke beberapa referensi tentang pekerjaan ke arah ini.

— manoj
sumber

Ini adalah kemungkinan duplikat dari pertanyaan berikut: cstheory.stackexchange.com/questions/12585/…

— cody

bahasa yang jelas yang dapat dikesampingkan adalah Turing lengkap karena masalah penghentian yang tidak dapat diputuskan adalah dalam bahasa tersebut. maka ini mengarah pada pertanyaan, apa bahasa yang lebih terbatas daripada Turing lengkap yang ini mungkin? tapi bisa dibilang, bahasa bukan "bahasa pemrograman" kecuali itu Turing lengkap. oleh karena itu, kira-kira, tujuan semacam itu pada dasarnya tidak mungkin secara teoritis ... mungkin ada beberapa ide yang meringankan untuk bahasa dengan kompleksitas terbatas ...

— vzn

n^{2}

$n^2$

n^{3}

$n^3$

@ Kaveh Saya tidak setuju bahwa pertanyaan saya adalah duplikat "Apakah batas runtime dalam P dapat dipilih?". Saya sudah tahu bagaimana membuktikan itu tidak mungkin. Namun demikian, terima kasih telah membawa utas ini juga menjadi perhatian saya! Namun, mungkin saja pertanyaan saya adalah pertanyaan rangkap, seperti yang ditunjukkan oleh cody.

— manoj

Ketika saya masih muda dan naif saya mencoba menulis penganalisa kompleksitas menggunakan gcov . Ini memberi Anda beberapa kali setiap baris dieksekusi. :) Pertanyaan bagus!

— Pratik Deoghare

Jawaban:

Kompleksitas implisit telah mengajarkan kepada kita bahwa (beberapa) kelas kompleksitas dapat diklasifikasikan berdasarkan sistem tipe, dalam arti bahwa ada sistem tipe yang hanya menerima program polinomial, misalnya. Satu cabang yang lebih praktis dari penelitian ini adalah RAML (Resource Aware ML), bahasa pemrograman fungsional dengan sistem tipe yang akan memberi Anda informasi akurat tentang waktu pelaksanaan program-programnya. Itu lebih tepat, pada kenyataannya, daripada kompleksitas O-besar, adalah faktor-faktor konstan juga dimasukkan, ditentukan oleh model biaya untuk operasi dasar.

Anda mungkin berpikir ini curang: pasti beberapa algoritma memiliki kompleksitas yang sangat sulit untuk dihitung secara tepat, jadi bagaimana bahasa ini dapat dengan mudah menentukan kompleksitas programnya? Kuncinya adalah bahwa ada banyak cara untuk mengekspresikan algoritma yang diberikan, beberapa yang sistem-jenisnya akan tolak (ia menolak beberapa program bagus), dan beberapa, mungkin, yang diterimanya. Jadi pengguna tidak mendapatkan dunia secara gratis: ia tidak perlu menghitung estimasi biaya lagi, tetapi perlu memikirkan cara mengekspresikan kode dengan cara yang diterima oleh sistem.

(Itu selalu trik yang sama, seperti dengan bahasa pemrograman dengan hanya penghentian perhitungan, atau properti keamanan yang dapat dibuktikan, dll.)

— gasche
sumber

Terima kasih, ini jawaban yang sangat menarik. Saya akan melihat lebih dekat pada RAML.

— manoj

Alat COSTA yang dikembangkan oleh kelompok penelitian COSTA melakukan apa yang Anda inginkan. Diberikan program (dalam format bytecode Java), alat menghasilkan persamaan biaya berdasarkan model biaya yang disediakan oleh programmer. Model biaya dapat melibatkan entitas seperti runtime, penggunaan memori, atau peristiwa yang dapat ditagih (seperti mengirim pesan teks). Persamaan runtime kemudian dipecahkan menggunakan alat khusus untuk menghasilkan bentuk tertutup, batas atas terburuk dari model biaya.

Secara alami, alat tidak bekerja dalam semua kasus, baik dengan gagal menghasilkan persamaan runtime atau dengan gagal menemukan formulir tertutup. Ini tidak mengejutkan.

— Dave Clarke
sumber

Saya sebenarnya memikirkan pertanyaan yang sama beberapa waktu lalu. Inilah kereta pemikiran yang saya miliki:

Seperti yang Anda katakan masalah berhenti adalah masalah. Untuk menghindarinya kita perlu bahasa yang hanya memungkinkan program yang selalu berhenti. Di sisi lain bahasa kita perlu cukup ekspresif untuk menangani masalah yang paling umum (mis. Setidaknya harus menangkap semua kelas kompleksitas EXP).

Jadi, mari kita lihat program LOOP. Program LOOP selalu berhenti dan ekspresinya jauh melebihi EXP - untuk mendapatkan ide yang lebih baik: Anda dapat mensimulasikan TM mana pun yang fungsi runtime dapat dinyatakan sebagai program LOOP.

Sekarang, kita dapat melihat kedalaman bersarang dan besarnya jumlah pengulangan untuk setiap loop dari sudut pandang sintaksis dan kita memiliki titik awal (tidak tahu seberapa jauh ini membawa kita). Namun, pertimbangkan masalah berikut:

$f(n)$

$f(n) = y$ $y$ $n$ $y > n$

$p(n)$ $n$ $f(n)$

y := n + 1
while not prime(y) 
    y++
return y

Sekarang, bagaimana kita akan melakukan ini hanya dengan loop terikat? Masalahnya sekarang adalah memikirkan batas atas untuk rentang angka yang harus kita cari.

\forall prime p \exists prime p^{'} : p < p^{'} \leq p! + 1

$\forall \text{ prime } p \phantom{a} \exists \text{ prime } p' : p < p' \leq p! + 1$

Intuisi saya di sini adalah bahwa satu-satunya informasi yang dapat diberikan oleh kompiler adalah dengan menganalisis sintaksis yang pada akhirnya disediakan oleh programmer. Jadi, mengaktifkan kompiler untuk membuat pernyataan yang bermakna tentang kompleksitas waktu suatu program berarti memaksa programmer untuk memasukkan informasi ini ke dalam program.

Namun, paragraf terakhir adalah subyektif dan tentu saja mungkin ada pendekatan lain yang mungkin menghasilkan hasil yang menarik. Saya hanya ingin memberikan ide tentang apa yang tidak boleh diharapkan saat melewati jalan ini.

— John D.
sumber

Kedalaman loop yang bersarang adalah masalah utama di sini, dan kompleksitas berkisar pada fungsi rekursif primitif, lihat Kompleksitas program loop , Meyer & Ritchie, ACM '67 Conference, dx.doi.org/10.1145/800196.806014 .

— Sylvain

Terima kasih. Saya pikir Anda membuat poin yang baik di sini. Ada masalah jika saya akan menjalankan loop jenis sementara (predikat = benar) melakukan sesuatu karena saya harus berdebat tentang pertama kali predikat menjadi salah. Untuk mengulangi pertanyaan saya dalam konteks yang telah Anda tentukan, saya ingin tahu apakah seseorang dapat merancang sekelompok primitif, dengan waktu berjalan yang terdefinisi dengan baik, yang dapat disusun dengan cara sederhana untuk menulis program yang menarik, dan mendapatkan batasan waktu berjalan untuknya . Mungkin RAML sudah melakukan beberapa dari ini, seperti yang ditunjukkan oleh jawaban pertama.

— manoj

Untuk memberikan lebih banyak petunjuk semacam ini, Cobham's The intrinsik komputasional fungsi sering dikutip sebagai salah satu karya paling awal pada kompleksitas implisit: itu mencirikan FP melalui skema rekursi. Anda akan menemukan karya yang lebih baru di sepanjang baris ini oleh Bellatoni & Cook dalam Karakterisasi rekursi-teoretis baru fungsi poli-waktu , Kompleksitas Komputasi 1992. Lihat juga survei oleh Hofmann dalam SIGACT News 31 (1): 31--42, 2000: dx.doi.org/10.1145/346048.346051 .

— Sylvain

Terima kasih Sylvain, saya melihat survei! Saya telah menyadari bidang teori kompleksitas tersirat ini, tetapi tidak pernah benar-benar repot untuk mempelajarinya, karena kurangnya penghargaan terhadap apa pertanyaan dasar yang mereka coba jawab. Sekarang saya memiliki motivasi lebih untuk memahami ide-ide ini!

— manoj