registerAsObserver
is left as a backdoor in case the programmer cannot guarantee that the object pointed to will remain alive for the whole lifetime of the handle—namely, it should be set to false
when the passed shared pointer does not own the pointee (this should only happen in a controlled environment, so that the programmer is aware of it). Failure to do so can very likely result in a program crash. If the programmer does want the handle to register as observer of such a shared pointer, it is his responsibility to ensure that the handle gets destroyed before the pointed object does. Settings::includeReferenceDateCashFlows()
is set to true
, payments occurring at the settlement date of the swap might be included in the NPV and therefore affect the fair-spread calculation. This might not be what you want. T
to Disposable<T>
is destructive, i.e., it does not preserve the state of the original object. Therefore, it is necessary for the developer to avoid code such as which would likely render the passed object unusable. The correct way to obtain the desired behavior would be: from
must be a later time than to
. from
must be a later time than to
. Objects cache the results of the previous calculation. Such results will be returned upon later invocations of calculate. When the results depend on arguments which could change between invocations, the lazy object must register itself as observer of such objects for the calculations to be performed again when they change.
Should this method be redefined in derived classes, LazyObject::calculate() should be called in the overriding method.
Should this method be redefined in derived classes, LazyObject::calculate() should be called in the overriding method.
registerAsObserver
. currently, this method returns the Black-Scholes implied volatility using analytic formulas for European options and a finite-difference method for American and Bermudan options. It will give unconsistent results if the pricing was performed with any other methods (such as jump-diffusion models.)
options with a gamma that changes sign (e.g., binary options) have values that are not monotonic in the volatility. In these cases, the calculation can fail and the result (if any) is almost meaningless. Another possible source of failure is to have a target value that is not attainable with any volatility, e.g., a target value lower than the intrinsic value in the case of American options.
Settings::includeReferenceDateCashFlows()
is set to true
, payments occurring at the settlement date of the swap might be included in the NPV and therefore affect the fair-rate and fair-spread calculation. This might not be what you want.