Come ingannare l'euristica "provare alcuni casi di prova": algoritmi che sembrano corretti, ma in realtà non corretti

Per provare a verificare se un algoritmo per qualche problema è corretto, il solito punto di partenza è provare a eseguire l'algoritmo manualmente su una serie di semplici casi di test - provalo su alcuni casi esemplificativi, inclusi alcuni semplici "casi angolari" ". Questa è una grande euristica: è un ottimo modo per eliminare rapidamente molti tentativi errati di un algoritmo e per capire perché l'algoritmo non funziona.

Tuttavia, quando apprendono gli algoritmi, alcuni studenti sono tentati di fermarsi qui: se il loro algoritmo funziona correttamente su una manciata di esempi, compresi tutti i casi angolari che possono pensare di provare, allora concludono che l'algoritmo deve essere corretto. C'è sempre uno studente che chiede: "Perché devo dimostrare il mio algoritmo corretto, se posso provarlo solo su alcuni casi di test?"

Quindi, come si fa a ingannare l'euristica "provare un mucchio di casi di prova"? Sto cercando alcuni buoni esempi per dimostrare che questa euristica non è abbastanza. In altre parole, sto cercando uno o più esempi di un algoritmo che apparentemente superficialmente potrebbe essere corretto e che fornisca la risposta giusta su tutti i piccoli input che chiunque probabilmente troverà, ma in cui l'algoritmo effettivamente non funziona Forse l'algoritmo funziona correttamente su tutti i piccoli input e fallisce solo per input di grandi dimensioni o fallisce solo per input con un modello insolito.

In particolare, sto cercando:

