以下のクラスで非常に優れた実世界のアルゴリズムが存在しますか？[閉まっている]

昨夜、私は別のプログラマーと話し合っていましたが、何かがO（1）であっても、O（1）アルゴリズムに大きな定数がある場合、O（n）の操作はそれを上回る可能性があります。彼は同意しなかったので、ここに持ってきました。

その下のクラスのアルゴリズムを大幅に上回るアルゴリズムの例はありますか？たとえば、O（n）がO（1）より速いか、O（n ²）がO（n）より速いです。

数学的には、定数因子を無視すると、漸近的上限を持つ関数でこれを実証できますが、そのようなアルゴリズムは野生に存在しますか？そして、それらの例はどこにありますか？どのような状況に使用されますか？

非常に小さい固定データテーブルのルックアップ。最適化されたハッシュテーブルは、O（1）である可能性がありますが、ハッシュ計算のコストのために、バイナリ検索や線形検索よりも遅くなる場合があります。

行列の乗算。ナイーブO（n ^ 3）アルゴリズムは、実際には、小さな行列の場合、StrassenのO（n ^ 2.8）よりも高速であることがよくあります。O（n ^ 2.3）Coppersmith–Winogradアルゴリズムの代わりにStrassenを使用して、より大きな行列を作成します。

簡単な例は、さまざまなソートアルゴリズムの違いです。Mergesort、Heapsort、およびその他のいくつかはO（n log n）です。クイックソートはO（n ^ 2）最悪の場合です。しかし、多くの場合Quicksortはより高速であり、実際にはO（n log n）のように平均して実行されます。詳細情報。

別の例は、単一のフィボナッチ数の生成です。反復アルゴリズムはO（n）ですが、マトリックスベースのアルゴリズムはO（log n）です。それでも、最初の数千のフィボナッチ数については、反復アルゴリズムはおそらくより高速です。これはもちろん実装にも依存します！

漸近的なパフォーマンスが向上したアルゴリズムには、パフォーマンスは低下しますが、操作が単純なアルゴリズムでは必要のない高価な操作が含まれる場合があります。最後に、O表記は、処理対象の引数が劇的に増加する（無限に近づく）場合にのみパフォーマンスに関する情報を提供します。

注：以下の@ back2dosと他の達人によるコメントを読んでください。実際に書いたものよりも役立つので、すべての貢献者に感謝します。

下のチャート（ビッグO表記、「アルゴリズムの悲観的な性質：」を検索）から、O（log n）がO（n）よりも常に優れているとは限らないことがわかります。だから、あなたの議論は有効だと思う。

の実用的な値についてはn、はい。これは、CS理論でよく取り上げられます。多くの場合、技術的にbig-Ohのパフォーマンスが優れた複雑なアルゴリズムがありますが、定数係数は非常に大きいため、実用的ではありません。

私はかつて計算幾何学の教授に、線形時間でポリゴンを三角測量するアルゴリズムを説明してもらいましたが、彼は「非常に複雑です。実際に誰もそれを実装していないと思います」（!!）

また、フィボナッチヒープは、通常のヒープよりも優れた特性を持っている、しかし、彼らは同様に行いませんので、非常に人気がありません実際には、通常のヒープとして。これは、ヒープを使用する他のアルゴリズムにカスケードできます。たとえば、ダイクストラの最短パスはフィボナッチヒープを使用すると数学的に高速になりますが、実際にはそうではありません。

リンクリストへの挿入とサイズ変更可能な配列への挿入を比較してください。

リンクリストO（1）を挿入する価値があるためには、データの量がかなり大きくなければなりません。

リンクリストには、次のポインターと逆参照のための余分なオーバーヘッドがあります。サイズ変更可能な配列は、データをコピーする必要があります。そのコピーはO（n）ですが、実際には非常に高速です。

Big-Oh表記は、関数の成長率を記述するために使用されるため、O（1）アルゴリズムがより高速になる可能性がありますが、特定のポイント（定数係数）までです。

一般的な表記法：

O（1）-繰り返しの回数（関数によってユーザー時間が費やされることもあります）は、入力のサイズに依存せず、実際には一定です。

O（N） -反復数はで成長線形入力の大きさに比例。意味-アルゴリズムが任意の入力N、2 * N回を反復する場合、O（n）と見なされます。

O（n ^ 2）（2次）-反復回数は入力サイズの2乗です。

