私の答えの1つが引用されているので、MINPACKの代わりにIPOPTを使用することを提案した理由を明確にしようとします。
MINPACKを使用することに反対する私の意見は、MINPACKが使用するアルゴリズムとその実装に関係するすべてのこととは関係ありません。私の主な異議は、ソフトウェアが1980年にさかのぼり、1999年に最後に更新されたということです。ホルヘ・モレは引退しました。彼やソフトウェアの他の作者がそれを監視していることは疑わしく、積極的にサポートしているチームは存在しません。私がソフトウェアで見つけることができる唯一のドキュメントは、JorgeMoréと他のMINPACKの著者によって書かれた元の1980年のArgonneテクニカルレポートです。(1-3章はここにあり、4章はここにあります。)MINPACKソースコードを検索し、ドキュメントを熟読した後(PDFはスキャンされた画像であり、検索できません)、制約に対応するオプションが表示されません。非線形最小二乗問題の元のポスターは、制約付き非線形最小二乗問題を解決したかったため、MINPACKはその問題を解決することさえしません。
IPOPTメーリングリストを見ると、一部のユーザーは、非線形最小二乗(NLS)問題でのパッケージのパフォーマンスが、Levenberg-Marquardtアルゴリズムとより特化したNLSアルゴリズムに関連していることを示しています(こちら、こちら、およびこちらをご覧ください)。NLSアルゴリズムと比較したIPOPTのパフォーマンスは、もちろん問題に依存します。ユーザーからのフィードバックを考えると、IPOPTはNLSアルゴリズムに比べて妥当な推奨事項のようです。
ただし、NLSアルゴリズムを調査する必要があることを指摘します。同意する。MINPACKよりも最新のパッケージを使用する必要があると思うのは、パフォーマンスが向上し、使いやすく、サポートされると信じているからです。Ceresは興味深い候補パッケージのように見えますが、現在は制約のある問題を処理できません。TAO古典的なLevenberg-Marquardtを実装せず、代わりに微分のないアルゴリズムを実装しますが、ボックス制約付き最小二乗問題で動作します。派生物のないアルゴリズムは、おそらく大規模な問題にはうまく機能しますが、小規模な問題には使用しません。ソフトウェアエンジニアリングに大きな信頼を寄せる他のパッケージは見つかりませんでした。たとえば、GALAHADは一見、バージョン管理や自動テストを使用していないようです。MINPACKはこれらのことも実行していないようです。MINPACKの経験がある場合、またはより優れたソフトウェアに関する推奨事項がある場合は、私はすべて耳にします。
これらすべてを念頭に置いて、私のコメントの引用に戻ります。
方程式系はいずれも最適化問題に相当します。そのため、最適化におけるニュートンベースの方法は、非線形方程式システムを解くためのニュートンベースの方法によく似ています。
より良いコメントは、おそらく次の効果をもたらすものです。
n個の未知数g (x )= 0を持つn 方程式系を解きたい場合、これを最小二乗最適化問題として定式化できます。(Dmitri Bertsekasによる非線形計画法、第2版のp.102の最後の段落のフレーズ。)nng(x )= 0
このステートメントは、制約下で方程式系を解く場合にも当てはまります。変数に制約がある場合の「方程式ソルバー」と見なされるアルゴリズムは知りません。私が知っている一般的なアプローチは、おそらく数学期の最適化コースと最適化ラボでの研究に起因するもので、方程式系の制約を最適化定式化に組み込むことです。方程式を解くためにニュートンラプソンのようなスキームで制約を使用しようとすると、おそらく制約付き最適化で使用される方法と同様に、投影勾配法または投影信頼領域法になります。