Re: ObjectHandler and evaluationDate()

Posted by Plamen Neykov on
URL: http://quantlib.414.s1.nabble.com/ObjectHandler-and-evaluationDate-tp3963p3968.html

Hi Toyin,

> If it is true that the global_ evaluation date is set when the
> referenceDate is set within the
> YieldCurve constructor, why doesn't the YieldCurve constructor itself
> update the global evaluation
> date? Why do you have to do a seperate step (setEvalDate() before calling
> the constructor?
Well - we could provide a separate function to set the eval date - but this is
even more problematic because it will increase the dependency to the order in
which cells are calculated ....

> Calling the constructor alone with what you believe are the correct
> parameters to a YieildCurve
> object that will be stripped using a forwarddate alone will result in an
> invalid YieldCurve object (if the referenceDate entered is different from
> that of the current system date.). Because the global evalDate() and the
> date entered into the YielCurve object has to be the same.
Not completely true - you can build a curve with a ref date after the eval
date e.g. using S/N as your first grid point so the curve ref date will be
eval + X spot days. You are right in the case when you are using O/N as your
first point - there the ref date has to be equal to eval (in this case you
need also T/N)

> Take note here, your system clock has to be the same as the date you
> entered into the YieldCurve object constructor (if you do not call the
> evalDate() global function), otherwise you will result in invalid results.
> That I find worrying, try stripping a curve when the system clock is on a
> weekend, doesn't work!!!
Well striuctly speaking in the current impl of QuantLibAddin this is not true
- the system clock has no influence what is the eval date - it is question of
the user specifying it.

> Traders all the time estimate their Theta by simply moving the
> EvaluationDate by one day (or more) and recomputing their trades.
Well - this is acompletely different discussion - I don't think it is so easy
to estimate Theta (or for the sake of argument cost of carry) as by just
moving the eval date by one day. A systematic solution should provide a
correct roll-forward capabilities for all types of trades - for example
fixing calculation or execution of options.

> You could get even sexier, if the trader wanted the theta only due to the
> YieldCurve evalDate movement and not the volcurve evalDate movement. And
> Vice versa, because each object would have their own eval date property
> (YieldCurve object can have a different evalDate than that of the VolCurve
> object).
you have to be carefull here because of the vol-smile - you have to fix the
df's and vols and move only the forwards, then fix the forwards and the vols
and move df's and finaly move vols while keeping df and fwd const .... (it
can be even more complicated than that) - but the main point is that this
cannot be done easily only by using excel - you have to have a supporting
infrastructure in the library it self.

> Also (there's more!!!), the volCurve objects are unaffected by the global
> evaluation date object (if you use the constructor that uses the
> ReferenceDate parameter) as all the dates used internally are relative to
> the passed in referenceDate. Thus changing the global evalution date may
> mean that you acquire a different discount factor or fixing, but you obtain
> the same volatility value!!!
you still can ensure in excel that they shre the same eval date as the YC
object and thus the global eval date.

> Why not go with the volatility objects way of life, the evalDate is local
> to the object, self-contained as in the constructor sets up the object
> correctly without any other external calls to ensure that the object is
> valid, and you can have more than one (with different evalDates) floating
> around the system?
Well - this is a bigger change in QuantLib so I presume that the project
manager should decide on taking this in development.

> The YieldCurve Object which strips from market rates almost has the same
> functionality as the VolCurve object. I agree with you Plamen, the
> referenceDate ought to really be the new evaluationDate(), where this logic
> falls down is within the rateHelper classes. Here they just take the global
> evalDate() value. Thus constructing an inconsistent object if the
> referenceDate is not set properly.
ref date has to be consistent with eval but not necessarily the same ;-)

> Also from my quick seach of the code, whenever there is a call to
> evaluationDate(), there is either a YieldCurve or an InterestRate object in
> the same scope. In terms of the Coupon classes, this is via the Xibor
> object, thus it doesn't look like any new parameters needs to be passed in
> any function.
This seems really prommising... But again this alone wouldn't solve your theta
problem .... (I'll be also happy to see a bigger discussion how is the best
way this to be implemented - might be via some sort of environment object
passed to every constructor?)

> One other thought that, I could be wrong here, is that setting the global
> eval to the same value as the refenceDate could be incorrect. This is
> because one use of the global eval value is to test for missed fixings for
> floating rate coupons. Now if you use the constructor that does not take
> ReferenceDates, but rather the fixingDays, it computes the referenceDate as
> today (Let's assume a Monday) advanced by the number of fixing days (let's
> say 2 days, thus we land on a Wednesday).
> So assume we now use the other YieldCurve object constructor with the
> referenceDate set to Wednesday and internally in the Excel+Objecthandler
> code, you update this global eval value.
>
> Thus constructor #1 (via fixingDays) and constructor #2 (via referenceDate)
> will each result in the same ReferenceDate for the YieldCurve object
> (Wednesday), but different global evaluationDate values.
>
> Now when this global eval value is acquired by the FloatingRate coupon set
> of classes they need to determine if a fixing can be computed.
>
>    Rates are fixed 'FixingDays', before the start of the coupon period, so
> let's say that we have a Coupon that has a start date of Thursday, one day
> after the ReferenceDate. This will be fixed on Tuesday. Constructor #1 will
> happily compute the rate, whereas construtor #2 will report a missed
> fixing. This is because under Constructor #2 you set the global eval to the
> referenceDate of the YieldCurve object (a wednesday), thus the fixing date
> (a Tuesday) is before this and thus will result in a missed fixing (needs
> to be looked up), when in effect, because Today is Monday, there isn't a
> missed fixing at all.
>
> Thus it would seem that constructor #1 is the way to go, the problem,
> cannot change the evaluation date locally.

Humm - it might be that I'm missing your point here - but:

1) the current QuantLibAddin implementation uses only the YC constructor which
takes the ref date as parameter.
2) ref date and eval date are taken as two different parameters by the
QuantLibAddin adaptor function - so the ref date and eval can be
different ...


cheers,
Plamen