「定数を無視する」という一般的なコンピュータサイエンスの使用は、古典的なコンピューティングと量子コンピューティングを比較するときに役立ちますか？

ダニエル・サンクはコメントで、多項式時間アルゴリズムを認める問題の10 8の一定の高速化はわずかであるという（私の）意見に答えて言及しました。$10^8$

複雑さの理論は、無限のサイズのスケーリング制限に取りつかれすぎています。実際の生活で重要なのは、問題の答えをどれだけ早く得るかです。

コンピュータサイエンスでは、アルゴリズムの定数を無視するのが一般的であり、全体として、これはかなりうまくいくことが判明しています。（私はそこに、意味ある良いと実用的なアルゴリズムは。私はあなたが私が（理論上の）アルゴリズムの研究者は、この中でかなり大きな手を持っていた与えることを願っています！）

しかし、これは現在とは少し異なる状況であることを理解しています。

1. 同じコンピューターで実行されている2つのアルゴリズムを比較するのではなく、2つのまったく異なるコンピューターで2つの（わずかに）異なるアルゴリズムを比較します。
2. 現在、量子コンピューターを使用していますが、従来のパフォーマンス測定では不十分な場合があります。

特に、アルゴリズム分析の方法は単なる方法です。根本的に新しいコンピューティング手法では、現在のパフォーマンス評価手法を批判的にレビューする必要があると思います！

だから、私の質問は：

量子コンピューターのアルゴリズムのパフォーマンスと古典的なコンピューターのアルゴリズムのパフォーマンスを比較する場合、定数を「無視」するのは良い習慣ですか？

「定数を無視する」という一般的なコンピューターサイエンスの使用法は、さまざまな種類のハードウェアアーキテクチャまたはソフトウェアのパフォーマンスの違いを少しのマッサージで無視できる場合にのみ役立ちます。しかし、古典的な計算であっても、難しい問題や大きな問題を解決したい場合は、アーキテクチャの影響（キャッシュ動作、ハードディスクの使用）に注意することが重要です。

定数を無視する慣行は、実装の観点から動機付けられた慣行ではありません（継続的に肯定されるという意味で）。それは主に、純粋な数学に近い方法で、構成の下でうまく動作し、単純な特性化を認めるアルゴリズムの研究へのアプローチへの関心によって駆動されます。チューリングマシンの高速化定理は、賢明な理論に到達するために、賢明な定義が問題の複雑さをあまりにも正確に突き止めることができないことを意味しました。さらに、困難な問題に適したアルゴリズムを見つけるのに苦労した中で、一定の要因は数学的に興味深い部分ではありませんでした...

アルゴリズムの研究に対するこのより抽象的なアプローチは、実り多いものでした。しかし、今、計算の2つのモデルがある状況に直面しています。

• 1つは、技術的な成熟度（古典的な計算）の高度な状態です。そして
• 1つは非常に未熟な状態ですが、大幅な漸近的改善（量子計算）につながる可能性のある理論モデルを実現しようとしています。

この場合、一定の要因を慎重に考慮して、または考慮せずに、漸近的利益を考慮することが理にかなっているかどうかを尋ねることができます。スケーラブルな量子コンピューティングを実行するために必要な余分な労力のため、量子アルゴリズムを実現する際のオーバーヘッドをすべて考慮に入れると、スカラー係数だけでなく、理論的性能の多項式「スピードアップ」が洗い流される可能性があります。

これらの初期の時代には、量子アーキテクチャへのさまざまなアプローチに対するパフォーマンスにも大きな違いがあるかもしれません。これにより、フォンノイマンマシンまたは高度に分散されたネットワークで従来の計算を行うかどうかに関係なく、アルゴリズムが漸近解析よりもどれだけうまく機能するかについて、アーキテクチャの選択が重要になります。かなりの遅延があります。

実際の計算で実際に重要なことは、これまでずっと、アルゴリズムだけでなく、アルゴリズムの実装、つまり特定のアーキテクチャで特定の方法で実現されるアルゴリズムです。一定の要因を無視する漸近解析の一般的な実践により、アルゴリズムのパフォーマンスの違いの体系的で数学的理由に注意を払うことができ、実際のパフォーマンスを支配するほどアーキテクチャの違いが大きくない場合に実際に動機付けられます。

量子テクノロジーに関しては、実際の状況で一定の要因を安全に把握できる幸福な状況ではありません。しかし、おそらくいつかそうすることができるでしょう。これは、量子情報技術の長いゲームです。量子情報技術に関する限り、これまで、学術コンピュータ科学者がプレイしたほぼ唯一のゲームです。量子テクノロジーがその基盤を見つける日を予想して、量子アルゴリズムのパフォーマンスの調査の1つの行として、漸近解析を追求し続けることは良いことです。