通常、正規表現ライブラリは、の複雑さを持つDFA生成ではなく、最悪の場合の指数関数的な時間を持つバックトラッキングを行うために実装されますO(nm)。

素朴なバックトラッキングは、入力が高速パス上にとどまるか、過度にバックトラックする必要なく失敗する場合に、より優れたパフォーマンスを発揮できます。

（この決定はパフォーマンスに基づいているだけではありませんが、後方参照も許可しています。）

O(1)アルゴリズム：

def constant_time_algorithm
  one_million = 1000 * 1000
  sleep(one_million) # seconds
end

O(n)アルゴリズム：

def linear_time_algorithm(n)
  sleep(n) # seconds
end

明らかに、任意の値に対して、実施例で与えられたアルゴリズムは、あろう速くよりアルゴリズム。nn < one_millionO(n)O(1)

この例は少し面倒ですが、精神的には次の例と同等です。

def constant_time_algorithm
  do_a_truckload_of_work_that_takes_forever_and_a_day
end

def linear_time_algorithm(n)
  i = 0
  while i < n
    i += 1
    do_a_minute_amount_of_work_that_takes_nanoseconds
  end
end

式の定数と係数を知っておく必要があり、どのアルゴリズムがより高速になるかを事前に決定するために、の予想される範囲を知る必要がOあります。n

そうしないと、あなたはしなければならないベンチマークの値を持つ2つのアルゴリズムnの順序で予想の範囲内で決定するために事後速いことになったアルゴリズム。

並べ替え：

挿入ソートはO（n ^ 2）ですが、少数の要素に対して他のO（n * log（n））ソートアルゴリズムよりも優れています。

これが、ほとんどのソート実装が2つのアルゴリズムの組み合わせを使用する理由です。たとえば、マージソートを使用して、特定のサイズの配列に達するまで大きな配列を分解し、挿入ソートを使用して小さな単位をソートし、マージソートで再度マージします。

この手法を使用するPythonおよびJava 7のソートの現在のデフォルト実装であるTimsortを参照してください。

統一実際に使用されるアルゴリズムは、いくつかの病理学的な入力のために、最悪の場合には指数関数的です。

多項式統合アルゴリズムがありますが、実際には遅すぎます。

メモリ内のバブルソートは、プログラムがディスクにスワップされている場合、または比較するときにディスクからすべてのアイテムを読み取る必要がある場合、クイックソートよりも優れています。

これは彼が関係できる例のはずです。

多くの場合、より高度なアルゴリズムは、ある程度の（高価な）セットアップを前提としています。一度だけ実行する必要がある場合は、ブルートフォースメソッドを使用することをお勧めします。

たとえば、バイナリ検索とハッシュテーブルルックアップはどちらもリニアサーチよりもルックアップごとにはるかに高速ですが、それぞれリストをソートするかハッシュテーブルを作成する必要があります。

ソートにはN log（N）のコストがかかり、ハッシュテーブルには少なくともNのコストがかかります。これで、数百または数千のルックアップを行う場合、それはまだ償却された節約になります。ただし、1つまたは2つのルックアップのみを行う必要がある場合は、線形検索を実行して起動コストを節約するだけの意味があります。

多くの場合、復号化は0（1）です。たとえば、DESのキースペースは2 ^ 56であるため、メッセージの復号化は一定時間の操作です。そこに2 ^ 56の係数があるので、本当に大きな定数です。

セットのさまざまな実装が思い浮かびます。最もナイーブの一つは、手段、ベクトルの上に実装されているremoveだけでなく、containsしたがって、またadd、すべてのテイクO（N）。
別の方法は、入力ハッシュを入力値にマッピングする汎用ハッシュを介して実装することです。このようなセット実装はadd、containsおよびのO（1）で実行されますremove。

Nが約10程度であると仮定すると、最初の実装はおそらくより高速です。要素を見つけるために必要なことは、10個の値を1個と比較することだけです。
他の実装では、あらゆる種類の巧妙な変換を開始する必要があります。これは、10回の比較を行うよりもはるかに高価になる可能性があります。すべてのオーバーヘッドがあるため、キャッシュミスが発生する可能性がありますが、ソリューションの理論上の速さは実際には関係ありません。

