実装方法について概観します。簡潔にする為、CallableBondクラス自体の説明は飛ばします。すべきでしたが、その名前もすぐに古臭くなるでしょうから、ここでは短いクラス名を使う事をお許し下さい。resultsクラスについて説明します。フォルダーの中を探してみてください。{};さて、エンジンの部分に入っていきましょう。この商品の(離散的な)価格過程を記述する為に、DiscretizedAssetクラスを使う必要があります。(訳注:価格計算に必要なデータリストを、それぞれ取りこむのでは無く、それをひとまとめにしたクラスを使ってコードを簡略化)。これによって、少なくとも3か所で、計算に必要なデータのリストをいちいちプログラムコードで書き上げる必要が無くなります。DiscretizedAssetクラスのインスタンスを生成する際のプログラムコードです。コンストラクターに引数として渡されます。これらのデータは、債券のキャッシュフロー発生日などを、現時点からの年数に換算するプログラムで使われます。(この年数に換算するプログラムコードはやや冗長で、おそらく何らかの抽象化が可能である事を示唆しています。converter”のような名前のオブジェクトを作ったとしても、ややあいまいです。いいアイデアがあれば教え下さい。前からずっと気になっていた事ですから)次に来るのが、DiscretizedAssetクラスで宣言されたインターフェースの実装です。)メソッドは、債券の償還日、利払い日、コールオプション日を集めて、その中からすでに過去となった日を取り除いた配列を返します。債券価格の配列のサイズを調整し、各要素に償還額を設定し、さらに必要な調整を行います。この調整が、このクラスの動作の中で興味深い部分です。このクラスは特定の商品に特化している為、他のクラスと合体して何かをすることは、ほぼありません。)で行われるかは、大きな問題ではありません。(訳注:オプションと対象資産の関係のように、Nodeでの価値の決定が、対象資産のキャッシュフローイベントに影響を受ける場合、その調整を、オプション行使の前に行うか、後に行うかは、慎重に判断しなければなりません。post-adjustmentとしてマネージします。)メソッドを呼び出します。おいて、オプション行使するかしないかの判断をした後、債券の価値をセットします。その判断の論理は単純明快です。おいて、行使しなかった場合の債券価値と、行使した場合のプレミアムの推定値が与えられ、(コールオプションを持つ)発行体はこの2つの価値の低い方を選び、(プットオプションを持つ)債券保有者は高い方を選びます。Nodeの債券価値にクーポン額を加えるだけです。気が付かれたと思いますが、このクラスは、コール行使日と利払い日が同じ日に発生すると仮定しています。(その場合は、利払日にクーポン額が資産価格に足されて、その後で行使条件がチェックされます。[訳注:オプションが行使される場合、本来そのクーポン額は受け取れないはずですが、受取れるという前提でオプション行使の判断がなされてしまう])。Bondが存在するので)、きちんと考慮しておくべきです。(無理やり)調整して利払い日と同じ日に合わせています。別の少しましな方法は、まず、オプション行使により支払いの影響を受けるクーポン支払日を特定し、その場合、クーポン額を別の所に一旦コピーしておき、コール行使日まで遡及してコール行使の判断を行った後に、元のDiscretizedAssetの価格に戻すという操作を行えばいいでしょう。Stepの数、および3基準日と4日数計算方法(これは任意)を取り、それぞれメンバー変数に保存します。)メソッドがすべてです。データはすべて、Instrumentインスタンスによって設定済み、という前提です。それが提供できる特別なクラスに型変換して、取りだそうとします。仮に、それが出来なかった場合は、コンストラクターに任意変数として渡された価格計算基準日と日数計算方法を使います。その後、実際の計算が開始します。Latticeインスタンスを生成して返します。配列の中からその最大値を取りだして使う事も出来ます。<ライセンス表示>QuantLibのソースコードを使う場合は、ライセンス表示とDisclaimerの表示が義務付けられているので、添付します。