Bagaimana mengelabui heuristik "coba beberapa kasus uji": Algoritma yang tampak benar, tetapi sebenarnya salah

Untuk mencoba menguji apakah suatu algoritma untuk beberapa masalah sudah benar, titik awal yang biasa adalah mencoba menjalankan algoritme dengan tangan pada sejumlah kasus uji sederhana - cobalah beberapa contoh contoh masalah, termasuk beberapa "kasus sudut" sederhana. ". Ini adalah heuristik yang hebat: ini adalah cara yang bagus untuk dengan cepat menyingkirkan banyak upaya yang salah pada suatu algoritma, dan untuk mendapatkan pemahaman tentang mengapa algoritma tidak bekerja.

Namun, ketika mempelajari algoritma, beberapa siswa tergoda untuk berhenti di situ: jika algoritme mereka bekerja dengan benar pada beberapa contoh, termasuk semua kotak sudut yang dapat mereka coba pikirkan, maka mereka menyimpulkan bahwa algoritme itu harus benar. Selalu ada siswa yang bertanya: "Mengapa saya perlu membuktikan algoritme saya dengan benar, jika saya bisa mencobanya pada beberapa kasus uji?"

Jadi, bagaimana Anda menipu heuristik "coba beberapa kasus uji"? Saya mencari beberapa contoh bagus untuk menunjukkan bahwa heuristik ini tidak cukup. Dengan kata lain, saya mencari satu atau lebih contoh dari suatu algoritma yang secara dangkal tampak seperti itu mungkin benar, dan yang menghasilkan jawaban yang tepat pada semua input kecil yang mungkin muncul dengan siapa pun, tetapi di mana algoritma tersebut sebenarnya tidak bekerja Mungkin algoritma hanya bekerja dengan benar pada semua input kecil dan hanya gagal untuk input besar, atau hanya gagal untuk input dengan pola yang tidak biasa.

Secara khusus, saya mencari:

1. Algoritma. Cacat harus berada pada level algoritmik. Saya tidak mencari bug implementasi. (Misalnya, minimal, contohnya harus agnostik bahasa, dan kelemahannya harus lebih terkait dengan masalah algoritme daripada masalah rekayasa perangkat lunak atau implementasi.)

2. Algoritma yang mungkin masuk akal bagi seseorang. Pseudocode harus terlihat setidaknya masuk akal benar (misalnya, kode yang dikaburkan atau jelas meragukan bukan contoh yang baik). Poin bonus jika ini adalah algoritma yang benar-benar dibuat oleh beberapa siswa ketika mencoba menyelesaikan pekerjaan rumah atau masalah ujian.

3. Algoritma yang akan melewati strategi uji manual yang masuk akal dengan probabilitas tinggi. Seseorang yang mencoba beberapa kasus uji kecil dengan tangan seharusnya tidak mungkin menemukan kekurangannya. Misalnya, "mensimulasikan QuickCheck dengan tangan pada selusin kasus uji kecil" seharusnya tidak akan mengungkapkan bahwa algoritma tersebut salah.

4. Lebih disukai, algoritma deterministik. Saya telah melihat banyak siswa berpikir bahwa "coba beberapa kasus uji dengan tangan" adalah cara yang masuk akal untuk memeriksa apakah algoritma deterministik benar, tetapi saya menduga sebagian besar siswa tidak akan menganggap bahwa mencoba beberapa kasus uji adalah cara yang baik untuk memverifikasi probabilistik algoritma. Untuk algoritma probabilistik, seringkali tidak ada cara untuk mengetahui apakah ada output tertentu yang benar; dan Anda tidak dapat menggunakan cukup banyak contoh tangan untuk melakukan tes statistik apa pun yang berguna pada distribusi keluaran. Jadi, saya lebih suka fokus pada algoritma deterministik, karena mereka menjadi lebih bersih ke jantung kesalahpahaman siswa.

