Як обдурити евристику "спробувати деякі тестові випадки": Алгоритми, які здаються правильними, але насправді є невірними

Щоб спробувати перевірити правильність алгоритму для якоїсь проблеми, звичайним початковим пунктом є спробувати запустити алгоритм вручну на декількох простих тестових випадках - спробуйте його на кількох прикладах проблемних випадків, включаючи кілька простих "кутових випадків" ". Це чудова евристика: це чудовий спосіб швидко вилучити багато неправильних спроб алгоритму та зрозуміти, чому алгоритм не працює.

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

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

Конкретно шукаю:

1. Алгоритм. Недолік повинен бути на алгоритмічному рівні. Я не шукаю помилок в реалізації. (Наприклад, при мінімальному рівні приклад повинен бути мовно-агностичним, і недолік повинен стосуватися алгоритмічних проблем, а не інженерії програмного забезпечення або впровадження.)

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

3. Алгоритм, який би пройшов розумну ручну тестову стратегію з високою ймовірністю. Хтось, хто намагається вручну спробувати кілька невеликих тестових випадків, навряд чи виявить недолік. Наприклад, "моделювати QuickCheck вручну з десятка невеликих тестових випадків" навряд чи виявить, що алгоритм невірний.

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

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

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

Приклад: Номінали монет, та число , виражають як суму : s з якомога кількістю монет. n n d $d_1,\dots,d_k$$n$$n$$d_i$

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

Наприклад, монети зі значенням , і дадуть правильні відповіді з жадібними відповідями на всі числа від до за винятком числа .5 1 1 14 10 = 6 + 1 + 1 + 1 + 1 = 5 + $6$$5$$1$$1$$14$$10 = 6+1+1+1+1 = 5+5$

Я одразу згадав приклад Р. Бекхаус (це, можливо, було в одній із його книг). Мабуть, він призначив завдання програмування, коли студенти повинні були написати програму Pascal для перевірки рівності двох рядків. Однією з програм, до яких звернувся студент, була така:

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

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

write(issame);

Тепер ми можемо протестувати програму за допомогою таких даних:

"університет" "університет" Правда; гаразд$\Rightarrow$

"курс" "курс" Правда; гаразд$\Rightarrow$

"" "" Правда; гаразд$\Rightarrow$

"університетський" "курс" Неправдиво; гаразд$\Rightarrow$

"лекція" "курс" Неправдиво; гаразд$\Rightarrow$

"точність" "точність" Неправда, гаразд$\Rightarrow$

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

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

Ще один милий приклад - двійковий пошук. У TAOCP Кнут говорить, що "хоча основна ідея бінарного пошуку є порівняно простою, деталі можуть бути напрочуд хитромудрими". Мабуть, помилка в реалізації двійкового пошуку Java залишилася непоміченою протягом десятиліття. Це була ціла помилка переповнення і виявлялася лише при досить великому вході. Хитрі деталі реалізації двійкового пошуку також висвітлюються Бентлі в книзі « Програмування перлів» .

Підсумок: напрочуд важко бути впевненим, що бінарний алгоритм пошуку правильний, просто перевіривши його.

Найкращий приклад, з яким я коли-небудь стикався, - це перевірка первинності:

вхід: натуральне число p, p! = 2
вихід: є простим чи ні?
алгоритм: обчислити 2 ** (p-1) mod p. Якщо результат = 1, то p є простим іншим, p не є.

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

Замість того, щоб просто використовувати 2 в якості основи потужності, можна вдосконалити алгоритм, використовуючи також додаткові, збільшуючи невеликі прайми в якості основи у випадку, якщо попередній прайм повернувся 1. І все-таки є контрприклад цієї схеми, а саме числа Кармайкхолла, досить рідкісна, хоча

Ось такий, який кинув на мене google повторень на конвенції, на яку я пішов. Він був закодований в C, але він працює іншими мовами, які використовують посилання. Вибачте за те, що потрібно кодувати на [cs.se], але це лише проілюструвати.

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

Цей алгоритм буде працювати для будь-яких значень, заданих x і y, навіть якщо вони однакові. Однак він не працюватиме, якщо його називають swap (x, x). У цій ситуації х закінчується як 0. Тепер це може вас не задовольнити, оскільки ви можете якось довести, що ця операція є математично правильною, але все ж забути про цей крайній випадок.

Є цілий клас алгоритмів, який по суті важко перевірити: генератори псевдовипадкових чисел . Ви не можете перевірити один вихід, але доведеться досліджувати (багато) ряд виходів за допомогою статистики. Залежно від того, що і як ви протестуєте, ви цілком можете пропустити невипадкові характеристики.

Один відомий випадок, коли справи йшли жахливо не так - RANDU . Він пройшов доступний пильний аналіз, який не міг врахувати поведінку кортежів наступних результатів. Вже тричі показують багато структури:

В основному тести не охоплювали всіх випадків використання: хоча одновимірне використання RANDU було (мабуть, переважно) добре, воно не підтримувало його використання для вибірки тривимірних точок (таким чином).

