多くのプロジェクトは、ゆっくりと行列演算を行う必要が生じ、最初にいくつかのベクトルクラスを構築し、機能を徐々に追加するという落とし穴に陥り、半ば評価されたカスタム線形代数ライブラリを構築し、それに依存するようになります。
接線方向に関連するライブラリ(OpenCV、OpenSceneGraphなど)に依存しないようにしながら、それを回避したいと思います。
一般的に使用されている行列数学/線形代数ライブラリとは何ですか?また、なぜ他のライブラリを使用することに決めますか?何らかの理由で使用しないことをお勧めしますか?私は特にこれを幾何学的/時間コンテキスト*(2,3,4 Dim)*で使用していますが、将来的にはより高次元のデータを使用する可能性があります。
API、速度、メモリ使用、幅/完全性、狭さ/特異性、拡張性、および/または成熟度/安定性のいずれかに関する違いを探しています。
私は非常に満足しているEigen3を使用することになりました。
このために Generic Graphics Toolkit に落ち着いたプロジェクトがかなりあります。そこにあるGMTLはニースです-非常に小さく、非常に機能的で、非常に信頼性が高いほど広く使用されています。 OpenSG、VRJuggler、およびその他のプロジェクトはすべて、独自の手動ロールマトリックス/マトリックス演算の代わりにこれを使用するように切り替えました。
とても素敵だと感じました-テンプレートを介してすべてを行うので、非常に柔軟で、非常に高速です。
編集:
コメントの議論と編集の後、私は特定の実装の利点と欠点、および状況を考慮して他の実装を選択する理由についてさらに情報を捨てると思いました。
GMTL -
利点:グラフィックエンジン専用に設計されたシンプルなAPI。他のパッケージにはない、レンダリングに向けた多くのプリミティブタイプ(プレーン、AABB、複数補間を行う四元数など)が含まれます。非常に低いメモリオーバーヘッド、非常に高速、使いやすい。
欠点:APIはレンダリングとグラフィックスに特に焦点を当てています。汎用(NxM)マトリックス、マトリックスの分解および解法などは含まれません。これらは、従来のグラフィックス/ジオメトリアプリケーションの領域外にあるためです。
固有 -
利点: Clean API 、非常に使いやすい。 Geometryモジュール にクォータニオンと幾何学的変換が含まれています。低メモリオーバーヘッド。完全、 高パフォーマンス 大きなNxN行列およびその他の汎用数学ルーチンの解法。
欠点:望んでいる(?)よりも少し大きいスコープになる可能性があります。 GMTLと比較した場合、幾何学的/レンダリング固有のルーチンが少なくなります(オイラー角の定義など)。
IMSL -
利点:非常に完全な数値ライブラリ。非常に、非常に高速です(おそらく最速のソルバー)。圧倒的に最大かつ完全な数学的API。商業的にサポートされ、成熟しており、安定しています。
欠点:コスト-安価ではありません。幾何学的/レンダリング固有のメソッドはほとんどないため、線形代数クラスの上に独自のメソッドをロールする必要があります。
NT2 -
利点:MATLABに慣れている場合により馴染みのある構文を提供します。大きな行列などの完全な分解と解決を提供します。
欠点:数学的で、レンダリングに焦点を合わせていません。おそらく、Eigenほど性能が劣っています。
LAPACK -
利点:非常に安定した実績のあるアルゴリズム。ずっと周りにいた。完全な行列解法など。あいまいな数学の多くのオプション。
欠点:場合によってはパフォーマンスが高くありません。 Fortranから移植されており、使用方法が変わっています。
個人的に、私にとっては、1つの質問に帰着します。これをどのように使用する予定ですか。レンダリングとグラフィックスだけに焦点を合わせている場合、 Generic Graphics Toolkit が好きです。これは、パフォーマンスがよく、独自の実装を行わなくてもすぐに使える多くの便利なレンダリング操作をサポートするためです。汎用の行列解法(つまり、SVDまたは大きな行列のLU分解)が必要な場合は、 Eigen を使用します。大規模なマトリックスソリューションで非常に高性能です。独自のグラフィックス/幾何学的操作(マトリックス/ベクトルの上に)をもっと書く必要があるかもしれませんが、それは恐ろしいことではありません。
それが価値があるものとして、私はEigenとArmadilloの両方を試しました。以下は簡単な評価です。
固有の利点:1.完全に自己完結型-外部BLASまたはLAPACKに依存しません。 2.適切なドキュメント。 3.意図的に高速ですが、私はテストしていません。
欠点:QRアルゴリズムは、Rマトリックスが上三角に埋め込まれた単一のマトリックスを返します。マトリックスの残りの部分がどこから来たのかわからず、Qマトリックスにアクセスできません。
Armadilloの利点:1.広範囲の分解およびその他の機能(QRを含む)。 2.合理的に高速(式テンプレートを使用)ですが、再び、私はそれを高次元にプッシュしていません。
短所:1.マトリックス分解については外部BLASおよび/またはLAPACKに依存します。 2.ドキュメントにIMHOがありません(LAPACKの詳細を含む、#defineステートメントの変更以外)。
自己完結型で簡単に使用できるオープンソースライブラリが利用可能であれば、素晴らしいでしょう。私はこの同じ問題に10年間遭遇しましたが、イライラします。ある時点で、私はCにGSLを使用し、C++ラッパーを作成しましたが、現代のC++では(特に式テンプレートの利点を使用して)21世紀にCを台無しにする必要はありません。ちょうど私のtuppencehapenny。
Intelプロセッサで高性能な行列/線形代数/最適化を探している場合は、IntelのMKLライブラリをご覧ください。
MKLは、実行時の高速パフォーマンスのために慎重に最適化されています。そのほとんどは、非常に成熟したBLAS/LAPACKフォートラン標準に基づいています。また、使用可能なコアの数に応じてパフォーマンスが向上します。利用可能なコアを備えたハンズフリースケーラビリティはコンピューティングの未来であり、マルチコアプロセッサをサポートしない新しいプロジェクトでは数学ライブラリを使用しません。
非常に簡単に言うと、次のものが含まれます。
欠点は、必要なルーチンによってはMKL APIが非常に複雑になる可能性があることです。また、高性能の画像処理操作向けのIPP(Integrated Performance Primitives)ライブラリを見ることができますが、それでも非常に広範です。
ポール
CenterSpace Software、.NET Mathライブラリ、centerspace.net
Eigen および NT2 について良いことを聞いたことがありますが、個人的にも使用していません。 Boost.UBLAS もあります。これは歯が少し長くなっていると思います。 NT2の開発者は、次のバージョンをBoostに組み込むことを意図して次のバージョンを構築しています。
私の林。藻ニーズは4x4マトリックスの場合を超えて拡張されないため、高度な機能についてはコメントできません。私はいくつかのオプションを指摘しています。
GLM についてはどうですか?
OpenGL Shading Language(GLSL)仕様に基づいており、MITライセンスでリリースされています。明らかにグラフィックプログラマー向け
Eigenへの投票を追加します:さまざまなライブラリから多くのコード(3Dジオメトリ、線形代数、微分方程式)をこのライブラリに移植しました。ほとんどすべてのケースでパフォーマンスとコードの読みやすさの両方が向上しています。
言及されていない利点の1つは、SSEをEigenで使用するのが非常に簡単なことです。これにより、2D-3D操作(すべてを128ビットにパディングできる)のパフォーマンスが大幅に向上します。
さて、私はあなたが探しているものを知っていると思います。 Reed Copseyが提案したように、GGTはかなり良いソリューションであるように見えます。
個人的に、私たちは合理的なポイントをたくさん扱っているので、私たち自身の小さなライブラリをロールしました-多くの合理的なNURBSとベジエ。
ほとんどの3Dグラフィックスライブラリは、射影数学の基礎を持たない射影点を使用して計算を行うことがわかります。最終的にGrassmannポイントを使用しましたが、これは強固な理論的基盤を持ち、ポイントタイプの数を減らしました。グラスマンポイントは基本的に、人々が現在使用しているのと同じ計算であり、堅牢な理論の利点があります。最も重要なことは、それによって物事がより明確になり、バグが少なくなることです。 Ron Goldmanは、コンピュータグラフィックスのGrassmannポイントに関する 「コンピュータグラフィックスの代数的および幾何学的基礎」 と呼ばれる論文を書きました。
あなたの質問に直接関係するものではなく、興味深い読み物です。
このライブラリは非常にシンプルで機能的であることがわかりました( http://kirillsprograms.com/top_Vectors.php )。これらは、C++テンプレートを介して実装されたベアボーンベクトルです。派手なものはありません-ベクトルを使用して行う必要があること(加算、減算、ドットなど)だけです。