Як збити ваші докази


59

Які загальні рекомендації щодо перевірки ваших доказів? Я вважаю, що це важливо для аспірантів, як я. Я вже знаю, що нам потрібно зробити, щоб щось довести, але завжди потрібно перевірити все, перш ніж відправити це. Навіть до власного радника.

Я розробив собі деякі стратегії шляхом спроб та помилок і отримав багато порад від свого радника. Але це завжди дуже копітка робота. Зазвичай, коли ви щось закінчите, ви просто хочете перейти до наступної проблеми, але вам все одно доведеться дотримуватися поточної проблеми, поки все не буде ідеально. Тут я представляю приклад власного списку хитрощів:

  1. Заповніть деталі. Дуже багато помилок там, де ви писали "зрозуміло, що ...", "без втрати загальності ..." тощо.
  2. Спробуйте кілька цифр. Спробуйте крайні випадки, наприклад, "що відбувається, коли я встановлю або n = 1000 ".n=1n=1000
  3. Ведіть чистий зошит. Пишіть на ньому кожен день і порівнюйте його з грубими нотами. Я намагаюся писати також в латекс, я знайшов багато помилок таким чином.

Які загальні стратегії ви застосовуєте для перевірки ваших доказів?

Мета цього питання - зробити його вікі-спільнотою.


Якщо питання видається суб’єктивним, будь ласка, допоможіть мені його покращити.
Marcos Villagra

як мені зробити цю спільноту-вікі?
Маркос Віллагра

1
Гей, здорово! Мені дуже цікаві відповіді на це питання. Також я можу оцінити ваш №3. (Коли я замислююсь над цим, у мене насправді скрізь розкидані купи паперу, коли я навмисно працюю над проблемою, яка потім перестає випадковим чином переїжджати. Юк.) Я зіткнувся з помилкою раніше з цієї самої проблеми і закінчив марнувати гарний шматок часу.
Даніель Апон

@Daniel: У мене була така ж проблема !! Ось чому після того, як я фінська з доказом, одразу пишу латексну версію. Добре знати, що я не єдиний безладний хлопець, який тримає все скрізь :-)
Marcos Villagra

1
ви позначите його на увагу модератора.
Суреш Венкат

Відповіді:


39

Інженери програмного забезпечення мають поняття, яке вони називають " кодовим запахом ". Це симптоми в коді, які можуть вказувати на більш глибоку проблему. Інженери програмного забезпечення збирають ментальні списки запахів, про які слід знати (тобто надмірно довгі методи або занадто багато параметрів). Це не обов'язково означає, що є проблема, а просто вказує на те, що письменник може захотіти перевірити ще раз.

Я пропоную також нам розглянути питання про "доказові запахи" . Це не дасть вам алгоритму перевірки ваших доказів, але це дає мову та метафору для розпізнавання можливих проблем у доказуванні. Деякі приклади доказів пахнуть:

  1. Прислівники «Чітко», «Очевидно» тощо.
  2. Посилання на доказ попереднього результату замість посилання на сам результат.
  3. Легке використання результату з багатьма технічними передумовами.

Є і більш тонкі запахи. Наприклад, якщо доказ використовує біноміальну теорему для розширення виразу, а потім пізніше використовує біноміальну теорему для повернення до закритої форми, то, можливо, є пряма маніпуляція із закритою формою, яка дає такий же результат.

Моя пропозиція - зібрати (розумовий чи письмовий) список таких запахів і перевірити їх, коли ви читаєте свою роботу. Приємний побічний ефект такого підходу полягає в тому, що він також зробить вас кращим читачем.

Примітка: Моя надія в цій відповіді полягала в тому, щоб дати інтуїтивну сторону суворій відповіді, яку надає Лампорт "Як написати доказ", на який посилається у відповіді М. Алагана.


4
Я постійно кажу це своїм студентам, і вони думають, що я божевільний. Звичайно, я фактично стверджую, що я відчуваю запах помилки, що може бути частиною проблеми;)
Суреш Венкат

7
@Suresh: Цей студент вважає, що ти з розуму з різних причин. ;-)
Джон Моеллер

4
У примітці про запах коду речі, які я завжди намагаюся уважно вивчити в доказах інших, включають ланцюги нерівності. Часто дійсно основні помилки мають звичку пробиратися серед складніших витворень.
Джон Моеллер

23

Є дуже хороший документ Леслі Лампорт ( Як написати доказ ). Це насправді пропозиція про стиль написання детальних доказів таким чином, щоб:

(1) Дозволяє виявляти помилки прямолінійно

(2) Пояснює, які припущення та теореми використовуються в яких частинах, що дозволяє досить легко зрозуміти, що відбувається, якщо ви хочете (наприклад) використовувати слабкіші припущення

