「いくつかのテストケースを試す」ヒューリスティックを欺く方法：正しいように見えるが実際は正しくないアルゴリズム

ある問題のアルゴリズムが正しいかどうかをテストするための通常の出発点は、いくつかの単純なテストケースでアルゴリズムを手動で実行してみることです。 「。これは優れたヒューリスティックです。これは、アルゴリズムに対する誤った試行の多くを迅速に排除し、アルゴリズムが機能しない理由を理解するための優れた方法です。

ただし、アルゴリズムを学習するとき、一部の学生はそこでやめようとします：試行することを考えられるすべてのコーナーケースを含む少数の例でアルゴリズムが正しく機能する場合、アルゴリズムが正しい必要があると結論付けます。「いくつかのテストケースで試してみることができるのに、なぜアルゴリズムが正しいことを証明する必要があるのか​​」と尋ねる学生が常にいます。

それでは、「多数のテストケースを試す」ヒューリスティックをどのように欺くのでしょうか。このヒューリスティックでは不十分であることを示す良い例を探しています。言い換えれば、表面的には正しいように見えるアルゴリズムの1つ以上の例を探しており、だれかが思い付く可能性のあるすべての小さな入力に対して正しい答えを出力しますが、アルゴリズムは実際には動作しません。たぶん、アルゴリズムはたまたますべての小さな入力で正しく動作し、大きな入力に対してのみ失敗するか、異常なパターンを持つ入力に対してのみ失敗します。

具体的には、私は探しています：

1. アルゴリズム。欠陥はアルゴリズムレベルである必要があります。実装のバグを探していません。（たとえば、最低限、この例は言語にとらわれず、ソフトウェアエンジニアリングや実装の問題ではなく、アルゴリズムの問​​題に関連する必要があります。）

2. 誰かがもっともらしく思いつくかもしれないアルゴリズム。擬似コードは、少なくとももっともらしいように見えるはずです（たとえば、難読化された、または明らかに疑わしいコードは良い例ではありません）。宿題や試験の問題を解決しようとするときに、一部の学生が実際に思いついたアルゴリズムである場合、ボーナスポイントがあります。

3. 妥当な手動テスト戦略に高い確率で合格するアルゴリズム。手作業でいくつかの小さなテストケースを試みる人は、欠陥を発見する可能性は低いはずです。たとえば、「12個の小さなテストケースで手動で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$

私はすぐにR. Backhouseの例を思い出しました（これは彼の本の1つにあったかもしれません）。どうやら、彼は2つの文字列の等価性をテストするために学生がPascalプログラムを作成する必要があるプログラミングの割り当てを割り当てていたようです。学生が提出したプログラムの1つは次のとおりです。

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

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

write(issame);

次の入力でプログラムをテストできます。

「大学」「大学」真。OK$\Rightarrow$

「コース」「コース」真。OK$\Rightarrow$

"" "" ; OK$\Rightarrow$

「大学」「コース」偽。OK$\Rightarrow$

「講義」「もちろん」偽。OK$\Rightarrow$

「精度」「正確」偽、OK$\Rightarrow$

これらはすべて非常に有望なようです。おそらくプログラムは実際に機能するでしょう。しかし、「純粋」と「真」と言うより慎重なテストでは、出力に誤りがあることが明らかになります。実際、文字列が同じ長さと同じ最後の文字を持っている場合、プログラムは「True」と言います！

ただし、テストは非常に徹底的でした。長さの異なる文字列、長さは等しいが内容が異なる文字列、さらには文字列が等しい場合もありました。さらに、学生はすべてのブランチをテストして実行しました。ここではテストが不注意だったと主張することはできません。プログラムが実際に非常に単純であるため、十分にテストするための動機とエネルギーを見つけるのは難しいかもしれません。

別のかわいい例は、バイナリ検索です。TAOCPで、Knuthは「バイナリ検索の基本的な考え方は比較的簡単ですが、詳細は驚くほどトリッキーになる可能性がある」と述べています。どうやら、Javaのバイナリ検索実装のバグは10年間気付かれていませんでした。これは整数オーバーフローのバグであり、十分な大きさの入力でのみ現れました。バイナリ検索実装のトリッキーな詳細については、Bentleyの 『Programming Pearls』でも取り上げられています。

結論：バイナリ検索アルゴリズムが正しいかどうかをテストするだけでは、驚くほど難しい場合があります。

私が出会った中で最高の例は、素数性のテストです：

入力：自然数p、p！= 2
出力：paプライムかどうか？
アルゴリズム：2 **（p-1）mod pを計算します。結果= 1の場合、pは素数であり、そうでない場合はpです。

これは、ごく少数の反例を除き、ほぼすべての数で機能します。実際には、現実的な期間で反例を見つけるためにマシンが必要です。最初の反例は341であり、反例の密度はpの増加とともに減少しますが、ほぼ対数になります。

単にパワーの基礎として2を使用する代わりに、前の素数が1を返した場合に、基礎として追加の増加する小さな素数を使用することでアルゴリズムを改善できます。さらに、このスキームに対する反例、すなわちCarmichael数、かなりまれですが