Saya ingin mengajarkan pentingnya membuktikan algoritme Anda dengan benar, dan saya berharap menggunakan beberapa contoh seperti ini untuk membantu memotivasi bukti kebenaran. Saya lebih suka contoh yang relatif sederhana dan dapat diakses oleh mahasiswa; contoh yang membutuhkan mesin berat atau satu ton latar belakang matematika / algoritme kurang berguna. Juga, saya tidak ingin algoritma yang "tidak alami"; Meskipun mungkin mudah untuk membuat beberapa algoritma buatan aneh untuk mengelabui heuristik, jika terlihat sangat tidak alami atau memiliki backdoor yang jelas dibangun hanya untuk menipu heuristik ini, mungkin tidak akan meyakinkan siswa. Adakah contoh yang bagus?

Kesalahan umum yang saya pikir adalah menggunakan algoritma serakah, yang tidak selalu merupakan pendekatan yang benar, tetapi mungkin berhasil di sebagian besar kasus uji.

Contoh: Denominasi koin, dan angka n , ungkapkan n sebagai jumlah d i : s dengan koin sesedikit mungkin.$d_1,\dots,d_k$$n$$n$$d_i$

Pendekatan naif adalah dengan menggunakan koin terbesar yang mungkin pertama, dan dengan rakus menghasilkan jumlah tersebut.

Sebagai contoh, koin dengan nilai , 5 dan 1 akan memberikan jawaban yang benar dengan serakah untuk semua angka antara 1 dan 14 kecuali untuk angka 10 = 6 + 1 + 1 + 1 + 1 + 1 + 1 = 5 + 5 .$6$$5$$1$$1$$14$$10 = 6+1+1+1+1 = 5+5$

Saya langsung ingat contoh dari R. Backhouse (ini mungkin ada di salah satu bukunya). Rupanya, ia telah menugaskan tugas pemrograman di mana siswa harus menulis program Pascal untuk menguji kesetaraan dua string. Salah satu program yang dibuat oleh seorang siswa adalah sebagai berikut:

issame := (string1.length = string2.length);

if issame then
  for i := 1 to string1.length do
    issame := string1.char[i] = string2.char[i];

write(issame);

Kami sekarang dapat menguji program dengan input berikut:

"universitas" "universitas" Benar; baik$\Rightarrow$

"course" "course" Benar; baik$\Rightarrow$

"" "" Benar; baik$\Rightarrow$

"universitas" "mata kuliah" Salah; baik$\Rightarrow$

"kuliah" "tentu saja" Salah; baik$\Rightarrow$

"presisi" "ketepatan" Salah, oke$\Rightarrow$

Semua ini tampaknya sangat menjanjikan: mungkin programnya memang bekerja. Tetapi pengujian yang lebih hati-hati dengan mengatakan "murni" dan "benar" mengungkapkan output yang salah. Bahkan, program mengatakan "Benar" jika string memiliki panjang yang sama dan karakter terakhir yang sama!

Namun, pengujian sudah cukup menyeluruh: kami memiliki string dengan panjang berbeda, string dengan panjang sama tetapi konten berbeda, dan bahkan string sama. Selanjutnya, siswa bahkan telah menguji dan mengeksekusi setiap cabang. Anda tidak dapat benar-benar berpendapat bahwa pengujian ceroboh di sini - mengingat program ini memang sangat sederhana, mungkin sulit untuk menemukan motivasi dan energi untuk mengujinya dengan cukup teliti.

Contoh lucu lainnya adalah pencarian biner. Dalam TAOCP, Knuth mengatakan bahwa "meskipun ide dasar pencarian biner relatif mudah, detailnya bisa sangat rumit". Rupanya, bug dalam implementasi pencarian biner Java tidak diketahui selama satu dekade. Itu adalah bug integer overflow, dan hanya dimanifestasikan dengan input yang cukup besar. Rincian rumit dari implementasi pencarian biner juga dibahas oleh Bentley dalam buku Programming Pearls .

Intinya: bisa sangat sulit untuk memastikan algoritma pencarian biner benar dengan hanya mengujinya.

Contoh terbaik yang pernah saya temui adalah pengujian primality:

input: bilangan asli p, p! = 2
output: apakah perdana atau tidak?
algoritma: menghitung 2 ** (p-1) mod p. Jika hasil = 1 maka p adalah prima lain p tidak.

Ini berfungsi untuk (hampir) setiap angka, kecuali untuk beberapa contoh pencacah, dan seseorang benar-benar membutuhkan mesin untuk menemukan contoh tandingan dalam periode waktu yang realistis. Contoh tandingan pertama adalah 341, dan densitas sampel tandingan sebenarnya berkurang dengan meningkatnya p, meskipun hampir secara logaritma.