1. Un algoritmo Il difetto deve essere a livello algoritmico. Non sto cercando bug di implementazione. (Ad esempio, come minimo, l'esempio dovrebbe essere indipendente dal linguaggio e il difetto dovrebbe riguardare problemi algoritmici piuttosto che problemi di ingegneria del software o di implementazione.)

2. Un algoritmo che qualcuno potrebbe plausibilmente inventare. Lo pseudocodice dovrebbe apparire almeno plausibilmente corretto (ad esempio, il codice che è offuscato o ovviamente dubbioso non è un buon esempio). Punti bonus se si tratta di un algoritmo che alcuni studenti hanno escogitato durante il tentativo di risolvere un problema di compiti a casa o di esame.

3. Un algoritmo che avrebbe superato una ragionevole strategia di test manuale con alta probabilità. Qualcuno che prova a mano alcuni piccoli casi di test dovrebbe essere improbabile che scopra il difetto. Ad esempio, "simulare QuickCheck a mano su una dozzina di piccoli casi di test" dovrebbe essere improbabile per rivelare che l'algoritmo non è corretto.

4. Preferibilmente, un algoritmo deterministico. Ho visto molti studenti pensare che "provare alcuni casi di test a mano" è un modo ragionevole per verificare se un algoritmo deterministico è corretto, ma sospetto che la maggior parte degli studenti non ritenga che provare alcuni casi di test sia un buon modo per verificare probabilistici algoritmi. Per gli algoritmi probabilistici, spesso non c'è modo di dire se un determinato output è corretto; e non è possibile manovrare a sufficienza esempi per eseguire test statistici utili sulla distribuzione dell'output. Quindi, preferirei concentrarmi sugli algoritmi deterministici, poiché arrivano più chiaramente al cuore delle idee sbagliate degli studenti.

Mi piacerebbe insegnare l'importanza di dimostrare il tuo algoritmo corretto e spero di usare alcuni esempi come questo per motivare le prove di correttezza. Preferirei esempi relativamente semplici e accessibili agli studenti; esempi che richiedono macchinari pesanti o tonnellate di background matematico / algoritmico sono meno utili. Inoltre, non voglio algoritmi "innaturali"; mentre potrebbe essere facile costruire uno strano algoritmo artificiale per ingannare l'euristico, se sembra altamente innaturale o ha un'ovvia backdoor costruita solo per ingannare questo euristico, probabilmente non sarà convincente per gli studenti. Qualche buon esempio?

Un errore comune penso sia l'uso di algoritmi avidi, che non è sempre l'approccio corretto, ma potrebbe funzionare nella maggior parte dei casi di test.

Esempio: denominazioni di monete, e un numero , esprimono come somma di : s con il minor numero di monete possibile. n n d $d_1,\dots,d_k$$n$$n$$d_i$

Un approccio ingenuo consiste nell'utilizzare prima la moneta più grande possibile e produrre avidamente una tale somma.

Ad esempio, le monete con valore , 5 e 1 daranno risposte corrette con avidità per tutti i numeri tra 1 e 14 tranne il numero 10 = 6 + 1 + 1 + 1 + 1 = 5 + 5 .$6$$5$$1$$1$$14$$10 = 6+1+1+1+1 = 5+5$

Ho immediatamente ricordato un esempio di R. Backhouse (questo potrebbe essere stato in uno dei suoi libri). Apparentemente, aveva assegnato un incarico di programmazione in cui gli studenti dovevano scrivere un programma Pascal per testare l'uguaglianza di due stringhe. Uno dei programmi offerti da uno studente era il seguente:

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

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

write(issame);

Ora possiamo testare il programma con i seguenti input:

"università" "università" Vero; ok$\Rightarrow$

"corso" "corso" Vero; ok$\Rightarrow$

"" "" Vero; ok$\Rightarrow$

"corso" "universitario" Falso; ok$\Rightarrow$

"lezione" "corso" Falso; ok$\Rightarrow$

"precisione" "esattezza" Falso, OK$\Rightarrow$

Tutto ciò sembra molto promettente: forse il programma funziona davvero. Ma un test più attento con dire "puro" e "vero" rivela un output difettoso. In effetti, il programma dice "True" se le stringhe hanno la stessa lunghezza e lo stesso ultimo carattere!

Tuttavia, i test sono stati abbastanza approfonditi: avevamo stringhe con lunghezza diversa, stringhe con lunghezza uguale ma contenuto diverso e persino stringhe uguali. Inoltre, lo studente aveva persino testato ed eseguito ogni ramo. Non si può davvero sostenere che i test siano stati trascurati qui - dato che il programma è davvero molto semplice, potrebbe essere difficile trovare la motivazione e l'energia per testarlo abbastanza a fondo.

Un altro esempio carino è la ricerca binaria. In TAOCP, Knuth afferma che "sebbene l'idea di base della ricerca binaria sia relativamente semplice, i dettagli possono essere sorprendentemente complicati". Apparentemente, un bug nell'implementazione della ricerca binaria di Java è passato inosservato per un decennio. Era un bug di overflow di numero intero e si manifestava solo con input abbastanza grande. I dettagli complicati delle implementazioni della ricerca binaria sono anche trattati da Bentley nel libro Programming Pearls .

In conclusione: può essere sorprendentemente difficile essere certi che un algoritmo di ricerca binaria sia corretto semplicemente testandolo.

Il miglior esempio che abbia mai incontrato è il test di primalità:

input: numero naturale p, p! = 2
output: è pa prime o no?
algoritmo: calcolare 2 ** (p-1) mod p. Se risultato = 1, allora p è primo, altrimenti p non lo è.

Questo funziona per (quasi) tutti i numeri, ad eccezione di pochissimi esempi di contatori, e uno ha effettivamente bisogno di una macchina per trovare un controesempio in un periodo di tempo realistico. Il primo controesempio è 341, e la densità dei controesempi diminuisce effettivamente all'aumentare di p, sebbene quasi logaritmicamente.

Invece di usare solo 2 come base del potere, si può migliorare l'algoritmo usando anche ulteriori primi crescenti come base nel caso in cui il primo precedente sia tornato 1. E tuttavia, ci sono controesempio a questo schema, vale a dire i numeri di Carmichael, piuttosto raro però

Eccone uno che mi è stato lanciato dai rappresentanti di Google a una convention a cui sono andato. È stato codificato in C, ma funziona in altre lingue che usano riferimenti. Ci scusiamo per aver dovuto scrivere il codice su [cs.se], ma è l'unico a illustrarlo.

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

Questo algoritmo funzionerà per qualsiasi valore dato a xey, anche se hanno lo stesso valore. Non funzionerà comunque se viene chiamato swap (x, x). In quella situazione, x finisce come 0. Ora, questo potrebbe non soddisfarti, dal momento che puoi in qualche modo dimostrare che questa operazione è corretta matematicamente, ma dimentica ancora questo caso limite.

Esiste un'intera classe di algoritmi che è intrinsecamente difficile da testare: generatori di numeri pseudo-casuali . Non è possibile testare un singolo output ma è necessario esaminare (molte) serie di output con mezzi statistici. A seconda di cosa e come testare, potreste perdere caratteristiche non casuali.

Un caso famoso in cui le cose sono andate terribilmente storto è RANDU . Ha superato il controllo disponibile al momento - che non è riuscito a considerare il comportamento delle tuple delle uscite successive. Le triple già mostrano molta struttura:

Fondamentalmente, i test non coprivano tutti i casi d'uso: mentre l'uso monodimensionale di RANDU andava (probabilmente per lo più) bene, non supportava il suo utilizzo per campionare punti tridimensionali (in questo modo).

Il campionamento pseudo-casuale corretto è un affare complicato. Fortunatamente, ci sono potenti test suite al giorno d'oggi, ad esempio dieharder specializzati nel lanciare tutte le statistiche che conosciamo in un generatore proposto. È abbastanza?

^{Ad essere sinceri, non ho idea di cosa si possa provare in modo fattibile per i PRNG.}

Massimo locale 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$

quindi ogni cella in grassetto è un massimo locale. Ogni array non vuoto ha almeno un massimo locale.

$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)$

