多くのプロジェクトでは、行列演算を行う必要性が徐々に生じ、最初にいくつかのベクトル クラスを構築し、機能を徐々に追加するという罠に陥り、中途半端なカスタム線形代数ライブラリを構築し、それに依存するようになります。
いくつかの接線関連のライブラリ (OpenCV、OpenSceneGraph など) に依存して構築するのではなく、それを避けたいと思います。
一般的に使用されている行列数学/線形代数ライブラリとは何ですか?なぜそれらを使用することに決めたのでしょうか? 何らかの理由で使用しないようにアドバイスされるものはありますか? 私はこれを特に幾何学的/時間的なコンテキスト*(2,3,4 Dim)*で使用していますが、将来的にはより高次元のデータを使用する可能性があります。
API、速度、メモリ使用量、広さ/完全性、狭さ/具体性、拡張性、および/または成熟度/安定性のいずれかに関する違いを探しています。
私は非常に満足しているEigen3を使用することになりました。
このためにGeneric Graphics Toolkitに落ち着いたプロジェクトがかなりあります。そこにある GMTL は素晴らしいです。非常に小さく、非常に機能的で、非常に信頼できるほど広く使用されています。OpenSG、VRJuggler、およびその他のプロジェクトはすべて、独自の手巻きバーター/マトリックス演算の代わりにこれを使用するように切り替えました。
テンプレートを介してすべてを行うため、非常に柔軟で非常に高速です。
編集：
コメントの議論と編集の後、特定の実装の利点と欠点、および状況に応じてどちらかを選択する理由について、さらに情報を提供したいと思いました。
GMTL -
利点: グラフィック エンジン用に特別に設計されたシンプルな API。他のどのパッケージにもない、レンダリング向けの多くのプリミティブ タイプ (プレーン、AABB、複数の補間を伴うクォーテリオンなど) が含まれています。非常に低いメモリ オーバーヘッド、非常に高速、使いやすい。
欠点: API は、特にレンダリングとグラフィックに重点を置いています。汎用 (NxM) 行列、行列の分解と解決などは含まれません。これらは従来のグラフィックス/ジオメトリ アプリケーションの領域外であるためです。
固有-
利点:きれいな APIで、かなり使いやすい。クォータニオンと幾何学的変換を備えたGeometry モジュールが含まれています。低メモリ オーバーヘッド。大規模な NxN 行列およびその他の汎用数学ルーチンの完全で高性能な解。
欠点: あなたが望んでいるよりも少し大きなスコープかもしれません (?)。GMTL と比較して、幾何学的/レンダリング固有のルーチンが少ない (例: オイラー角の定義など)。
IMSL -
利点: 非常に完全な数値ライブラリ。非常に高速です (おそらく最速のソルバー)。群を抜いて最大かつ最も完全な数学的 API。商業的にサポートされ、成熟しており、安定しています。
欠点: コスト - 安価ではありません。幾何学的/レンダリング固有のメソッドはほとんどないため、線形代数クラスの上に独自のメソッドを展開する必要があります。
NT2 -
利点: MATLAB に慣れている場合は、より使い慣れた構文が提供されます。大きな行列などの完全な分解と解法を提供します。
欠点: 数学的であり、レンダリングに焦点が当てられていません。おそらくEigenほどのパフォーマンスではありません。
ラパック-
利点: 非常に安定した実績のあるアルゴリズム。長い間存在しています。完全な行列の解法など。あいまいな数学のための多くのオプション。
欠点: 場合によっては、パフォーマンスがそれほど高くありません。Fortran から移植されたもので、使用方法が奇妙です。
個人的には、1 つの質問に行き着きます。これをどのように使用する予定ですか。レンダリングとグラフィックスだけに焦点を当てている場合は、 Generic Graphics Toolkitが好きです。これは、パフォーマンスが高く、独自の実装をしなくてもすぐに使用できる多くの便利なレンダリング操作をサポートするためです。汎用の行列解法 (つまり、大きな行列の SVD または LU 分解) が必要な場合は、Eigenを使用します。これは、それを処理し、いくつかの幾何学的操作を提供し、大きな行列解で非常にパフォーマンスが高いためです。独自のグラフィックス/幾何学的操作を (行列/ベクトルの上に) もっと書く必要があるかもしれませんが、それは恐ろしいことではありません。
だから私はかなり批判的な人間で、図書館に投資するつもりなら、自分が何に興味を持っているかを知っておくべきだと考えています. 精査するときは、批判を重視し、お世辞を軽視する方がよいと思います。何が間違っているかは、何が正しいかよりも将来に多くの意味を持ちます。だから私はここで少し船外に出て、私を助けたような答えを提供するつもりです. これは、これらのライブラリで行ったわずかなレビュー/テストに基づいていることに注意してください。ああ、私はリードから肯定的な説明の一部を盗みました.
Eigen2 の危険性があまりにも大きなマイナス面だったので、その特異性にもかかわらず、私は GMTL を使用したことを最初に述べておきます。しかし、私は最近、Eigen2 の次のリリースに、アラインメント コードを遮断して安全にする定義が含まれることを知りました。だから乗り換えるかも。
更新: Eigen3 に切り替えました。その特異性にもかかわらず、そのスコープとエレガンスは無視するのが難しすぎます。
利点: LGPL MPL2、クリーンでよく設計された API、かなり使いやすい。活気のあるコミュニティでよく維持されているようです。低メモリ オーバーヘッド。ハイパフォーマンス。一般的な線形代数用に作られていますが、優れた幾何学的機能も利用できます。すべてのヘッダー ライブラリ、リンクは不要です。
特異性/欠点: (これらの一部/すべては、現在の開発ブランチEigen3で利用可能ないくつかの定義によって回避できます)
利点: グラフィック エンジン用に特別に設計された LGPL (かなりシンプルな API)。他のどのパッケージにもない、レンダリング向けの多くのプリミティブ タイプ (平面、AABB、複数の補間を伴うクォーテリオンなど) が含まれています。非常に低いメモリ オーバーヘッド、非常に高速、使いやすい。すべてヘッダー ベースで、リンクは不要です。
特異性/欠点:
vec1 - vec2ません。たとえば、通常のベクトルを返さないため、length( vecA - vecB )機能しても失敗しますvecC = vecA -
vecB。次のようにラップする必要があります。length( Vec( vecA - vecB ) )
length( makeCross( vecA, vecB ) ) gmtl::length( gmtl::makeCross( vecA, vecB ) ) vecA.cross( vecB ).length()Web ページのコンテンツよりもフラクタル イメージ ヘッダーに関心があるように見えるため、わかりません。本格的なソフトウェア プロジェクトというよりも、アカデミック プロジェクトのように見えます。
2年以上前の最新リリース。
どうやら英語のドキュメントはないようですが、フランス語のどこかにあると思われます。
プロジェクトの周りにコミュニティの痕跡が見つかりません。
利点: 古くて成熟している。
欠点:
価値があるので、私はアイゲンとアルマジロの両方を試しました. 以下簡単な評価です。
Eigen の利点: 1. 完全に自己完結型 -- 外部の BLAS または LAPACK に依存しません。2. まともなドキュメント。3. テストはしていませんが、速いと言われています。
欠点: QR アルゴリズムは、R 行列が上の三角形に埋め込まれた単一の行列のみを返します。マトリックスの残りの部分がどこから来ているのかわからず、Q マトリックスにアクセスできません。
Armadillo の利点: 1. 幅広い分解およびその他の機能 (QR を含む)。2. 適度に高速 (式テンプレートを使用)。
短所: 1. マトリックス分解は、外部の BLAS や LAPACK に依存します。2. ドキュメンテーションには私見が欠けています (#define ステートメントの変更以外の、LAPACK に関する詳細を含む)。
自己完結型で簡単に使用できるオープン ソース ライブラリが利用できると便利です。私はこの同じ問題に10年間遭遇しており、イライラしています。ある時点で、私は C に GSL を使用し、その周りに C++ ラッパーを作成しましたが、最新の C++ を使用すると (特に式テンプレートの利点を利用して)、21 世紀に C をいじる必要はありません。ちょうど私のタペンハペニー。
Intel プロセッサ上で高性能の行列/線形代数/最適化を探しているなら、Intel の MKL ライブラリを検討します。
MKL は、実行時のパフォーマンスが高速になるように慎重に最適化されています。その多くは、非常に成熟した BLAS/LAPACK fortran 標準に基づいています。また、そのパフォーマンスは、利用可能なコアの数に応じて変化します。利用可能なコアを使用したハンズフリーのスケーラビリティはコンピューティングの未来であり、マルチコア プロセッサをサポートしない新しいプロジェクトには数学ライブラリを使用しません。
非常に簡単に言えば、次のものが含まれます。
欠点は、必要なルーチンによっては MKL API が非常に複雑になる可能性があることです。また、高性能の画像処理操作を対象とした IPP (Integrated Performance Primitives) ライブラリも参照できますが、それでも非常に広範です。
ポール
CenterSpace ソフトウェア、.NET Math ライブラリ、centerspace.net
GLMはどうですか？
OpenGL Shading Language (GLSL) 仕様に基づいており、MIT ライセンスの下でリリースされています。明らかにグラフィックプログラマー向け
EigenとNT2について良いことを聞いたことがありますが、個人的にはどちらも使用していません。また、 Boost.UBLASもあります。NT2 の開発者は、Boost に組み込むことを意図して次のバージョンを構築しているので、それは何かに役立つかもしれません。
私のリン。アルゴリズム 必要性は 4x4 マトリックスの場合を超えないので、高度な機能についてコメントすることはできません。いくつかのオプションを指摘しているだけです。
Eigen に投票を追加します: さまざまなライブラリから多くのコード (3D ジオメトリ、線形代数、微分方程式) をこのライブラリに移植しました。ほとんどの場合、パフォーマンスとコードの読みやすさの両方が向上しています。
言及されていない利点の 1 つは、Eigen で SSE を使用するのが非常に簡単であることです。これにより、2D-3D 操作のパフォーマンスが大幅に向上します (すべてを 128 ビットにパディングできます)。
わかりました、私はあなたが探しているものを知っていると思います。Reed Copsey が示唆したように、GGT は非常に優れたソリューションのようです。
個人的には、独自の小さなライブラリを作成しました。これは、有理数のポイント (多くの有理 NURBS とベジエ) を扱うためです。
ほとんどの 3D グラフィックス ライブラリは、射影演算の基礎を持たない射影点を使用して計算を行うことがわかりました。最終的にグラスマン ポイントを使用することになりました。これは、理論的にしっかりした基盤を持ち、ポイント タイプの数を減らしました。グラスマン ポイントは、基本的に、現在人々が使用している計算と同じであり、堅牢な理論の利点があります。最も重要なことは、頭の中で物事がより明確になるため、バグが少なくなるということです。Ron Goldman は、コンピューター グラフィックスにおけるグラスマン点に関する論文を書きました。 「コンピューター グラフィックスの代数的および幾何学的基礎について」と呼ばれます。
ご質問とは直接関係ありませんが、興味深く読ませていただきました。
このライブラリは非常にシンプルで機能的であることがわかりました ( http://kirillsprograms.com/top_Vectors.php )。これらは、C++ テンプレートを介して実装されたベアボーン ベクトルです。派手なことはありません-ベクトルで行う必要があることだけです（加算、減算、乗算、ドットなど）。