Alih-alih hanya menggunakan 2 sebagai dasar kekuatan, seseorang dapat meningkatkan algoritma dengan juga menggunakan tambahan, meningkatkan bilangan prima kecil sebagai dasar jika prime sebelumnya kembali 1. Dan masih, ada tandingan sampel untuk skema ini, yaitu nomor Carmichael, cukup langka

Inilah salah satu yang dilemparkan kepada saya oleh perwakilan Google di sebuah konvensi yang saya kunjungi. Itu dikodekan dalam C, tetapi bekerja dalam bahasa lain yang menggunakan referensi. Maaf karena harus kode pada [cs.se], tapi itu satu-satunya untuk menggambarkannya.

swap(int& X, int& Y){
    X := X ^ Y
    Y := X ^ Y
    X := X ^ Y
}

Algoritma ini akan bekerja untuk semua nilai yang diberikan kepada x dan y, bahkan jika nilainya sama. Namun itu tidak akan berfungsi jika itu disebut sebagai swap (x, x). Dalam situasi itu, x berakhir sebagai 0. Sekarang, ini mungkin tidak memuaskan Anda, karena Anda entah bagaimana dapat membuktikan operasi ini benar secara matematis, tetapi masih melupakan kasus tepi ini.

Ada seluruh kelas algoritma yang secara inheren sulit untuk diuji: generator angka pseudo-acak . Anda tidak dapat menguji satu output tetapi harus menyelidiki (banyak) seri output dengan alat statistik. Bergantung pada apa dan bagaimana Anda menguji Anda mungkin akan kehilangan karakteristik non-acak.

Salah satu kasus terkenal di mana segalanya berjalan salah adalah RANDU . Itu melewati pengawasan yang tersedia pada saat itu - yang gagal untuk mempertimbangkan perilaku tuple dari output berikutnya. Sudah tiga kali lipat menunjukkan banyak struktur:

Pada dasarnya, tes tidak mencakup semua kasus penggunaan: sementara penggunaan satu dimensi RANDU (mungkin sebagian besar) baik-baik saja, itu tidak mendukung menggunakannya untuk sampel titik tiga dimensi (dengan cara ini).

Sampling pseudo-acak yang tepat adalah bisnis yang rumit. Untungnya, ada ruang uji yang kuat di sana beberapa hari ini, misalnya dieharder yang berspesialisasi dalam membuang semua statistik yang kita ketahui pada generator yang diusulkan. Cukup?

^{Agar adil, saya tidak tahu apa yang layak Anda buktikan untuk PRNG.}

Maksimum lokal 2D

$n \times n$$A$

$(i,j)$$A[i,j]$

$A[i, j+1], A[i, j-1], A[i-1, j], A[i+1, j]$$A$

maka setiap sel yang dicetak tebal adalah maksimum lokal. Setiap array yang tidak kosong memiliki setidaknya satu maksimum lokal.

$O(n^2)$

$A$$X$$X$$A$$(i, j)$$X$$(i, j)$$(i', j')$

$A \setminus X$$A$$X$$(i', j')$$A'$

$A'$$A$

$(i', j')$$A'$$A'$$(i', j')$$\diamond$

$\frac{n}{2}\times\frac{n}{2}$$A'$$(i, j)$

$T(n)$$n\times n$$T(n) = T(n/2) + O(n)$$T(n) = O(n)$

Dengan demikian, kami telah membuktikan teorema berikut:

$O(n)$$n\times n$

Atau sudahkah kita?

Ini adalah contoh-contoh primitif, karena mereka biasa.

(1) Primality in SymPy. Edisi 1789 . Ada pengujian yang salah pada situs web terkenal yang tidak gagal sampai setelah 10 ^ 14. Sementara perbaikannya benar, itu hanya menambal lubang daripada memikirkan kembali masalah.

(2) Primality di Perl 6. Perl6 telah menambahkan is-prime yang menggunakan sejumlah tes MR dengan basis tetap. Ada contoh tandingan yang diketahui, tetapi mereka cukup besar karena jumlah tes standar sangat besar (pada dasarnya menyembunyikan masalah sebenarnya dengan menurunkan kinerja). Ini akan segera diatasi.

