クラスの説明から始めたいと思います。Helperクラスに依存するので、説明は後にする)に依存していないからです(実際の所、このクラスは“モデルクラス”のインターフェースを全く使っていません)。BootstrapHelperクラスのそれと似通っています(クラス名そのものがヒントになりませんか?)。TermStructureモデルの中の個別のNodeと言ってもいいかもしれません)、その商品の価格を(価格)モデルに従って計算する機能と、その価格が“市場価格”からどのくらい離れているかをチェックする機能を提供しています。実際は、価格計算機能だけにとどまりませんが、その事については後で少しだけ触れます。(LazyObjectについては既に説明済でご存知かと思います)。したのは、このクラスは若干の事前計算を必要とする可能性があるという理由からです。Volatilityであるような場合です)。再計算を行えば十分です。意味は怠慢という意味ではなく、市場価格が変更になった場合に、すぐにそれに対応して再計算を起動させるのではなく、実際に価格計算が必要になった場合にのみそれを行うといった意味。市場価格が頻繁に変動しても、その都度価格を再計算すると、コンピューターシステムに対する負担が大きくなるため。コンストラクターは、3つの引数を取ります。それぞれ、やや汎用性の低い性質のパラメータですが(訳注:従って、ベースクラスではなく派生クラスで特定しても良かったかもしれない)、特に文句を言うほどでもありません。(訳注:ポインターへのポインター。Volatilityで呈示されているという前提です。これが計算の時に必ず必要になるという前提です。実際にその通りでしょうが、これは派生クラスでしか使われないので、このベースクラスではなく、私としては、他の計算に必要な引数とともに、派生クラスのコンストラクターで宣言する方が良かったかと思います。最後の引数は、Calibrationエラー(訳注:市場価格と価格モデルでの計算結果との差)をどのように設定するかを指定しています。Enumerationで指定された3種類の選択肢から選びます。Model)の拡散係数)との差の絶対値です。Patternを使うことも出来ましたが、それによる複雑化に対して、汎用性のメリットが上回るか確信がなく、enumで対応することにしました。少なくとも、この3つのケース以外にエラーをとらえる方法を思いつきませんでした。コンストラクターの実装内容は、簡潔にするため、ここでは示していません。実際にやっている事は、通常のコンストラクターの操作と同じで、引数を該当するメンバー変数に保存することと、(Observerである)自分自身を、値が変動する可能性のあるもの(Observable)へ登録する事です。述べたように、LazyObjectの仕組みは、市場価格に変動があった場合に(それを使ったメソッドが起動された時にのみ)機能します。レベルに変動があった場合にのみそれをオプション価格に変換して、それをメンバー変数に保持します。実際の計算アルゴリズムは、個別の商品によって異なります。)メソッドに委託されています。Volatilityの注釈参照)を使って計算されているはず、という前提です。)メソッドが、計算結果を返します。今説明したこの3つの(似たような目的を持つ)メソッドについては、すべて別個に必要となります。同じような機能のメソッドが3つあると、たしかに煩わしいと思います。)メソッドは、LazyObjectのインターフェースを利用するために不可欠です。?この2つを一緒にできなかったでしょうか?残念ながらNoです。)を呼ぶかたちにしなければなりません。)から呼び出される形なので、一緒にできないのです。引数として取っているため、インターフェースも異なっています。デフォールト値として与える事で、対応可能だったかもしれません。対象となる“価格モデル”を使った計算を司ります。)メソッドは、その商品の価格を‘価格モデル’に従って計算し、それを返します。)メソッドは、後でもっと詳しく説明しますが、市場価格とモデル価格との差を、何らかの形で返します。)は、引数として渡されたモデルのポインターをメンバー変数に取り込みます。Helperクラスが対応している商品の価格計算を行い、その計算結果を返します。Value)を計算します。実際のところ、各実装方法は非常に似通っているので、共通の実装をベースクラスで提供してもよかったかも知れません。)メソッドの実装方法は、おそらく次のようになったでしょう。最初の時点で、一度で済ませられたかも知れません。した場合のダウンサイドリスクは、メソッドの計算結果が、それが呼ばれた順番に依存していたかも知れないという事です。)メソッドが(本来意図していた自分の価格モデルではなく)Blackモデルによる価格を返してしまう可能性があります。マーフィーの法則によれば、うまく行ったとしても仕返しが付いてくる、ですね。)メソッドについての最後の注意点ですが、最初に私がそのコードを見たとき、バグがあるように見えました。(Observableになる)に登録すべきだと思いました。為だけに使われており、LazyObjectの仕組みを使って、市場価格の再計算に使われるべきではありません。最後の2つのメソッドは、Calibrationを行う際の補助機能を提供しています。)メソッドの逆関数の動作を行います。Volatility)を逆算するものです。5.1の後半の方にあります。ImpliedVolatilityHelperクラスの実装内容も書かれています。VIIで説明します)。インデックス確定日など)を加えます。Time-Gridのリストに追加の時間を加えた全リストを返すのではなく、追加の時間の部分だけを返すようにプログラムしたかもしれません。それは重要なポイントではありません。とって必要なものではありません。従って、派生クラスで実装しなくても良い場合にそなえて、空の実装を含めています。Helperクラスに移すつもりはありません。ひとつには、そうする事によって複雑さが増すもののアップサイドが無い事、もうひとつは、Helperクラスをそのように分類する事が出来ないというのが理由です。使われる可能性があるという事です。)メソッドの実装内容も示しています。このメソッドは、新しいパラメータに対するCalibrationの計算が行われる毎に呼び出され、価格モデルでの計算結果が市場価格からどの程度離れているかという誤差を返します。“どの程度離れているか”の定義は、enumerationのリストで提供されており、モデル価格と市場価格の相対価格、あるいは価格差の絶対値、あるいはVolatilityの差の絶対値のいずれかです。参照)を具体例として使います。Helperクラスの方の説明をします。CalibratedModelクラスの章で議論します。このクラスは‘ヨーロピアンオプション’をオブジェクトモデル化していますが、問題のにおいを感じます。Instrumentを扱っているか判別できません。Modelは含まれていません。このクラスがライブラリに加えられた際に、私も含めて、この問題をはっきり認識していませんでした。};いずれにしても、実装自体は複雑ではありません。その他の市場データを引数として取りこんでいます。引数の一部はベースクラスのコンストラクターに渡され、他の引数は自らのメンバー変数に保存されます。VanillaOptionクラスのインスタンスを生成し、その市場価格を計算します。VanillaOptionインスタンスと計算された市場価格もメンバー変数に保存されます。Optionインスタンスの生成方法に少し問題があります。本日から満期日までの期間として計算しています。残念ながら、このプログラムでは本日の日付が計算の途中で変わる可能性を考慮していません。Overrideしてその中で計算させるようにしなければなりません。その他の部分は単純です。PricingEngineを使っても作動するので、クラス名が気に入らない理由です)。Black-Scholesモデルを使ったオプション価格を返します。)メソッドを呼び出しても計算できます。)メソッドは何もしません。Hestonモデルは含まれていません。相当するでしょうが)他のモデルでも使えるようになるでしょう。HestonModelHelperクラスの説明は以上です。Calibrationに必要な計算機能を提供します。その部分の説明に行く前に、少し寄り道をします。Quoteされていなかったとすればどうなるでしょうか?その場合でも、プログラムは作動しますが、クラス名やメソッド名が意図したものと異なるため、プログラムコードを理解する妨げになるでしょう。)メソッドの中に実装せざるを得ず、頭がこんがらがってしまうかもしれません。)メソッドで呼び出そうとすると、次のような頭を混乱させるようなコードを実装する事になります。Compilerは気にしません)。やっても、プログラムコードを読む人間には、依然ややこしいものではありますが。<ライセンス表示>QuantLibのソースコードを使う場合は、ライセンス表示とDisclaimerの表示が義務付けられているので、添付します。