Posted by
Toyin Akin on
URL: http://quantlib.414.s1.nabble.com/ObjectHandler-and-evaluationDate-tp3963p3967.html
Hi Plamen,
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?
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.
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!!!
Traders all the time estimate their Theta by simply moving the
EvaluationDate by one day (or more) and recomputing their trades.
A system shouldn't provide a way from the Trader/Marketer to leave his
system in an invalid state (behind the scences) and continue as if the
correct evaluation date is being used.
What's wrong with associating the evaluationDate with the
YieldCurve/VolCurve/InterestRate object themselves? After all, all the
pricing instruments need a YieldCurve object to discount, acquire fixings
etc... The same can be said for the volatility objects.
That way, when a cap needs to be priced, the evaluationDate from the
YieldCurve can determine whether a mixed fixing is required, acquire
discount factors for the evaluationDate that has been set as well as acquire
volatility (from the vol object).
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).
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!!!
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?
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.
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.
Just an idea!!
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.
Thanks for the quick reply,
Best Regads,
Toy out.
>From: Plamen Neykov <
[hidden email]>
>To: "Toyin Akin" <
[hidden email]>
>CC:
[hidden email]
>Subject: Re: [Quantlib-users] ObjectHandler and evaluationDate()
>Date: Tue, 2 Aug 2005 21:16:34 +0200
>
>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
><< attach3 >>