(3) Prioritas dalam FLINT. n_isprime () mengembalikan true untuk komposit , sejak diperbaiki. Pada dasarnya masalah yang sama dengan SymPy. Menggunakan database Feitsma / Galway dari pseudoprimes SPRP-2 ke 2 ^ 64 sekarang kita dapat menguji ini.

(4) Matematika Perl :: Primality. is_aks_prime rusak . Urutan ini tampaknya mirip dengan banyak implementasi AKS - banyak kode yang bekerja secara tidak sengaja (mis. Hilang pada langkah 1 dan akhirnya melakukan semuanya dengan pembagian percobaan) atau tidak bekerja untuk contoh yang lebih besar. Sayangnya AKS sangat lambat sehingga sulit untuk diuji.

(5) Pra-2.2 is_prime Pari. Matematika :: tiket Pari . Ini menggunakan 10 pangkalan acak untuk tes MR (dengan seed tetap pada startup, bukan seed tetap GMP setiap panggilan). Ini akan memberi tahu Anda 9 prima sekitar 1 dari setiap panggilan 1M. Jika Anda memilih nomor yang tepat, Anda dapat membuatnya gagal relatif sering, tetapi jumlahnya menjadi lebih jarang, sehingga tidak banyak muncul dalam praktik. Mereka telah mengubah algoritma dan API.

Ini tidak salah, tetapi ini adalah tes probabilistik klasik: Berapa putaran yang Anda berikan, katakanlah, mpz_probab_prime_p? Jika kita berikan 5 putaran, itu pasti terlihat berfungsi dengan baik - angka harus lulus tes Fermat base-210 dan kemudian 5 tes Miller-Rabin yang dipilih sebelumnya. Anda tidak akan menemukan contoh tandingan hingga 3892757297131 (dengan GMP 5.0.1 atau 6.0.0a), jadi Anda harus melakukan banyak pengujian untuk menemukannya. Tetapi ada ribuan contoh tandingan di bawah 2 ^ 64. Jadi, Anda terus meningkatkan jumlahnya. Berapa jauh? Apakah ada musuh? Seberapa penting jawaban yang benar? Apakah Anda membingungkan basis acak dengan basis tetap? Apakah Anda tahu ukuran input apa yang akan Anda berikan?

$10^{16}$

Ini cukup sulit untuk diuji dengan benar. Strategi saya termasuk unit test yang jelas, ditambah kasus tepi, ditambah contoh kegagalan yang terlihat sebelum atau dalam paket lain, tes vs database yang diketahui jika memungkinkan (misalnya jika Anda melakukan tes MR basis-2 tunggal, maka Anda telah mengurangi kemungkinan yang tidak dapat dihitung secara komputasional tugas pengujian 2 ^ 64 angka untuk menguji sekitar 32 juta angka), dan akhirnya, banyak tes acak menggunakan paket lain sebagai standar. Poin terakhir berfungsi untuk fungsi-fungsi seperti primality di mana ada input yang cukup sederhana dan output yang diketahui, tetapi beberapa tugas seperti ini. Saya telah menggunakan ini untuk menemukan cacat pada kode pengembangan saya sendiri serta masalah sesekali dalam paket perbandingan. Tetapi mengingat ruang input yang tidak terbatas, kami tidak dapat menguji semuanya.

Adapun pembuktian kebenaran, berikut adalah contoh primality lainnya. Metode BLS75 dan ECPP memiliki konsep sertifikat keutamaan. Pada dasarnya setelah mereka melakukan pencarian untuk menemukan nilai yang sesuai dengan bukti mereka, mereka dapat menampilkannya dalam format yang dikenal. Seseorang kemudian dapat menulis verifikasi atau meminta orang lain untuk menulisnya. Ini berjalan sangat cepat dibandingkan dengan pembuatan, dan sekarang salah satu (1) kedua kode tidak benar (maka dari itu mengapa Anda lebih suka programmer lain untuk verifier), atau (2) matematika di balik ide bukti salah. # 2 selalu mungkin, tetapi ini biasanya telah diterbitkan dan ditinjau oleh banyak orang (dan dalam beberapa kasus cukup mudah bagi Anda untuk berjalan sendiri).

