10

私は ublas::Compressed Matrix を使用して、スパース線形ソルバーである UMFPACK を操作しています。私はシミュレーションを行っているため、係数行列の拡大/縮小といくつかの疎行列の乗算が含まれる可能性がある線形システムがわずかに異なる方法で構築されるたびに。線形システムの規模は約 25k です。

Boost が UMFPACK で動作するためのバインディング パッチがあっても、マトリックスを時々変更する必要があります。行列を初期化するときのゼロ以外の値)。また、ublas::range を使用して列/行を動的に追加します。

私の質問は次のとおりです。これを行う効率的な方法はありますか? 今のところ、私には遅すぎます。15k のような次元の行列を転置すると、ほぼ 6 秒かかり、約 12k 行を追加するのは高速ですが (これは行優先の行列だと思います)、行列に同じ数の列を追加すると、最大 20 秒かかります (同じだと思います)。そのため、列優先の行列を使用しても、必要な合計時間は同じになります)。

ここでちょっと必死になっています。どんな提案でも大歓迎です。

乾杯。

4

4 に答える 4

1

私はあなたのパッケージに精通していませんが、なぜ (理想的には) マトリックス内のゼロ以外の要素の数を指定する必要があるのですか? 指定しすぎてサイズを小さくすることはできませんか?

また、列の追加にそれほどの費用がかかる理由についても混乱しています。スパース形式はそれを処理できるはずです。2つのうちの1つが起こっていると結論付けます。あなたの行列は、元に戻す前にどういうわけか非疎行列に変換されているか（適切な疎行列パッケージでは恐ろしく、不可能に思えます）、または値を繰り返し挿入し、それぞれ他のすべてをシフトするため、挿入用のコードは二次です。時間。

後者の可能性が高いようです。現在のスパース行列を取得し、さらにエントリがいくつあるかを把握し、より大きなブロックを割り当て、順番にコピーして、新しい列を挿入する独自の「列の挿入」コードをロールしようとします。これは線形であり、基本的に瞬時に行われるべきです。それが問題全体を解決するのに十分かどうかはわかりませんが、それが出発点になるはずです。

さらに、マトリックスに 25k エントリのオーダーがある場合、コピーまたは転置に数ミリ秒以上かかる理由について、合理的な答えはありません。列を追加するための上記の解決策が問題を解決しない限り、この問題の個々の部分をベンチマークし、時間がどこに行くのかを正確に判断する必要があると思います。

于 2010-12-18T13:51:47.000 に答える
0

いくつかの異なる値のセットを結合して A を構築するのではなく、それらを別々の行列に保持し、既存のソルバー ルーチンを使用して独自の全体的なソルバーを構築することを検討しましたか? 基本的に、適切な分解 (LU、QR など) を 1 つのコンポーネント マトリックスに適用し、後続のコンポーネントに対して対応する更新/変換を実行し、後続のマトリックスごとに繰り返します。次に、因数分解された成分行列を使用して解を計算します。ただし、使用しているライブラリがこれを直接サポートするかどうか、または数値ルーチンの一部またはすべてを自分で作成する必要があるかどうかは明らかではありません。

于 2011-05-21T06:32:40.757 に答える
0

この種の問題にEigenを試しましたか？最近、疎行列のサポートが完了しました。

于 2012-03-21T08:11:44.153 に答える
0

毎回マトリックスをどのように構築しますか、ある種の異なるソフトウェアからインターフェースしていますか。この場合、インターフェースに費やされる時間はかなり少ないと思います。

そして、uBlas には -DNDEBUG フラグを使用しますね。

何が問題なのかはまだわかりません...

ベスト、ウムト

于 2010-12-10T15:45:36.573 に答える