非線形最小二乗フィッティングに pygsl の multifit_nlin モジュールを使用しています。pygsl は、C 数値ライブラリ gsl の python バインディングです。私が経験している問題は、pygsl または gsl に関連しているようには見えませんが、このコンテキストでのみ発生します。
関数のパラメーターをいくつかのデータに当てはめています。パラメータ フィッティングに pygsl を使用するには、関数とその jacobian を定義する必要があります。次に、multifit_nlin のフィッター lmsder は、フィッティング プロセスで必要に応じて、これら 2 つの関数を呼び出します。ヤコビアンを呼び出すと、数値の行列が生成されます。この行列を画面に出力すると、数値が正しいことがわかります。次に、lmsder クラスを定義し、lmsder.set コマンドで初期化します。lmsder.getJ() コマンドを使用してヤコビアン行列を画面に出力すると、以前と同じ数値が表示されます。もちろん、これは私のコードでやりたいことではありませんが、説明とデバッグのみを目的としています。
jacobian と lmsder.getJ() の出力間の一致は、 lmsder.getJ() が jacobian 関数によって生成されたメモリ内の jacobian 行列にアクセスするため、予想されるものです。ただし、コード行を挿入する場合は、次のように print 'bob" (またはその他) とします。
system = gsl_multifit_function_fdf(...) # jacobian is passed here
solver = lmsder(...) # system is passed here
solver.set(...) # first call to jacobian is in here
print "bob"
print solver.getJ()
ここで ... は適切な引数を意味します。次に、print solver.getJ() は、下位の行がランダムなコンテンツで満たされたヤコビ行列の転置である行列を出力します。繰り返しになりますが、これは set() 呼び出しと getJ() 呼び出しの間に余分なコード行がある場合にのみ発生します。
コードを正常に実行すると、つまり、フィッティング プロセス全体を実行すると、コードはエラーなしで動作します。ヤコビ行列が実際に getJ() コマンドが示すものである場合、例外が発生する可能性のある場所がかなりあります。したがって、コードが機能することは確かです。また、パラメーターに対して取得した値が妥当であるためです。
私はまた、pygsl が gsl の c ライブラリーに至る一連の呼び出しを追跡しました。この問題を引き起こすものは何もありません。また、gsl は古くから存在しており、マトリックスを表示するような単純なものは何年も前に修正されていたでしょう。
この問題の原因について何か提案はありますか? ガベージ コレクター、インポート ステートメントの順序が正しくない、マルチコア? メモリ リークやガベージ コレクション プロセスをチェックするには、どのツールを使用できますか?
ありがとう、アレクサンダー