これは、Nが十分に小さい場合、考えられる最悪の実装が適切な実装よりも優れていることを意味するものではありません。これは、十分に小さいNを意味します。フットプリントとオーバーヘッドが少ない素朴な実装では、拡張性を優先する実装よりも実際に命令が少なく、キャッシュミスが少ないため、高速になります。

現実世界のシナリオで何かをどれだけ速くするかは、実際にそれを入れて単純に測定するまでわかりません。多くの場合、結果は驚くべきものです（少なくとも私には）。

はい、適切に小さいNの場合。常にNがあり、それを超えると常に順序O（1）<O（lg N）<O（N）<O（N log N）<O（N ^ c ）<O（c ^ N）（ここでO（1）<O（lg N）は、Nが適切に大きく、cが1より大きい固定定数である場合、O（1）アルゴリズムで実行される操作が少なくなることを意味します）。

特定のO（1）アルゴリズムが正確にf（N）= 10 ^ 100（googol）操作を行い、O（N）アルゴリズムが正確にg（N）= 2 N + 5操作を行うとします。O（N）アルゴリズムは、Nがほぼグーグルになるまで（実際にはN>（10 ^ 100-5）/ 2になるまで）パフォーマンスが向上します。 O（1）アルゴリズムを使用すると、大きなペナルティが発生します。

または、現実的な比較のために、n桁の数字を乗算するとします。カラツバアルゴリズムはながら（約O（N ^ 1.585である））は、最も3 N ^（LG 3）操作であるSchönhage-StrassenのアルゴリズムがあるO（NログNログログN）で高速順が、引用しますウィキペディア：

実際には、シェーンハーゲストラッセンアルゴリズムは、2 ^ 2 ^ 15から2 ^ 2 ^ 17（10,000から40,000桁）を超える数のKaratsubaやToom-Cook乗算などの古い方法よりも優れています。[4] [5] [6 ]

したがって、500桁の数字を一緒に乗算する場合、大きなO引数により「高速」なアルゴリズムを使用することは意味がありません。

編集：f（N）/ g（N）の制限N->無限大を取ることにより、g（N）と比較してf（N）を決定できます。制限が0の場合はf（N）<g（N）、制限が無限の場合はf（N）> g（N）、制限が他の定数の場合はf（N）〜g（N）大きなO表記の観点から。

線形計画法のシンプレックス法は、最悪の場合は指数関数になる可能性がありますが、比較的新しい内点アルゴリズムは多項式になる可能性があります。

ただし、実際には、シンプレックス法の指数関数的な最悪のケースは発生しません。シンプレックス法は高速で信頼性が高く、初期の内点アルゴリズムは非常に遅すぎて競争力がありません。（現在、競争力のある最新の内点アルゴリズムがありますが、シンプレックス法もあります...）

サフィックスの試行を作成するためのUkkonenのアルゴリズムはO（n log n）です。「オンライン」であるという利点があります-つまり、より多くのテキストを追加できます。

最近、他のより複雑なアルゴリズムは実際には高速であると主張しています。これは主に、メモリアクセスの局所性が高いため、プロセッサキャッシュの使用率が向上し、CPUパイプラインのストールが回避されるためです。たとえば、処理時間の70〜80％がメモリの待機に費やされていると主張するこの調査と、「wotd」アルゴリズムについて説明するこのペーパーを参照してください。

接尾辞の試行は、遺伝学（遺伝子配列のマッチング）で重要であり、多少重要ではありませんが、スクラブル辞書の実装でも重要です。

明確に定義された問題には、常に最速で最短のアルゴリズムがあります。ただし、純粋に理論的には（漸近的に）最速のアルゴリズムにすぎません。

問題のいずれかの記述を考えるとPとその問題のインスタンスI、それはすべての可能なアルゴリズムを列挙AとプルーフのPrをするかどうか、そのような各ペアをチェックし、Prは、有効な証拠であるAは、のために漸近的に最速のアルゴリズムであるP。そのような証明を見つけると、Iに対してAを実行します。

この問題のないペアの検索には、複雑なO（1）（固定された問題Pの場合）があるため、常に問題に対して漸近的に速いアルゴリズムを使用します。ただし、この定数はほとんどすべての場合で非常に大きいため、この方法は実際にはまったく役に立ちません。

多くの言語/フレームワークでは、KMPの代わりに単純なパターンマッチングを使用して文字列を照合します。ababaabababababaabababababababではなく、Tom、New Yorkのようなストリングを探します。