Правильна псевдовипадкова вибірка - справа хитра. На щастя, там існують потужні набори тестів, наприклад, dieharder, які спеціалізуються на передачі всієї статистики, яку ми знаємо, на запропонованому генераторі. Чи достатньо?

^{Якщо чесно, я не маю уявлення, що можна довести для PRNG.}

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$

то кожна жирна клітина є локальним максимумом. Кожен непустий масив має щонайменше один локальний максимум.

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

Таким чином, ми довели наступну теорему:

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

Або ми?

Це приклади первинності, оскільки вони поширені.

(1) Первинність у SymPy. Випуск 1789 року . На відомому веб-сайті було проведено неправильне тестування, яке провалилося не пізніше 10 ^ 14. Хоча виправлення було правильним, це було лише латання дірок, а не переосмислення проблеми.

(2) Первинність в Perl 6. Perl6 додав первинний прайм, який використовує ряд тестів MR на фіксованій основі. Існують відомі контрприклади, але вони досить великі, оскільки кількість тестів за замовчуванням величезна (в основному приховуючи реальну проблему, знижуючи продуктивність). Це буде вирішено найближчим часом.

(3) Первинність у FLINT. n_isprime (), що повертає справжнє для композитів , оскільки виправлено. В основному те саме питання, що і SymPy. Використовуючи базу даних Feitsma / Galway псевдоприкладів SPRP-2 до 2 ^ 64, ми можемо перевірити їх.

(4) Матерія Перла: Первинність. is_aks_prime порушено . Ця послідовність здається схожою на безліч реалізацій AKS - безліч кодів, які або спрацьовували випадково (наприклад, загубилися на етапі 1 і в кінцевому підсумку робили всю справу шляхом пробного поділу), або не працювали для великих прикладів. На жаль, AKS настільки повільний, що його важко перевірити.

(5) Попереднє значення 2.2 для Пари є Математика :: Білет Пари . Він використовував 10 випадкових баз для тестів на МР (з фіксованим насінням при запуску, а не з фіксованим насінням GMP кожного виклику). Він скаже вам, що 9 - це приблизно 1 з кожного 1М-дзвінка. Якщо ви виберете потрібне число, ви зможете вийти з ладу відносно часто, але цифри стають рідшими, тому на практиці це не дуже добре відображається. З тих пір вони змінили алгоритм та API.

Це не помиляється, але це класика ймовірнісних тестів: скільки раундів ви даєте, скажімо, mpz_probab_prime_p? Якщо ми дамо йому 5 раундів, це впевнено виглядає, що він працює добре - номери повинні пройти базовий тест Ферма-210 і потім 5 попередньо вибраних баз тестів Міллера-Рабіна. Ви не знайдете контрприклад до 3892757297131 (з GMP 5.0.1 або 6.0.0a), тому вам доведеться зробити багато тестування, щоб знайти його. Але є тисячі зустрічних прикладів під 2 ^ 64. Таким чином, ви продовжуєте збільшувати кількість. Як далеко? Чи є противник? Наскільки важлива правильна відповідь? Ви плутаєте випадкові бази з фіксованими базами? Чи знаєте ви, які розміри вводу вам дадуть?

$10^{16}$

Їх досить складно перевірити правильно. Моя стратегія включає очевидні одиничні тести, плюс крайові випадки, а також приклади відмов, виявлені перед або в інших пакунках, тестуйте порівняно з відомими базами даних, де це можливо (наприклад, якщо ви робите один тест базового рівня-2 МР, то ви зменшили обчислювально нездійсненні завдання тестування 2 ^ 64 чисел для тестування близько 32 мільйонів чисел), і, нарешті, безліч рандомізованих тестів, використовуючи інший пакет як стандарт. Останній пункт працює для таких функцій, як первинність, де є досить простий вхід і відомий вихід, але досить багато завдань схожі на це. Я використовував це для виявлення дефектів як у власному коді розробки, так і у випадкових проблемах у пакунках порівняння. Але враховуючи нескінченний вхідний простір, ми не можемо протестувати все.

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

Для порівняння, такі методи, як AKS, APR-CL, пробний поділ або детермінований тест Рабіна, не дають іншого виходу, окрім "простих" або "композитних". В останньому випадку ми можемо мати чинник, який ми можемо перевірити, але в першому випадку нам не залишається нічого іншого, крім цього одного біта виводу. Чи правильно працювала програма? Данно.

Важливо перевірити програмне забезпечення на кількох іграшкових прикладах, а також пройти кілька прикладів на кожному кроці алгоритму і сказати "з урахуванням цього вводу, чи є сенс, що я тут з цим станом?"

Алгоритм перетасовки Фішера-Йейтса-Кнута є (практичним) прикладом, про який прокоментував один з авторів цього сайту .

Алгоритм генерує випадкову перестановку даного масиву як:

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

"Наївним" алгоритмом може бути:

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

Де в циклі, елемент, який потрібно поміняти, вибирається з усіх доступних елементів. Однак це призводить до упередженої вибірки перестановок (деякі з них представлені надмірно тощо).