Існує також певний досвід спільноти та надихаючий коментар щодо цієї методики щодо МО, який показує позитивний досвід загалом (та деякі інші ресурси).

Оновлення: є нова версія Як написати доказ 21 століття .


5
Ці докази дуже схожі на те, що можна було б написати в дослідницькому документі PL. Ланцюг логіки дуже явний. Навчившись читати та оцінювати докази в стилі PL, мені складно було зрозуміти «нормальні» математичні докази. Такі докази часто вимагають, щоб читач міркував так само, як це робить автор, і коли ви звикли до іншого стилю доказування, це просто не так (як мінімум, для мене!)
Крістофер Монсанто

2
@Christopher Monsanto: PL означає Мови програмування? Буду вдячний, якщо ви можете згадати такий приклад (один такий документ), щоб перевірити :)
М. Алаган

5
У мене завжди було відчуття, що те, що пропонує Лампорт, не сумісне з "Плачем математика" Пола Локхарта ( maa.org/devlin/LockhartsLament.pdf ).
Маркос Віллагра


14

Я, здається, пам’ятаю, як давно читав популярний запис про те, як фізики мають справу з аналогічною проблемою. Хто знає, наскільки точна його версія; виправлення вітаються. Але я вважав, що основна стратегія є досить чудовою.

Вони пояснили, як вони повірили у чорні діри. Чорні діри були спочатку чисто математичними конструкціями, як і інші дивні об'єкти у фізиці, як червоточини. Їх стратегія була вражаючою: вони математично кидали б інші об'єкти на тестуваний об'єкт. Червотоки провалили свої випробування, оскільки виявили, що черв'ячна криниця руйнується навіть у присутності нормального фізичного об'єкта, можливо, астероїда. Але чорні діри пройшли це випробування: чорна діра вижила б, коли на неї кинули астероїд. Тому вони намагалися кинути на нього зірку. Той самий результат. Нарешті вони кинули ще одну чорну діру на чорну діру, і вона вижила. В результаті цього вони набули достатньо впевненості в існуванні чорних дір, щоб насправді почати шукати їх у реальному Всесвіті.

Тож доречність та застосування стратегії, зазначеної вище, полягає в тому, щоб почати кидати справи на ваш доказ. Чи витримає це перевірка санітарності ? Якщо ви видалите необхідне припущення, воно руйнується як слід? Чи він руйнується як слід, коли застосовується до справ, що виходять за межі його сфери? Чи витримує це розумні узагальнення та спеціалізації? Погляньте на перелік евристики у Полі « Як її вирішити» . Спробуйте вимкнути своє доказ з цією евристикою і подивіться, чи воно стоїть і падає як слід.


Більшість вашої відповіді зосереджується на тому, щоб перевірити докази, перевіривши, що вони стають помилковими в ситуаціях, коли вони повинні бути помилковими. Це не працює, оскільки не перевіряє, чи теорема була правдою там, де вона повинна була бути правдою! Наприклад, припустимо, що я "довів", що кожне непарне число ділиться на три. Я перевіряю, що мій доказ не вдається, якщо я поширююсь і на парні числа: це так, оскільки чотири не поділяються на три. Ура, мій доказ повинен бути правильним!
Девід Річербі,

12

Я думаю, що одним із найбезпечніших підходів є створення декількох незалежних доказів. Тоді ви можете бути впевнені, що ваш головний результат правильний, навіть якщо ви помилилися в деяких деталях доказу.


9

Один з методів, який я вважав корисним, - це подумати над тим, які інші результати могли б довести стратегію доказування. Якщо мені легко вдається адаптувати доказову стратегію, щоб довести велику відкриту проблему або навіть проблему, яка не є відкритою, але яка має занадто складне рішення порівняно зі складністю стратегії доказування, то це великий привід сумніватися. доказ.


5
PNP

6

Я завжди повторно перевіряю свої докази за допомогою перевірки, наприклад COQ або ISABELLE . Якщо ви можете довести своє підтвердження будь-якою з цих мов програмування, ви можете бути впевнені, що ваші докази правильні. Так просто, як лямбда-термін;).


Я ніколи не використовував Coq, але мені слід спробувати. Насправді я намагаюся довести деякі нижчі межі з математикою, але я не знайшов правильного шляху. Можливо, мені потрібні спеціальні пакети чи щось.
Marcos Villagra

1
Можливо, це довгий знімок, але якщо ви хочете довести деякі нижчі межі за допомогою дійсних даних, ви можете перевірити ці бібліотеки: coqtail.sourceforge.net/?home/en
Gopi

Погоджено, але будь-яка мова програмування працює. Найчастіше я роблю це в зворотному порядку. Сформулюйте проблемний домен мовою програмування (як правило, Ruby), а потім використовуйте це як шаблон для мого підтвердження.
Чад Brewbaker
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.