$O\left(f\left[N\right]\right)$$N$

$10^{10}$

$\approx300$

量子計算と古典的な計算を比較するとき、定数因子を無視することはできません。大きすぎます。

たとえば、昨年発表したスライドの画像を次に示します。

下にあるものは魔法の状態の工場です。フットプリントは15万物理キュービットです。ANDゲートは0.6ミリ秒で150Kキュビットを使用するため、量子ANDゲートの時空体積は90キュビット秒程度であると推測されます。

同僚の目標の1つは、エラー修正を実行するときに100キュビットあたり1 CPUを使用することです。したがって、90キュビットの秒には0.9 cpu秒の作業が必要と言えます。上記のイメージが作成されて以来、量子構造が数倍効率的になったため、代わりに0.1 cpu秒と呼びます。

（これらの推定値には多くの仮定があります。どのようなアーキテクチャ、エラー率など。私は一桁のアイデアを伝えようとしています。）

64ビット加算を実行するには、63個のANDゲートが必要です。63 * 0.1 cpu秒〜= 6 cpu秒。量子的には、64ビットの追加には1秒以上のCPUがかかります。古典的に、64ビットの追加はCPUナノ秒よりも安価です。ここでは、100億という一定の要因差が簡単にあります。GPUなどの並列の古典的なマシンと比較すると、数値はさらに悪化します。桁数が多い定数係数は無視できません。

たとえば、Groverのアルゴリズムを考えます。N個の評価ではなく、関数のsqrt（N）評価で関数への満足のいく入力を検索できます。100億の定数係数を加算し、量子コンピューターが必要とする評価が少なくなる場所を解きます。

Groverのアルゴリズムは評価を並列化することができず、評価には少なくとも1つのANDゲートが必要です。したがって、基本的には、検索に数千万年かかっている場合にのみCPU時間のメリットが見られます。

一定の要因を大幅に改善しない限り、Grover検索を使用して有用なものを探す人はいません。現在、量子対古典的な状況は、指数関数的優位性またはバストです。

他の答えは良い点を提供しますが、私はまだ少し意見が違うと感じています。それで、この点に関する私自身の考えを共有します。

要するに、一定の「現状のまま」を紹介することは、せいぜい無駄な機会だと思います。おそらく今のところ入手できる最高のものですが、理想とはほど遠いものです。

しかし、最初に、短い遠足はネセカリーだと思います。

効果的なアルゴリズムはいつありますか？

$10^6$

1. $P$
2. $P^2$$P$
3. $P^2$

$P^2$$P$$P$$P^2$

したがって、ごみのアルゴリズムが偶然「奇跡的な」高速化を持っているように見えるかもしれないことは不合理ではありません。今、もちろん、リスクを軽減できる多くの実験設計手法がありますが、おそらく多くの場合に失敗するより賢い「高速」アルゴリズムですが、十分な例では不十分です！（また、悪意のある研究者はいないと想定していることに注意してください。

そこで、「パフォーマンスメトリックが改善されたら目を覚ます」と答えます。

では、どうすればより良い結果が得られるでしょうか？

すべてのケースで「ブラックボックス」アルゴリズムをテストする余裕がある場合、上記にだまされることはありません。ただし、これは実際の状況では不可能です。（これは理論モデルで行うことができます！）

私たちがすることができません代わりにすることは、統計作成することであるという仮説いくつかのためのパラメータ、我々のような仮説我々を取得し、nullを拒否することは合理的と思われるまで、おそらく再び我々の仮説とテストを適応させる、これをテストする（通常、入力サイズ用）を実行している時間を。（私が無視している他の要因が関与している可能性があることに注意してください。私は実質的に数学者です。実験計画は私の専門知識の範囲内ではありません）

$O(n^3)$

それでは、定数をどうするか？

$10^9$すごい、スピードアップを！」このケースを処理するのは悪い方法です。しかし、この結果を完全に無視することも悪いことだと思います。

好奇心定数を異常と見なすことは最も有用だと思います。つまり、それ自体がさらなる調査を必要とする主張です。これを行うには、単に「アルゴリズムにX時間かかる」よりも一般的なモデルに基づいて仮説を作成するのが良いと思います。そのため、ここでCSの規則を単純に引き継ぐことはできないと思いますが、定数に対する「軽da」を完全に無視することも悪い考えです。