Come abbattere le tue prove

Quali sono le linee guida generali per la verifica delle prove? Credo che questo sia importante per i dottorandi come me. So già cosa dobbiamo fare per provare qualcosa, ma devi sempre controllare tutto prima di inviarlo. Anche al tuo consulente.

Ho sviluppato alcune strategie per tentativi ed errori e ho ricevuto molti consigli dal mio consulente. Ma questo è sempre un lavoro molto noioso. Normalmente, quando finisci con qualcosa, vuoi solo passare al problema successivo, ma devi ancora attenerti al problema attuale fino a quando tutto è perfetto. Qui presento un esempio del mio elenco di trucchi:

1. Inserisci i dettagli. Molti errori sono presenti in alcuni punti in cui scrivi "è chiaro che ...", "senza perdita di generalità ...", ecc.
2. Prova alcuni numeri. Prova casi estremi, come "cosa succede quando imposto o ".$n=1$$n=1000$
3. Tieni un quaderno pulito. Scrivici ogni giorno e confrontalo con le tue note approssimative. Provo a scrivere anche in lattice, ho trovato molti errori in questo modo.

Quali sono le strategie generali che applichi per controllare le tue prove?

L'obiettivo di questa domanda è di renderlo un wiki della community.

Gli ingegneri del software hanno un'idea che chiamano " odori di codice ". Questi sono sintomi nel codice che possono indicare un problema più profondo. Gli ingegneri del software raccolgono elenchi mentali di odori di cui tenere conto (ovvero metodi eccessivamente lunghi o troppi parametri). Non significa necessariamente che c'è un problema, ma indica semplicemente che lo scrittore potrebbe voler ricontrollare.

Propongo che dovremmo considerare anche "odori di prova" . Questo non ti darà un algoritmo per controllare le tue prove ma ti darà una lingua e una metafora per riconoscere possibili problemi nelle prove. Alcuni esempi di odori di prove:

1. Gli avverbi "Chiaramente", "Ovviamente", ecc.
2. Riferimento alla prova di un risultato precedente anziché un riferimento al risultato stesso.
3. Uso irriverente di un risultato con molti presupposti tecnici.

Ci sono anche odori più sottili. Ad esempio, se una dimostrazione usa il teorema binomiale per espandere un'espressione e successivamente usa il teorema binomiale per tornare a una forma chiusa, allora forse c'è una manipolazione diretta sulla forma chiusa che dà lo stesso risultato.

Il mio suggerimento è di raccogliere un elenco (mentale o scritto) di tali odori e verificarne la lettura mentre leggete il vostro lavoro. Il piacevole effetto collaterale di questo approccio è che ti renderà anche un lettore migliore.

Nota: la mia speranza in questa risposta era di dare un lato intuitivo alla risposta rigorosa fornita da Come scrivere una prova di Lamport a cui fa riferimento la risposta di M. Alaggan.

C'è un ottimo documento di Leslie Lamport ( Come scrivere una prova ). In realtà è una sua proposta su uno stile di scrittura di prove dettagliate in modo tale che:

(1) Consente di rilevare gli errori in modo diretto

(2) Illustra quali ipotesi e teoremi vengono utilizzati in quali parti, il che rende abbastanza facile vedere cosa succede se si desidera (ad esempio) utilizzare ipotesi più deboli

C'è anche qualche esperienza della comunità e commenti ispiratori su questa tecnica su MO che mostra un'esperienza positiva in generale (e anche alcune altre risorse).

Aggiornamento: c'è una nuova versione Come scrivere una prova del 21 ° secolo .

Dick Lipton ha un bell'articolo intitolato " Come provare una prova è una prova "

Mi sembra di aver letto molto tempo fa un famoso racconto di come i fisici affrontano un problema analogo. Chissà quanto sia accurata la seguente versione di esso; le correzioni sono benvenute. Ma ho trovato la strategia di base abbastanza notevole.

Spiegarono come arrivarono a credere nei buchi neri. I buchi neri erano inizialmente costrutti puramente matematici, come altri strani oggetti in fisica come i wormhole. La loro strategia era sorprendente: avrebbero lanciato matematicamente altri oggetti sull'oggetto da testare. I wormhole non hanno superato i loro test perché hanno scoperto che il wormhole sarebbe crollato anche in presenza di un normale oggetto fisico, forse un asteroide. Ma i buchi neri hanno superato questo test: il buco nero sarebbe sopravvissuto se gli fosse stato lanciato un asteroide. Quindi hanno provato a lanciargli una stella. Stesso risultato Alla fine, lanciarono un altro buco nero sul buco nero e sopravvisse. Di conseguenza, sono diventati abbastanza sicuri dell'esistenza dei buchi neri da iniziare a cercarli nel vero universo.

Quindi la pertinenza e l'applicazione della strategia di cui sopra è iniziare a gettare le cose alla tua prova. Sopravvive ai controlli di integrità ? Se rimuovi un presupposto necessario, collassa come dovrebbe? Crolla come dovrebbe quando viene applicato a casi al di fuori del suo ambito? Resiste a generalizzazioni e specializzazioni ragionevoli? Dai un'occhiata all'elenco delle euristiche in Come risolverlo in Polya . Prova a mutare la tua prova con queste euristiche e vedi se resiste e cade come dovrebbe.

Penso che uno degli approcci più sicuri sia quello di elaborare prove multiple indipendenti. Quindi puoi essere sicuro che il tuo risultato principale sia corretto, anche se hai un errore in alcuni dettagli di una prova.

Una tecnica che ho trovato utile è pensare a quali altri risultati sarebbe in grado di dimostrare la strategia di dimostrazione. Se sono facilmente in grado di adattare la strategia di prova per dimostrare un grosso problema aperto o anche un problema che non è aperto ma che ha una soluzione troppo complicata rispetto alla complessità della strategia di prova, allora questa è una grande ragione per dubitare la prova.

Ricontrollo sempre le prove con un correttore di prove come COQ o ISABELLE . Se riesci a provare la tua prova in uno di questi linguaggi di programmazione, puoi essere sicuro che la prova sia corretta. Semplice come un termine lambda;).