Sebagai perbandingan, metode seperti AKS, APR-CL, divisi percobaan, atau tes Rabin deterministik, semua tidak menghasilkan output selain "prima" atau "komposit." Dalam kasus terakhir kita mungkin memiliki faktor yang dapat memverifikasi, tetapi dalam kasus sebelumnya kita tidak memiliki apa pun selain sedikit output ini. Apakah program bekerja dengan benar? Tidak tahu

Penting untuk menguji perangkat lunak pada lebih dari hanya beberapa contoh mainan, dan juga melalui beberapa contoh pada setiap langkah algoritma dan mengatakan "diberi input ini, apakah masuk akal bahwa saya di sini dengan keadaan ini?"

Algoritma Fisher-Yates-Knuth shuffling adalah contoh (praktis) dan salah satu yang dikomentari oleh salah satu penulis situs ini .

Algoritma ini menghasilkan permutasi acak dari array yang diberikan sebagai:

 // To shuffle an array a of n elements (indices 0..n-1):
  for i from n − 1 downto 1 do
       j ← random integer with 0 ≤ j ≤ i
       exchange a[j] and a[i]

$i$$j$$0 \le j \le i$

Algoritma "naif" dapat berupa:

 // To shuffle an array a of n elements (indices 0..n-1):
  for i from n − 1 downto 1 do
       j ← random integer with 0 ≤ j ≤ n-1
       exchange a[j] and a[i]

Di mana dalam loop elemen yang akan ditukar dipilih dari semua elemen yang tersedia. Namun ini menghasilkan pengambilan sampel yang bias dari permutasi (ada yang terlalu banyak terwakili dll.)

Sebenarnya seseorang dapat membuat shuffling fisher-yates-knuth menggunakan analisis penghitungan sederhana (atau naif) .

$n$$n! = n \times n-1 \times n-2 ..$$n$$n-1$

Masalah utama dengan memverifikasi apakah algoritma pengocokan benar atau tidak ( bias atau tidak ) adalah bahwa karena statistik, sejumlah besar sampel diperlukan. The Artikel codinghorror saya link di atas menjelaskan hal itu (dan dengan tes yang sebenarnya).

Contoh terbaik (baca: hal yang paling membuat saya sakit hati) yang pernah saya lihat berkaitan dengan dugaan collatz. Saya berada dalam kompetisi pemrograman (dengan hadiah 500 dolar di baris pertama) di mana salah satu masalahnya adalah menemukan jumlah langkah minimum yang diperlukan untuk dua angka untuk mencapai nomor yang sama. Solusinya tentu saja adalah secara bergantian langkah masing-masing sampai mereka berdua mencapai sesuatu yang telah terlihat sebelumnya. Kami diberi kisaran angka (saya pikir itu antara 1 dan 1000000) dan diberi tahu bahwa dugaan collatz telah diverifikasi hingga 2 ^ 64 sehingga semua angka yang kami berikan pada akhirnya akan konvergen pada 1. Saya menggunakan 32-bit bilangan bulat untuk melakukan langkah-langkah dengan Namun. Ternyata ada satu angka yang tidak jelas antara 1 dan 1000000 (170 ribu sesuatu) yang akan menyebabkan bilangan bulat 32-bit meluap pada waktunya. Sebenarnya angka-angka ini sangat langka di bawah 2 ^ 31. Kami menguji sistem kami untuk nomor HUGE yang jauh lebih besar dari 1000000 untuk "memastikan" bahwa tidak terjadi overflow. Ternyata jumlah yang jauh lebih kecil yang baru saja kami uji tidak menyebabkan luapan. Karena saya menggunakan "int" bukannya "long", saya hanya mendapat hadiah 300 dolar daripada hadiah $ 500.

Masalah Knapsack 0/1 adalah masalah yang hampir semua siswa pikir dapat dipecahkan oleh algoritma serakah. Itu terjadi lebih sering jika Anda sebelumnya menunjukkan beberapa solusi serakah sebagai versi masalah Knapsack di mana algoritma serakah bekerja .

