Posted by
Toyin Akin on
URL: http://quantlib.414.s1.nabble.com/ObjectHandler-and-evaluationDate-tp3963p3972.html
Hi Plamen,
Ahhhhhhh,
I didn't realise that you provided 2 different date inputs to your Excel's
YieldCurve call. I was just going along the assumption that you simply
delegated to QuantLib's YieldCurve function (thus only passed in the
ReferenceDate and used it for the global evalDate() function also). I like
that idea a lot and believe that this is how the QuantLib YieldCurve
constructor should be modelled, you specify the Eval date and the reference
date at the same time (am I correct on this is how you do it within the
Excel version?)
However you still have the global eval() date problem.
As for the Theta, Traders use it as a quick approximate way during the
pricing of a Trade, especially a structured trade where you may have some
exotic legs involved and you may have some parts that use other external
Excel addins or custom calculations on the spreadsheet that generate price
only. There would be no way of computing an estimation of the theorectical
theta unless you started bumping parameters and computing differences.
You are correct, there are many definitions of Theta and you could even
break down the components of theta to the part coming from the vol, the
rates, the discount factors etc...
Do you re-strip, do you simply acquire the discounts from another part of
the curve etc...
Even if you wanted to be a purist about it and wanted to compute just 2
effects on your structured deal. One for the theta movement on the discount
factors alone and one for the forward rates used by the pricing object. You
could do this by providing 2 curves, a fixing curve and a discount curve.
QuantLib has a nice model for this as the YieldCurve attached to the Xibor
object is used for Fixing rates and you provide another (or the same curve)
for discount factors.
Normally you would generate 2 curves, one curve would have a spread on it.
Thus to compute the effect of theta for the discount factors only you would
bump the evalDate for the discount curve, but because you want the forwards
to remain the same, you do not bump the date on the reset curve. Under
quantLib today, both would be bumped (global evalDate), no matter what
environment you are in Excel, C++ etc... Same vice versa.
As for the 2 YieldCurve constructurs, you managed to taylor your environment
to the use of only one of the constructors. If you use quantLib direct, you
get the scenario I described in terms of missed fixings.
My dislike of the evalDate() function is really from a QuantLib library
standpoint and not really how the Excel version is implemented. Basically
you have to code your Excel environment in such a way as to not generate an
inconsistent environment. Problem is, you may still be able to do that
because if you pass in the evalDate() to the Yieldcurve function, thus
changing the global date, but use another function which does not depend on
this YieldCurve object at all, you have to be pretty sure that the algorithm
does not depend on the evalDate(). Unless you want it to use the same
evalDate(). The other function doesn't even have to be another YieldCurve
object, just any which refers to the global evalDate() within the QuantLib
code.
If you don't want the same date, how do you go about resetting this?
I believe that the QuantLib library is the best library for would-be
financial analysts to learn from as well as seasoned professionals. There's
nothing like is out there that is free. Very clean code and very solid.
Hell I even rewote it in C# a few years ago. (www.capetools.net will be back
up in a few weeks time with a new version, which is actually a C# wrapper on
top of the latest QuantLib library instead of a rewrite.)
I give it a 11/10 (!), however there must be people out there that are
actually implementing this within their systems. From a multi-threaded point
of view, it would be interesting to see how others have overcome this global
evalDate() issue.
Whinning over...!!!
Toy out.
>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 >>