isExpired
Locked
 
|
Hi all
in revision 16174 (http://quantlib.svn.sourceforge.net/quantlib/?rev=16174&view=rev) I've revisited Instrument::isExpired implementation, which is now often using Event::hasOccurredFunction I noticed that in many cases the Instrument is considered to be expired if its last payment date is earlier than Settings::instance().evaluationDate(). Unless I miss something this approach is wrong. isExired if often used in order to bypass NPV evaluation setting it to zero, and as such it should rely on a PricingEngine and/or TermStructure::referenceDate() to verify expiration E.g. Bond::isExpired check the settlementDate() vs Settings::instance().evaluationDate(). This imply that if a bond trade with t+3 settlement it could be expired and still have cashflows to be discounted for an YieldTermStructure with t=0 as referenceDate If I'm right removing the default referenceDate from Event::hasOccurredFunction would show at compilation time most of the places where expiration is deduced from Settings::instance().evaluationDate() Any feedback? ciao -- Nando ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Thu, 2009-04-16 at 19:54 +0200, Ferdinando Ametrano wrote:
> > If there's no payment after the evaluation date, you can consider the > > instrument as expired. Unless your settlement date is _before_ the > > evaluation date, but that's nonsense, isn't it? > > Not really. I tried to price an expired (from the point of view of the > evaluation date) bond with an YieldTermStructure whose settlement date > was also before evaluation date, i.e. I would have liked not to care > about the evaluation date at all. So basically, you tried to discount to yesterday with the evaluation date set to today? > >> E.g. Bond::isExpired check the settlementDate() vs > >> Settings::instance().evaluationDate(). Oh, you mean "it checks the last cash flow against the settlement date, instead of checking it against the evaluation date". I though you meant "it compares the settlement date and the evaluation date". Agreed, it should check the evaluation date. Luigi -- To err is human -- to blame it on a computer is even more so. -- unknown ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Luigi
> So basically, you tried to discount to yesterday with the evaluation > date set to today? it is not nonsensical as (you try to make) it sounds, especially in a dynamic environment. I have a session on QuantLibXL with the evaluation date equal to today. I'm asked by the control office to justify a bond price valuation done about 2 months ago. I deserialize the xml files of that bond and its interest rate curve as they were at the time. The yield curve has fixed reference date. The bond clean price fails because of the evaluation date, and it should not since both bond and interest rate curve are coherent. To solve this issue I have to change evaluation date, disrupting my session, or just use a different dedicated session for the control office check. No big deal, but definitely not nice. >> >> E.g. Bond::isExpired check the settlementDate() vs >> >> Settings::instance().evaluationDate(). > > Oh, you mean "it checks the last cash flow against the settlement date, > instead of checking it against the evaluation date". I though you meant > "it compares the settlement date and the evaluation date". Agreed, it > should check the evaluation date. ok, now that at least we agree that it should check the evaluation date, let's try to move ahead one more step. It might check the yield term structure reference date if a pricing engine is set: wouldn't this be better? It would allow to price the bond in the above QuantLibXL example This is the key point you can observe in Revision 16180 (http://quantlib.svn.sourceforge.net/quantlib/?rev=16180&view=rev): isExpired sometime refers to the evaluation date, some other times to the term structure reference date. In my opinion the latter should be the correct, or at least preferred, behavior. While this can be probably patched locally (and I'm mainly interest in the Bond class right now), thinking along this line might lead to conclude that we should add the reference date in Instrument::results, i.e. the date at which value and error estimate have been evaluated. This would make the information set in Instrument::results "complete" and would allow for easy check/use of that reference date. Then the current evaluation date might then just become a fall-back case when the engine is not provided in order to calculate Bond::settlementDate and Bond::accruedAmount I look forward to feedback ciao -- Nando ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Nando,
sorry if I'll be short---I don't have much time and I will be gone in the afternoon. On Fri, 2009-04-17 at 11:31 +0200, Ferdinando Ametrano wrote: > > So basically, you tried to discount to yesterday with the evaluation > > date set to today? > > it is not nonsensical as (you try to make) it sounds, especially in a > dynamic environment. > I have a session on QuantLibXL with the evaluation date equal to > today. I'm asked by the control office to justify a bond price > valuation done about 2 months ago. I deserialize the xml files of that > bond and its interest rate curve as they were at the time. The yield > curve has fixed reference date. The bond clean price fails because of > the evaluation date, and it should not since both bond and interest > rate curve are coherent. I think the clean price should fail. It's true that, with a fixed reference date for the curve, you can calculate the NPV. But for the clean price you need to calculate the bond settlement date, and you can't retrieve that from the discount curve---you don't know if the reference date was t+0, t+2 or whatever. And in general, yes, it might be a pain to keep curves, instrument and evaluation date consistent. But otherwise, I'm not sure that the library can always determine when you want it to disregard the evaluation date that you set earlier in the session. I tend to think it dangerous when the code tries to double-guess the user. > ok, now that at least we agree that it should check the evaluation > date, let's try to move ahead one more step. It might check the yield > term structure reference date if a pricing engine is set: wouldn't > this be better? It would. But to retrieve the discount curve, you'll have to downcast the engine (not a big problem now, but there might be a few different engines in the future.) We'd be entering a quagmire of "it's a discounting engine? Ok, get the discount curve. It's not? It's a short-rate model engine? Ok, get the model, and get the risk-free curve from it. It's not? ..." > It would allow to price the bond in the above QuantLibXL example Again, not sure about that. NPV? Yes. Price? No. > This is the key point you can observe in Revision 16180 > (http://quantlib.svn.sourceforge.net/quantlib/?rev=16180&view=rev): > isExpired sometime refers to the evaluation date, some other times to > the term structure reference date. In my opinion the latter should be > the correct, or at least preferred, behavior. Same problem here. When it checks against the reference date, it's because we didn't move the instrument to the pricing-engine framework and we still have the discount curve available. We'll lose it if we move it into the engine. Also, it depends. If we're checking cash-flow dates, they should be checked against the curve reference date. If we're checking exercise dates, those should be checked against the evaluation date, shouldn't they? Later, Luigi -- The First Rule of Optimization: Don't do it. The Second Rule of Optimization (For experts only): Don't do it yet. -- Michael Jackson ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |