標準の線形代数/最適化法には大きすぎるものは何ですか？

異なる数値線形代数および数値最適化手法は、独自のプロパティに加えて、それらが「良いアイデア」である場合に異なるサイズ体制を持っています。たとえば、非常に大規模な最適化問題の場合、ヘッセ行列を扱う必要がないため、ニュートン法や内点法の代わりに勾配法、確率勾配法、座標降下法が使用されます。同様に、密な線形ソルバーメソッドは、特定のサイズになると実行できなくなります。

したがって、アルゴリズムとコンピューターハードウェアの両方が絶えず変化していることを考えると、標準の線形代数と最適化ソルバーにとってどれほどの大きさであるかを知るにはどうすればよいでしょうか。

（数値アルゴリズムのエンドユーザーである場合、それらのアルゴリズムを適用できるときはあいまいな考えを持つことが重要であるため、これについて考えています。その一部は、問題の構造と望ましいソリューションの種類ですが、一部は問題の大きさでもあります。）

編集：より具体的に言えば、これについて私が考えさせられたのは、問題の内点アルゴリズムが解決できる大きさの上限に関するさまざまな経験則でした。以前の論文では、次元数は約1000である必要があると述べていましたが、後の論文では5000に上方修正されており、最近の論文では、スパース性を利用できるかどうかに応じてさらに大きな値を認めています。これはかなり広い範囲なので、最先端の内点法では何が大きいのか知りたいです。

スパース性が維持され、最適な前提条件が利用可能であり、不等式制約がマルチスケール法で解決できる場合（またはアクティブな制約の数が多すぎない場合）、全体的なアルゴリズムは時間と空間になります。並列マシンに分散すると、時間に対数項が追加されます。十分なスパース性が利用可能である場合、または行列なしの方法が使用されている場合、コアあたり100万程度の自由度を解決できます。これにより、今日の最大のマシンの問題サイズは約1兆自由度になります。いくつかのグループがこの規模でPDEシミュレーションを実行しています。$\mathcal O(n)$

大規模な設計空間でニュートンベースの最適化を使用することは依然として可能であることに注意してください。単にヘッセ行列で反復的に解く必要があります。これを効率的に行うには多くのアプローチがあります。

したがって、それはすべて「標準メソッド」の定義方法に依存します。定義にマルチレベルの構造保存メソッドが含まれている場合、非常に大きな問題が扱いやすくなります。定義が非構造化密手法に限定されている場合、アルゴリズムは時間または空間のいずれにおいても「スケーラブル」ではないため、実行可能な問題のサイズははるかに小さくなります。

制限は主に、行列表現を格納するために必要なメモリと、メモリから取得するための時間によって与えられます。

これにより、単純な環境での密行列法の数千が限界になります。疎な問題の場合、直接ソルバーの制限ははるかに高くなりますが、フィルインを調整する必要があるため、スパースパターンに依存します。線形ソルバーの反復法の制限は、行列ベクトル乗算のコストに不可欠です。

線形サブ問題を解くための制限は、方程式の非線形システムと最適化問題のローカルソルバーの対応する制限に直接変換されます。

グローバルソルバーには、ブランチアンドバウンドフレームワークで解決する必要のあるサブ問題の数、または確率的探索法の次元の呪いによって制限されるため、はるかに厳しい制限があります。

与えられたクラスの問題について、「大きすぎる」とはどの程度の大きさであるかを理解する良い方法は、

• あなたの分野の文献を検索してください。実行時間を制限する要因を理解する（これらには、メモリ使用量と通信が含まれます）
• テスト問題セットを見てください（並列化アルゴリズムの多くのテスト問題セットを知らないため、並列化アルゴリズムよりもシリアルアルゴリズムの方が優れています）
• アルゴリズムをより小さな構成要素に分解し、その部分について知っていることを使用して全体について推論します（例：クリロフ部分空間法は、行列とベクトルの積のループに要約されるため、反復回数を把握する必要があります「多すぎる」であり、行列とベクトルの積が「大きすぎる」理由
• 自分で試してみてください（シリアルマシン、またはリソースがある場合はパラレルマシン）。実行できるインスタンスの大きさ、または異なるサイズの複数のインスタンスを実行して、経験的なスケーリング分析（時間と問題のサイズ）を行います。

たとえば、グローバル最適化では、具体的な答えは非常に構造に依存します。Arnold Neumaierが指摘しているように、決定論的グローバル最適化アルゴリズムは、分岐限定（または分岐限定）フレームワークで解決する必要がある副問題の数によって制限される傾向があります。私は何千ものバイナリ変数を含む混合整数線形プログラム（MILP）を解きましたが、このような大きな問題（比較的言えばMILPの場合）を解くことができる理由は、問題構造が解くために必要なサブ問題がほとんどないためであると思います一部の重要なバイナリ変数のセット、および残りはゼロに設定できます。私の問題は「大きい」ことを知っています。同じようなサイズの他のMILPを作成して、数万倍の速度でゆっくりと解決しました。

「ありふれた」ものについてのアイデアを与えるグローバルな最適化テストセットがあり、文献は「大きな」問題についてのアイデアを与えることができます。他の分野の最新の問題サイズを把握するための同様の戦術が存在します。これは、Jed BrownとArnold Neumaierがこれらの数値を引用できる方法です。これらの数値を取得することは素晴らしいことですが、時が来たら自分でそれらを取得する方法を理解できるようになる方がはるかに価値があります。