ObjectHandler and evaluationDate()
Locked
ObjectHandler and evaluationDate()
 
|
Re: ObjectHandler and evaluationDate()
|
|
Hi Toyin,
the excel wrapper of the YC object calls QuantLib::Settings::instance().setEvaluationDate(evaluationDate); before constructing the YC object (e.g. it is set globally for the whole library ....) Not quite fool-proof (you have to be carefull if you have multiple YC objects in your spreadsheet) hope this helps cheers, Plamen On Tuesday 02 August 2005 19:11, Toyin Akin wrote: > Hi, > > How does the Excel implementation of QuantLib+ObjectHandler handle > constructing YieldCurves with a referenceDate forward from Today? > > Let's say that the Yieldcurve object is constructed with a referenceDate, 3 > months from today. > This date will be stored within the YieldCurve object. > > If you then construct a swap object and then wish to price this, because > the code would access the evaluation date from evaluationDate() and not the > date passed in to the YieldCurve you would get a mixed fixing error. > > However the more I think about this the more it seems to me that the > reference Date variable passed in to the YieldCurve function is more tied > to the instrument themselves rather than the date that you want the curve > stripped at. > > Thus if you pass in a 3 month forward date into the Yieldcurve's > referenceDate function, you are specifying forward rates (ie - the 5Y swap > rate Tenor actually starts in 3 months time rather than today (or the spot > date)) and has nothing to do with the date that the YieldCurve is actually > stripped on. > > If my previous thought process is actually what is going on, It would be > nice to have a curve function that you specified up front as to what the > actual calculation date was and not depend on global variables. For > example, back testing strategies. > > Even if my previous analysis is correct, you still have the problem of > multiple users wanting to price a particular deal/product under difference > calculation dates. > > If the referenceDate parameter is tied to the instruments, what is the > ImpliedTermStructure Curve class used for? Does this actually implement a > different calculation/stripping date without going throught the > modifications of the evaluationDate() function? > If so, is this curve compatible with the wonderfully new > piecewiseYieldCurve Curve class? > > Sorry for the waffle, too many exciting Toys within the recent QuantLib > library...!! > > Best Regards, > Toy out. > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Quantlib-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-users |
attachment0 (189 bytes)
Re: ObjectHandler and evaluationDate()
|
|
Re: ObjectHandler and evaluationDate()
|
|
Hi Toyin,
> Thus if you have 2 YieldCurve objects (or more) within an Excel spreadsheet > with 2 different referenceDate (assuming the referenceDates controls the > evaluation date and not the dates in which the stripping tenors will > reference themselves from), you don't actually know what date is actually > set last. You don't really know what is the true global evaluationDate() correct > Thus the final evaluation date will all be dependant on Excel's calculation > order, which may be different based on how you construct your > spreadsheet...!!! yes > I wouldn't like to quote a 10 million notional swap price from such a > system mate!! me neither ;-) The underlying problem is the sigleton used to determine globally the eval date. There are some technical solutions which could solve this problem, but i think they are currently out of scope. > In your opinion, is the reference date passed in to the YieldCurve > functions the new evaluation date > or the date that the YieldCurve instruments reference themselves from? > > I think the latter, which would mean you don't need the call the > setEvaluationDate() function, but them again, I haven't looked too closely > at the implementation. current semantic is that this is the _global_ evaluation date - e.g. from then on all of the YC instruments will take it as their ref date. Basically for the whole QL instance this will be then the new eval date - also for swaps, bonds, options and any other objects in this QL instance (and because of the observer implementation most of them will either recalculate or mark them self as not calculated (LazyObject)). > Thanks for the reply, but it looks like you can only build, in any one > Excel session, no matter how many spreadsheets you open, or construct, you > can only have ONE yieldCurve object floating around to ensure that the eval > date is valid (and that you know is valid). Well - if you like you can have multiple YC's but you have to ensure _all_ of them use the same evalDate..... cheers, Plamen |
Re: ObjectHandler and evaluationDate()
|
|
Re: ObjectHandler and evaluationDate()
|
|
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. 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 |
Re: ObjectHandler and evaluationDate()
|
|
Re: ObjectHandler and evaluationDate()
|
|
Re: ObjectHandler and evaluationDate()
|
|
Hi Toy,
> Actually, thinking about your theta point, it looks like you can compute > all three effects within a spreadsheet environment alone. > > Rates constant, discount factors constant and vol constant. > Each element above is it's own curve (fixing, discount, vol) and you bump > the evalDate of each one individually. > > What do you think? (leaving aside the global evalDate() problem) > > You Could even compute cross-derivatives under this scheme (Rates+Vols, > Rates+Dcfs etc...) cheers, Plamen |
Bug within the YieldCurve bunch of classes
|
|
| Free forum by Nabble | Edit this page |