http://quantlib.414.s1.nabble.com/ObjectHandler-and-evaluationDate-tp3963p3969.html
Actually, thinking about your theta point, it looks like you can compute all
>From: Plamen Neykov <
[hidden email]>
>To: "Toyin Akin" <
[hidden email]>
>CC:
[hidden email]
>Subject: Re: [Quantlib-users] ObjectHandler and evaluationDate()
>Date: Wed, 3 Aug 2005 13:59:12 +0200
>
>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
><< attach3 >>