Насправді можна придумати переміщення рибалок-ятеш-кнут, використовуючи простий (або наївний) аналіз підрахунку .

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

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

Найкращий приклад (читайте: те, що мене найбільше болить в задниках ), я коли-небудь бачив, пов'язане з гіпотезою коллац. Я був у змаганні з програмування (з першочерговим призом 500 доларів на першому місці), в якому однією з проблем було знайти мінімальну кількість кроків, необхідних для двох чисел, щоб досягти однакової кількості. Рішення, звичайно, полягає в тому, щоб по черзі крокувати кожен з них, поки вони обидва не досягнуть чогось, що бачили раніше. Нам дали нам діапазон чисел (я думаю, це було від 1 до 1000000) і сказали, що гіпотеза Колаца була перевірена до 2 ^ 64, тому всі числа, які нам дали, врешті збігаються в 1. Я використовував 32-бітні цілі числа робити кроки, однак. Виявляється, що існує одне незрозуміле число між 1 і 1000000 (170 тис. Щось), яке спричинить переповнення 32-бітного цілого числа у свій час. Насправді ці цифри є вкрай рідкісними нижче 2 ^ 31. Ми перевірили нашу систему на ВЕЛИЧЕЗНІ числа, які перевищують 1000000, щоб "переконатися", що переповнення не відбулося. Виходить набагато менша кількість, яку ми просто не тестували, спричиняючи переповнення. Тому що я використовував "int" замість "long", я отримав лише приз у розмірі 300 доларів, а не приз у розмірі 500 доларів.

Проблема Knapsack 0/1 - це проблема, яку майже всі учні вважають вирішуваною жадібним алгоритмом. Це трапляється частіше, якщо раніше ви показуєте якісь жадібні рішення як проблему версії Knapsack, де працює жадібний алгоритм .

Для цих проблем у класі я повинен показати доказ Knapsack 0/1 ( динамічне програмування ) для усунення будь-яких сумнівів і для жадної версії проблеми також. Насправді обидва докази не є банальними, і студенти, ймовірно, вважають їх дуже корисними. Крім того, є коментар до цього в CLRS 3ed , Глава 16, Сторінка 425-427 .

Проблема: злодій грабує магазин і може перенести максимальну вагу Вт у свій рюкзак. Існує п предметів, а цей предмет важить wi і коштує vi доларів. Які предмети повинен взяти злодій? щоб максимізувати свій прибуток ?

Проблема з рюкзаком 0/1 : налаштування те саме, але елементи можуть не розбиватися на більш дрібні шматки , тому злодій може вирішити або взяти предмет, або залишити його (двійковий вибір), але може не взяти частину предмета .

І ви можете отримати від студентів кілька ідей або алгоритмів, які відповідають тій же ідеї, що і жадібна версія версії, це:

• Візьміть загальну ємність мішка і покладіть якомога більше найціннішого предмета і повторіть цей метод, поки ви не зможете покласти більше предметів, оскільки мішок повний або немає предмета з меншим рівним вагою для покладеного всередину сумки.
• Інший неправильний спосіб - мислення: поставте більш легкі предмети і поставте наступні найвищі до найнижчих цін.
• ...

Це вам корисно? насправді ми знаємо, що проблема з монетою є версією проблеми з рюкзаком. Але є ще кілька прикладів проблем лісового ранку, наприклад, що стосується Рюкзака 2D (це справді корисно, коли ви хочете різати деревину для виготовлення меблів , я бачив у місцевому з мого міста), дуже часто вважають, що жадібні тут теж працюють, але ні.

Поширена помилка - неправильно реалізувати алгоритми перетасування. Дивіться дискусію на wikipedia .

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

Пітони PEP450, які запровадили статистичні функції в стандартну бібліотеку, можуть зацікавити. Як частина обґрунтування наявності функції, яка обчислює дисперсію в стандартній бібліотеці пітона, автор Стівен Д'Апрано пише:

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)

Наведене вище видається правильним у випадковому тесті:

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

Але додавання константи до кожної точки даних не повинно змінювати дисперсію:

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

І дисперсія ніколи не повинна бути негативною:

>>> variance(data*100)
  -1239429440.1282566

Питання стосується числових даних і того, як втрачається точність. Якщо ви хочете отримати максимальну точність, вам доведеться певним чином замовляти свої операції. Наївна реалізація призводить до неправильних результатів, оскільки неточність занадто велика. Це було одним із питань, про який ходив мій курс чисельності в університеті.

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

Проблема : Напишіть функцію, яка приймає негативне ціле число і повертає кількість належних дільників n 2 + $n$$n^2+n+41$$0<d$$d\text{ divides } n^2+n+41$$d < n^2+n+41$

Пропоноване рішення :

int f(int n) {
   return 1;
}

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

Це "спробуй кілька невеликих випадків і підрахуй алгоритм з результату" підходить часто (хоча і не настільки надзвичайно, як тут) на змаганнях з програмування, де тиском потрібно створити алгоритм, який (a) швидко реалізується і (b ) має швидкий час роботи.