Pertanto, abbiamo dimostrato il seguente teorema:

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

O abbiamo?

Questi sono esempi di primalità, perché sono comuni.

(1) Primalità in SymPy. Numero 1789 . È stato effettuato un test errato su un noto sito Web che non ha avuto esito negativo fino a dopo 10 ^ 14. Sebbene la correzione fosse corretta, si trattava solo di correggere i buchi anziché ripensare il problema.

(2) Primalità in Perl 6. Perl6 ha aggiunto is-prime che utilizza una serie di test MR con basi fisse. Esistono controesempi noti, ma sono piuttosto grandi poiché il numero predefinito di test è enorme (sostanzialmente nasconde il vero problema degradando le prestazioni). Questo sarà affrontato presto.

(3) Primalità in FLINT. n_isprime () restituisce true per i compositi , poiché risolto. Fondamentalmente lo stesso problema di SymPy. Usando il database Feitsma / Galway degli pseudoprimi SPRP-2 su 2 ^ 64 ora possiamo testarli.

(4) Perl's Math :: Primality. is_aks_prime rotto . Questa sequenza sembra simile a molte implementazioni di AKS - un sacco di codice che ha funzionato per caso (ad esempio, si è perso nel passaggio 1 e ha finito per fare tutto per divisione di prova) o non ha funzionato per esempi più grandi. Purtroppo AKS è così lento che è difficile testarlo.