これは私が行った大会でGoogleの担当者によって私に投げられたものです。Cでコーディングされていますが、参照を使用する他の言語でも機能します。[cs.se]をコーディングする必要がありますが、それを説明するのはそれだけです。

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

このアルゴリズムは、同じ値であっても、xとyに与えられた値に対して機能します。ただし、swap（x、x）として呼び出された場合は機能しません。この状況では、xは0になります。この操作が数学的に正しいことを何らかの方法で証明することはできますが、このエッジケースについては忘れることができるため、これで満足できないかもしれません。

本質的にテストするのが難しいアルゴリズムのクラス全体があります：擬似乱数ジェネレーター。単一の出力をテストすることはできませんが、統計を使用して（多くの）一連の出力を調査する必要があります。何をどのようにテストするかにもよりますが、非ランダムな特性を見逃す可能性があります。

物事がひどく間違っていた有名なケースの1つはRANDUです。その時点で利用可能な精査に合格しました- 後続の出力のタプルの動作を考慮できませんでした。すでにトリプルは多くの構造を示しています：

基本的に、テストはすべてのユースケースをカバーしていませんでした：RANDUの1次元の使用は（おそらくほとんど）大丈夫でしたが、3次元の点をサンプリングするための使用はサポートしていませんでした（この方法で）。

適切な擬似ランダムサンプリングは、トリッキーなビジネスです。幸いなことに、例えば、強力なテストがスイート日、ある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$

太字のセルはそれぞれ極大値です。空でない配列にはすべて、少なくとも1つのローカル最大値があります。

$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年。よく知られているWebサイトに誤ったテストが行​​われ、10 ^ 14まで失敗しませんでした。修正は正しいものでしたが、問題を再考するのではなく、単にパッチを当てるだけでした。

（2）Perl 6の素数性。Perl6には、固定ベースで多数のMRテストを使用するis-primeが追加されました。反例は知られていますが、デフォルトのテスト数が膨大であるため、かなり大きくなります（基本的にパフォーマンスを低下させることで実際の問題を隠します）。これはすぐに対処されます。

（3）FLINTの素数。 修正されたため、n_isprime（）はcompositesに対してtrueを返します。基本的にSymPyと同じ問題。SPRP-2擬似プライムのFeitsma / Galwayデータベースを2 ^ 64に使用して、これらをテストできます。

（4）PerlのMath :: Primality。 is_aks_primeが壊れています。このシーケンスは、多くのAKS実装に類似しているようです-偶然に動作した（たとえば、ステップ1で失われ、試用部門ですべてを実行した）多くのコードは、より大きな例では動作しませんでした。残念ながら、AKSは非常に遅いため、テストが困難です。

（5）Pariの2.2より前のis_prime。 Math :: Pariチケット。MRテストには10​​個のランダムベースを使用しました（呼び出しごとにGMPの固定シードではなく、起動時に固定シードを使用）。9が、1Mコールごとに約1であることがわかります。適切な番号を選択すると、比較的頻繁に失敗する可能性がありますが、番号がまばらになるため、実際にはあまり表示されません。その後、アルゴリズムとAPIが変更されました。

これは間違いではありませんが、古典的な確率的テストです。たとえば、mpz_probab_prime_pを何ラウンド与えますか？5ラウンドを与えると、うまくいくように見えます。数字はbase-210 Fermatテストに合格し、次に5つの事前選択されたbases-Miller-Rabinテストに合格する必要があります。3892757297131（GMP 5.0.1または6.0.0aを使用）まで反例は見つからないため、それを見つけるには多くのテストを行う必要があります。しかし、2 ^ 64には数千の反例があります。だからあなたは数を増やし続けます。どのくらい遠い？敵はいますか？正解はどれくらい重要ですか？ランダムベースと固定ベースを混同していますか？与えられる入力サイズを知っていますか？

$10^{16}$

これらを正しくテストすることは非常に困難です。私の戦略には、明白な単体テストに加えて、エッジケースに加えて、可能であればテスト対既知のデータベースの前または他のパッケージで見られる障害の例が含まれます（たとえば、単一のベース2 MRテストを行う場合、計算上実行不可能な2 ^ 64の数字をテストし、約3,200万の数字をテストするタスク）、最後に、別のパッケージを標準として使用する多くのランダム化テスト。最後の点は、かなり単純な入力と既知の出力がある素数性のような関数で機能しますが、かなりの数のタスクがこのようなものです。これを使用して、自分の開発コードの欠陥と、比較パッケージの偶発的な問題の両方を見つけました。しかし、無限の入力空間を考えると、すべてをテストすることはできません。

正しさの証明については、別の素数の例があります。BLS75メソッドとECPPには、原始証明書の概念があります。基本的に、証明に役立つ値を見つけるための検索を行った後、既知の形式で出力できます。その後、検証者を作成するか、他の誰かにそれを作成してもらうことができます。これらは作成と比較して非常に高速に実行され、（1）両方のコードが正しくない（検証者に他のプログラマを好む理由）か、（2）証明アイデアの背後にある数学が間違っているかのどちらかです。＃2は常に可能ですが、これらは通常、複数の人によって公開およびレビューされています（場合によっては、自分で簡単に確認できるほど簡単です）。

