Listingの例よりも)さらに多くの作業が実行されています。どちらかの端(あるいは両端)において、境界条件による制約をかけなければなりません。原資産価格に対する感応度。なるような条件をかけたいとします。polymorphism(実行時多相性)を取り入れています。bc_set(境界条件の集合を扱う型)が定義されていたのを覚えておられると思います)。その為に最も相応しいコンテナは、同じ性質を持った、従って共通のベースクラスを持ったものがいいという考えに基づくものでした。この理由は、完全に正確ではありません。使う事が出来たでしょう。使っていれば、長い目で見れば、フレームワークがより複雑になる事を避けられたと考えています。std::tupleを使う事も可能でしたが、そうしませんでした。標準化協議会においても、あまり役に立つテンプレートとはみなされていませんでした。metaプログラミングが必要となりますが、それは、どうしても必要な場合以外は、避けるべきと考えました)。このクラスのインターフェースは、やや奇妙な名前が付いています。)メソッドなどは、Libraryの中で最悪なメソッド名の有力候補です。そのような名前になったかと言うと、境界条件を‘適用する(applyする)’方法が、色々あるからです。)メソッドが実行されるまで待って、実行後に境界値を調整する方法です。Operator(差分演算子)と入力データの配列を準備しておき、計算結果が境界条件を満たすようにする方法です。)メソッドが、それに対応します。)メソッドは何等かの理由で、単に演算子を取り込む動作しか行っていません。既存の条件では配列の値を修正する必要が無かったために、見逃がされたのかもしれません。DirichletBCクラスを見てください。このクラスは、基本的なディリクレ境界条件を実装したものです。グリッドの端の関数値について、与えられた値をそのまま条件として設定するものです。};コードを見て判る通り、もはやクラステンプレートではありません。Operatorを具体的な型で特定しているからです。これは驚くことではありません。境界条件は演算子にどのようにアクセスし、それをどう修正するかを知る必要があるからです。このケースでは、既に説明した、三重対角演算子が指定されています。コンストラクターは、非常に単純です。引数として1境界値として設定する値と、2それがグリッドの‘どちら側の境界か’という情報を受け取り、それをメンバー変数に保存します。設定しなければなりません。する為、‘どちら側の境界か’の情報に従って、対応する単位行列の最初(あるいは最後)の行を設定します。対応する要素と同じ値になります。境界条件を満たしていれば、次のステップにおいても境界条件を満たすことになります。このロジックに依存するのは、若干危なっかしい点があります(例えば、時間の経過によって境界値が動くような場合や、何等かの事象の発生により配列の値を修正しなければならないような場合には、このロジックは崩れます)。この方法が入力データの配列にアクセスする事なく境界値を設定する最善の方法と言えるでしょう。)メソッドの方は、よりシンプルで安全です。境界値を、境界条件に従って設定するだけです。)と同じ様な動作をしますが、このメソッドは入力データの配列にもアクセスでき、その配列に正しいデータが入っているかどうかのチェックを行えます。)メソッドについてですが、驚くべき事に、今この説明文を書いている段階においてさえ、中味が空なのです。)も同時に呼び出されるであろうとの想定に頼っていたのかもしれません(訳注:applylAfterSolvingが何もしなくても、applyBeforeSolvingが必要な動作をやってくれていると想定していた)。後から見ればあまりいいアイデアでは無いと思います。Scheme(差分進化スキーム)を選択した場合、それが、どのメソッドを呼び出すのか判りません。)メソッドが、見た目よりもっと安全で無くなります。)メソッドの実装方法にあります。Solverを実行する前と後に、すべての境界条件が設定されます。)メソッドが起こしそうな問題を修正するように働きます。)が動作しなかったとしても、必要な動作を済ませている仕組みになっているからです。)の動作)は重複した動作という事になるでしょう。境界条件を計算の後にだけ設定するだけで十分でした。開発当時、おそらく、いくつかの境界条件は、そのすべてを実装する事が出来ないものと想定して、従って(訳注:beforeとafterを両方呼び出しておけば、どちらかが必要な動作を行ってくれるという)安全な選択肢を選んだのではないかと思います。}もし、Libraryの中のこの部分を修正するのであれば、(新しいフレームワークを導入したので、その必要はなさそうですが)この問題をきちんと見直すべきでしょう。残念ながら、解決すべき問題は、簡単ではありません。Evolutionスキームで必要とされ、かつ特定の境界条件にサポートされたメソッドだけを呼び出す為には、その両方について特定の型を知る必要があるからです。Evolutionスキームと境界条件の依存関係を逆転させ、Evolutionスキームを境界条件に渡すようなロジックは、うまく動作しないでしょう。)メソッドを呼び出すのか、知る術がありません。)のプログラムコードを見ればわかる通り、境界条件の設定は、陽的ステップの計算と陰的ステップの計算の間で実行されています)。Visitorパターンを使えばうまく行くかもしれませんが、プログラムコードはより複雑になります(境界条件の数が増えた場合は特にそうです)。仮にC++でマルチメソッドの方法が提供されていれば、それが最善の選択肢であったでしょうが、その場合でも複数の境界条件の設定が必要な場合は、使えなかったでしょう。総合的にみて、今のプログラムのようにすべてのメソッドを呼び出して動作させる方法は、重複した動作を行う可能性があるものの、少なくとも正しく動作します。)メソッドは不要になり取り除くことができます。境界条件の説明は以上で十分でしょう。まで計算する事が出来ます。その間何も起こらなければですが。残念ながら、そうならないケースが多くあり、次のセクションではそれについて説明します。<ライセンス表示>QuantLibのソースコードを使う場合は、ライセンス表示とDisclaimerの表示が義務付けられているので、添付します。