(5) is_prime pre-2.2 di Pari. Matematica :: biglietto Pari . Ha usato 10 basi casuali per i test MR (con seed fisso all'avvio, piuttosto che seed fisso di GMP ogni chiamata). Ti dirà che 9 è primo circa 1 su ogni 1 milione di chiamate. Se scegli il numero giusto puoi farlo fallire relativamente spesso, ma i numeri diventano più scarsi, quindi in pratica non appare molto. Da allora hanno modificato l'algoritmo e l'API.

Questo non è sbagliato ma è un classico dei test probabilistici: quanti round dai, diciamo, mpz_probab_prime_p? Se gli diamo 5 round, sembra che funzioni bene: i numeri devono superare un test Fermat di base 210 e quindi 5 test Miller-Rabin di basi preselezionate. Non troverai un controesempio fino al 3892757297131 (con GMP 5.0.1 o 6.0.0a), quindi dovresti fare molti test per trovarlo. Ma ci sono migliaia di controesempi sotto 2 ^ 64. Quindi continui ad aumentare il numero. Quanto lontano? C'è un avversario? Quanto è importante una risposta corretta? Stai confondendo basi casuali con basi fisse? Sai quali dimensioni di input ti verranno fornite?

$10^{16}$

Questi sono abbastanza difficili da testare correttamente. La mia strategia include test unitari ovvi, oltre a casi limite, oltre ad esempi di guasti visti prima o in altri pacchetti, ove possibile test contro database noti (ad es. Se si esegue un singolo test MR di base-2, quindi è stato ridotto il calcolo non fattibile compito di testare 2 ^ 64 numeri per testare circa 32 milioni di numeri) e, infine, molti test randomizzati usando un altro pacchetto come standard. L'ultimo punto funziona per funzioni come la primalità in cui vi è un input abbastanza semplice e un output noto, ma alcune attività sono come questa. Ho usato questo per trovare difetti sia nel mio codice di sviluppo sia problemi occasionali nei pacchetti di confronto. Ma dato lo spazio di input infinito, non possiamo testare tutto.

Per quanto riguarda la dimostrazione della correttezza, ecco un altro esempio di primalità. I metodi BLS75 e ECPP hanno il concetto di un certificato di primalità. Fondamentalmente dopo che si allontanano facendo ricerche per trovare valori che funzionano per le loro prove, possono produrli in un formato noto. Si può quindi scrivere un verificatore o farlo scrivere a qualcun altro. Questi funzionano molto velocemente rispetto alla creazione, e ora o (1) entrambi i pezzi di codice sono errati (quindi perché preferiresti altri programmatori per i verificatori), o (2) la matematica dietro l'idea della prova è sbagliata. # 2 è sempre possibile, ma questi sono stati in genere pubblicati e recensiti da più persone (e in alcuni casi sono abbastanza facili da attraversare te stesso).

In confronto, metodi come AKS, APR-CL, divisione di prova o test deterministico di Rabin, non producono alcun output diverso da "prime" o "composito". In quest'ultimo caso potremmo avere un fattore che quindi possiamo verificare, ma nel primo caso non ci resta altro che questo bit di output. Il programma ha funzionato correttamente? Boh.

È importante testare il software su più di alcuni esempi di giocattoli, e anche passare attraverso alcuni esempi in ogni fase dell'algoritmo e dire "dato questo input, ha senso che io sia qui con questo stato?"

L'algoritmo shuffling di Fisher-Yates-Knuth è un esempio (pratico) e uno su cui uno degli autori di questo sito ha commentato .

L'algoritmo genera una permutazione casuale di un determinato array come:

 // 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$

Un algoritmo "ingenuo" potrebbe essere:

 // 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]

Dove nel ciclo l'elemento da scambiare viene scelto tra tutti gli elementi disponibili. Tuttavia, ciò produce un campionamento parziale delle permutazioni (alcune sono sovrarappresentate, ecc.)

In realtà si può inventare la mescolanza di pesca-yates-knuth usando un'analisi di conteggio semplice (o ingenua) .

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

Il problema principale con la verifica se l'algoritmo di shuffle è corretto o meno ( distorto o meno ) è che a causa delle statistiche è necessario un gran numero di campioni. L' articolo di codinghorror che linko sopra lo spiega esattamente (e con test reali).

L'esempio migliore (leggi: cosa di cui mi fa più male il culo) che abbia mai visto riguarda le congetture di collatz. Ero in una competizione di programmazione (con un premio di 500 dollari in prima fila) in cui uno dei problemi era trovare il numero minimo di passaggi necessari affinché due numeri raggiungessero lo stesso numero. La soluzione ovviamente è di alternare ciascuno fino a quando entrambi raggiungono qualcosa che è stato visto prima. Ci è stato dato un intervallo di numeri (penso che fosse tra 1 e 1000000) e ci è stato detto che la congettura di collatz era stata verificata fino a 2 ^ 64, quindi tutti i numeri che ci erano stati dati alla fine sarebbero convertibili a 1. Ho usato 32-bit numeri interi con cui eseguire i passaggi. Si scopre che esiste un numero oscuro compreso tra 1 e 1000000 (170 mila qualcosa) che causerà il trabocco di un numero intero a 32 bit a tempo debito. In realtà questi numeri sono estremamente rari sotto 2 ^ 31. Abbiamo testato il nostro sistema per numeri ENORMI di gran lunga superiori a 1000000 per "garantire" che non si verificasse un overflow. Risulta un numero molto più piccolo che non abbiamo appena testato ha causato trabocco. Poiché ho usato "int" anziché "long", ho ricevuto solo un premio di 300 dollari anziché un premio di $ 500.

Il problema di Knacksack 0/1 è uno che quasi tutti gli studenti ritengono risolvibile con un algoritmo avido. Ciò accade più spesso se in precedenza hai mostrato alcune soluzioni avide come la versione problematica dello zaino in cui funziona un algoritmo avido .

Per questi problemi, in classe , dovrei mostrare la prova per Knapsack 0/1 ( programmazione dinamica ) per rimuovere ogni dubbio e anche per la versione avida del problema. In realtà, entrambe le prove non sono banali e probabilmente gli studenti le trovano molto utili. Inoltre, c'è un commento al riguardo in CLRS 3ed , capitolo 16, pagina 425-427 .

Problema: il ladro ruba un negozio e può trasportare un peso massimo di W nello zaino. Ci sono n articoli e ogni articolo pesa wi e vale vi dollari. Quali oggetti dovrebbe prendere il ladro? massimizzare il suo guadagno ?

Zaino problema 0/1 : la configurazione è la stessa, ma gli oggetti non possono essere suddivisi in pezzi più piccoli , quindi il ladro può decidere di prendere un oggetto o di lasciarlo (scelta binaria), ma potrebbe non prendere una frazione di un oggetto .

E puoi ottenere dagli studenti alcune idee o algoritmi che seguono la stessa idea del problema della versione golosa, ovvero:

• Prendi la capacità totale della borsa e metti il ​​più possibile l'oggetto di maggior valore e itera questo metodo fino a quando non puoi mettere più oggetti perché la borsa è piena o non c'è un oggetto con meno o uguale peso da mettere all'interno della borsa.
• Un altro modo sbagliato è pensare: metti gli articoli più leggeri e mettili seguendo il prezzo più alto o più basso.
• ...

È utile per te? in realtà, sappiamo che il problema della moneta è una versione del problema dello zaino. Ma ci sono altri esempi nella foresta dei problemi degli zaini, ad esempio cosa ne pensi di Zaino 2D (è molto utile quando vuoi tagliare il legno per fare mobili , ho visto in un locale della mia città), è molto comune pensare che il anche qui gli avidi lavorano, ma no.

Un errore comune è quello di implementare errati algoritmi di shuffle. Vedi la discussione su Wikipedia .

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

Pythons PEP450 che ha introdotto funzioni statistiche nella libreria standard potrebbe essere interessante. Come parte della giustificazione per avere una funzione che calcola la varianza nella libreria standard di Python, l'autore Steven D'Aprano scrive:

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)

Quanto sopra sembra essere corretto con un test casuale:

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

Ma l'aggiunta di una costante per ogni punto dati non dovrebbe modificare la varianza:

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

E la varianza non dovrebbe mai essere negativa:

>>> variance(data*100)
  -1239429440.1282566

Il problema riguarda i numeri e come si perde la precisione. Se si desidera la massima precisione, è necessario ordinare le operazioni in un determinato modo. Un'implementazione ingenua porta a risultati errati perché l'imprecisione è troppo grande. Questo era uno dei problemi su cui il mio corso di numerazione all'università riguardava.

Anche se questo probabilmente non è proprio quello che stai cercando, è certamente facile da capire e testare alcuni piccoli casi senza alcun altro pensiero porterà a un algoritmo errato.

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

Soluzione proposta :

int f(int n) {
   return 1;
}

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

Questo approccio "prova alcuni piccoli casi e deduce un algoritmo dal risultato" affiora frequentemente (anche se non come in questo caso) nelle competizioni di programmazione in cui la pressione è quella di creare un algoritmo che (a) è veloce da implementare e (b ) ha un tempo di esecuzione rapido.