これに対して、AKS、APR-CL、試行分割、決定論的ラビン検定などのメソッドはすべて、「prime」または「composite」以外の出力を生成しません。後者の場合、検証できる要因がある可能性がありますが、前者の場合は、この1ビットの出力しか残されていません。プログラムは正常に機能しましたか？ダンノ

いくつかのおもちゃの例だけでソフトウェアをテストすることは重要です。また、アルゴリズムの各ステップでいくつかの例を見て、「この入力が与えられたら、この状態でここにいるのは理にかなっていますか？」

Fisher-Yates-Knuthシャッフリングアルゴリズムは（実用的な）例であり、このサイトの著者の1人がについてコメントしています。

このアルゴリズムは、指定された配列のランダム置換を次のように生成します。

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

シャッフルアルゴリズムが正しいかどうか（バイアスがあるかどうか）を検証する場合の主な問題は、統計のために、多数のサンプルが必要になることです。codinghorrorの記事私は上記のリンクは正確に（と実際のテストで）説明しています。

私が今まで見た中で最良の例（読んでください：私が最もお尻を痛めていること）は、collat​​z推測に関係しています。。問題は、2つの番号が同じ番号に達するために必要な最小ステップ数を見つけることでした。もちろん、解決策は、両方が前に見たものに到達するまで、それぞれを交互にステップすることです。数値の範囲（1〜1000000）が与えられ、collat​​z予想が2 ^ 64まで検証されたため、与えられた数値はすべて1に収束することを伝えました。32ビットを使用しましたただし、手順を実行する整数。1〜1000000のあいまいな数字（17万個）があり、32ビット整数がやがてオーバーフローすることがわかります。実際、これらの数字は2 ^ 31以下です。オーバーフローが発生していないことを「確認」するために、1000000をはるかに超える巨大な数値についてシステムをテストしました。オーバーフローの原因となるテストを行わなかっただけの、はるかに小さい数値が判明しました。「長い」の代わりに「int」を使用したため、賞金$ 500ではなく300ドルしか獲得できませんでした。

ナップザック0/1の問題は、ほぼすべての学生が貪欲なアルゴリズムによって解けると思い一つです。以前に貪欲なアルゴリズムが機能するナップザックの問題バージョンとしていくつかの貪欲なソリューションを示した場合、それはより頻繁に起こります。

これらの問題については、クラスで、疑いを取り除くためとナップザック0/1（動的計画法）の証明と貪欲な問題バージョンの証明を示す必要があります。実際、両方の証明は簡単ではなく、生徒たちはおそらく非常に役立つと思うでしょう。さらに、CLRS 3edの Chapter 16、ページ425-427にこれに関するコメントがあります。

問題： 泥棒は店を強奪し、ナップザックに最大重量のWを運ぶことができます。n個のアイテムがあり、i番目のアイテムの重量はwiであり、viドルの価値があります。泥棒はどのようなアイテムを取るべきですか？彼の利益を最大化するには？

ナップザック0/1の問題：セットアップは同じですが、アイテムは小さな断片に分割されない可能性があるため、泥棒はアイテムを取り出すか、そのままにするかを選択できます（バイナリ選択） 。

そして、貪欲なバージョンの問題と同じアイデアに従ういくつかのアイデアやアルゴリズムを学生から得ることができます：

• バッグの総容量を取得し、可能な限り最も価値のあるオブジェクトを配置し、バッグがいっぱいになるか、バッグに入れるための重量が等しいオブジェクトがなくなるため、オブジェクトを追加できないまでこのメソッドを繰り返します。
• 他の間違った方法は考えています：より軽いアイテムを置いて、これらを最高価格から最低価格まで置きます。
• ...

役に立ちましたか？実際、コインの問題はナップザックの問題バージョンであることがわかっています。しかし、ナップザックの問題の森にはもっと多くの例があります。例として、ナップザック2Dはどうですか（家具を作るために木を切りたいときは本当に役立ちます。私は地元の都市で見ました）。欲張りもここで動作しますが、動作しません。

よくある間違いは、シャッフルアルゴリズムを間違って実装することです。ウィキペディアの議論を参照してください。

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

標準ライブラリに統計関数を導入したPythons PEP450は興味深いかもしれません。著者のSteven D'Apranoは、Pythonの標準ライブラリで分散を計算する関数を持つことの正当化の一部として次のように書いています。

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

問題は、数値と精度が失われる方法に関するものです。最大の精度が必要な場合は、特定の方法で操作を注文する必要があります。単純な実装では、不正確さが大きすぎるため、誤った結果になります。それが、大学での数値コースの問題の1つでした。

これはおそらくあなたが望んでいることではありませんが、理解するのは確かに簡単であり、他の思考なしでいくつかの小さなケースをテストすると、誤ったアルゴリズムにつながります。

$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 ）実行時間が速い。