Untuk masalah-masalah tersebut, di kelas , saya harus menunjukkan bukti untuk Knapsack 0/1 ( pemrograman dinamis ) untuk menghilangkan keraguan dan untuk versi masalah serakah juga. Sebenarnya, kedua bukti itu tidak sepele dan para siswa mungkin menganggapnya sangat membantu. Selain itu, ada komentar tentang ini di CLRS 3ed , Bab 16, Halaman 425-427 .

Masalah: pencuri merampok toko dan dapat membawa berat maksimal W ke ranselnya. Ada n item dan item ih berat wi dan bernilai vi dolar. Barang apa yang harus diambil pencuri? untuk memaksimalkan keuntungannya ?

Masalah Knapsack 0/1 : Penyetelannya sama, tetapi barangnya mungkin tidak dapat dipecah menjadi potongan-potongan yang lebih kecil , sehingga pencuri dapat memutuskan untuk mengambil item atau meninggalkannya (pilihan biner), tetapi mungkin tidak mengambil sebagian kecil dari suatu item .

Dan Anda dapat memperoleh dari siswa beberapa gagasan atau algoritme yang mengikuti gagasan yang sama dengan masalah versi serakah, yaitu:

• Ambil kapasitas total tas, dan letakkan sebanyak mungkin objek bernilai paling tinggi, dan ulangi metode ini hingga Anda tidak dapat memasukkan lebih banyak objek karena tas penuh atau tidak ada objek dengan berat kurang sama untuk diletakkan di dalam tas.
• Cara salah lainnya adalah berpikir: letakkan barang yang lebih ringan dan letakkan yang berikut ini dengan harga terendah.
• ...

Apakah ini membantu Anda? sebenarnya, kita tahu masalah koin adalah versi masalah ransel. Tapi, ada lebih banyak contoh di hutan masalah ransel, dengan contoh, bagaimana dengan Knapsack 2D (itu sangat membantu ketika Anda ingin memotong kayu untuk membuat furnitur , saya melihat di lokal dari kota saya), itu sangat umum berpikir bahwa serakah juga bekerja di sini, tetapi tidak.

Kesalahan umum adalah menerapkan algoritma pengocokan yang salah. Lihat diskusi di wikipedia .

$n!$$n^n$$(n-1)^n$

Ular PEP450 yang memperkenalkan fungsi statistik ke dalam perpustakaan standar mungkin menarik. Sebagai bagian dari pembenaran untuk memiliki fungsi yang menghitung varians dalam pustaka standar python, penulis Steven D'Aprano menulis:

def variance(data):
        # Use the Computational Formula for Variance.
        n = len(data)
        ss = sum(x**2 for x in data) - (sum(data)**2)/n
        return ss/(n-1)

Di atas tampaknya benar dengan tes kasual:

>>> data = [1, 2, 4, 5, 8]
>>> variance(data)
  7.5

Tetapi menambahkan konstanta ke setiap titik data tidak boleh mengubah varians:

>>> data = [x+1e12 for x in data]
>>> variance(data)
  0.0

Dan varians tidak boleh negatif:

>>> variance(data*100)
  -1239429440.1282566

Masalahnya adalah tentang angka dan bagaimana presisi hilang. Jika Anda ingin presisi maksimum maka Anda harus memesan operasi Anda dengan cara tertentu. Implementasi yang naif mengarah ke hasil yang salah karena ketidaktepatan terlalu besar. Itulah salah satu masalah kursus numerik saya di universitas.

Meskipun hal ini kemungkinan tidak sesuai dengan yang Anda cari, tentu mudah untuk memahami dan menguji beberapa kasus kecil tanpa pemikiran lain akan mengarah pada algoritma yang salah.

$n$$n^2+n+41$$0<d$$d\text{ divides } n^2+n+41$$d < n^2+n+41$

Solusi yang diusulkan :

int f(int n) {
   return 1;
}

$n= 0, 1, 2, \dotsc, 39$$n=40$

Ini "mencoba beberapa kasus kecil dan menyimpulkan suatu algoritma dari hasilnya" pendekatan muncul sering (meskipun tidak sehebat ini di sini) dalam kompetisi pemrograman di mana tekanan adalah untuk datang dengan algoritma yang (a) cepat untuk diimplementasikan dan (b) ) memiliki waktu lari cepat.