Missing parameters in DiscountCurve

[scchess]

The current implementation in DiscountCurve() only takes a very limited set of tsQuotes. For example, I'm not allowed to customize my FRA rates (other than 3x6, 6x9 and 6x12). Is this any reason for that?

[eddelbuettel]

Can you provide a working example in plain QuantLib and demonstrate that something works there, but not in RQuantLib?

In the past I found the curves to be numerically "finicky". We had to alter the parameters over the years with different versions of compilers, OS, QuantLib, ...

[scchess]

I think we're talking about different things. I'm simply not sure how I could make custom FRAHelper objects in RQuantLib.

I'm interested to bootstrap a set of FRAs. The rates don't come from the market, they're generated simply for my project. Let's take a very simple example. I tried to do something similar in RQuantLib but I was only allowed 3x6, 6x9 and 6x12 for my FRAs.

Settings::instance().evaluationDate() = Date(8, July, 1981);

boost::shared_ptr<SimpleQuote> r1(new SimpleQuote(0.0420));
boost::shared_ptr<SimpleQuote> r2(new SimpleQuote(0.0500));
boost::shared_ptr<SimpleQuote> r3(new SimpleQuote(0.0550));
boost::shared_ptr<SimpleQuote> r4(new SimpleQuote(0.0560));
boost::shared_ptr<SimpleQuote> r5(new SimpleQuote(0.0530));

RelinkableHandle<Quote> q1; q1.linkTo(r1);
RelinkableHandle<Quote> q2; q2.linkTo(r2);
RelinkableHandle<Quote> q3; q3.linkTo(r3);
RelinkableHandle<Quote> q4; q4.linkTo(r4);
RelinkableHandle<Quote> q5; q5.linkTo(r5);

static Integer fixing = 2;

boost::shared_ptr<RateHelper> fra0x1(new FraRateHelper(q1, 0, 1, fixing, calendar, Following, false, dc));
boost::shared_ptr<RateHelper> fra1x2(new FraRateHelper(q2, 1, 2, fixing, calendar, Following, false, dc));
boost::shared_ptr<RateHelper> fra2x3(new FraRateHelper(q3, 2, 3, fixing, calendar, Following, false, dc));
boost::shared_ptr<RateHelper> fra3x4(new FraRateHelper(q4, 3, 4, fixing, calendar, Following, false, dc));
boost::shared_ptr<RateHelper> fra4x5(new FraRateHelper(q5, 4, 5, fixing, calendar, Following, false, dc));

std::vector<boost::shared_ptr<RateHelper>> fras{ fra0x1, fra1x2, fra2x3, fra3x4, fra4x5 };

boost::shared_ptr<PiecewiseYieldCurve<Discount, LogLinear>> curve(
    new PiecewiseYieldCurve<Discount, LogLinear>(Date(8, July, 1981), fras, dc));

/*
 * The discount curve can now be converted into forward and zero curve.
 */

// Forward rates
curve->forwardRate(Date(8, August, 1981), Period(1, Months), dc, Continuous, Annual, false);

// Zero rates
curve->zeroRate(Date(8, December, 1981), dc, Continuous, Annual, false);

// Discount factors
curve->discounts();

[eddelbuettel]

I see. In that case we may need to generalise some code. I think there is something really old in there which has a few hard-coded. The whole curve code is more-or-less in need of help / redoing.

[scchess]

I can offer you help for that. I will make it so that I can create custom FRA, deposit helper objects just like in the C++ version. Then, I'll make it so that the tsQuotes parameter to DiscountCurve() takes those custom objects rather than just "3x6, 6x9 and 6x12". I'll give you a request when I'm done.

[eddelbuettel]

I'd say let's re-open this and keep discussing. I think under a 'four-eyes principle' we can make this code a lot better. I am at a workshop now so give me a few days. Interested in working on this jointly (or at least reviewing jointly) ?

[scchess]

Hi. I'm very interested in working with you. I'm a regular source contributor but having issues contributing to the C++ QuantLib because everything is there and stuffs not there are too advanced. I'm interested to make the RQuantLib library a little more useful. My interest will be in option pricing and anything relates to curves.

My thinking to the curve code is to expose the objects just exactly like how QuantLib does. We should be able to write simple wrappers around those helper objects.

We can have a deeper discussion when you have more time.

[eddelbuettel]

Sounds good. I have access to a Bloomberg at work to double-check some curve stuff, but I don't work with curves day-to-day. And yes, contributions would be great. I am a little busy the next few weeks but that shouldn't stop us. I think I may prefer some discussion/ideas prior to sending pull requests if that is ok with you.

[scchess]

I'm very pleased to discuss with you for my contribution. You can give me feedback for my works. This way, you'll receive contribution, I'll learn new things and everybody else can benefit from the changes. My plan is to extend the term-structure in RQuantLib. I've often found it hard to do modelling in C++ because compiling is slow and I can't see my curves visually. I'm thinking to introduce one-to-one mapping for the wrapper objects such as rate helpers. This will give me a feeling how exactly RQuanLib should work. What do you think? What do you have in mind?

[eddelbuettel]

That sounds good. We want a good balance between what QuantLib itself has (so "one-to-one" is desirable) with what R can (ie Date or Datetime objects for the curve indives). Let's take it one a time.

[scchess]

Hi,

I'm working on the project. I'm still very interested to push the QF project forward. I've setup a new quotes.R file. So far, it has a wrapper for FRARateHelper and DepositRateHelper. I prefer to name them as "FRAQuote" and "DepositQuote". This new design should allow more flexible yield-curve building.

discountCurveEngine() will unpack those new quote objects., something like:

d.quote = Rcpp::asQuantLib::Real(l[0]);

You might want to take a quick look at: https://github.com/student-t/rquantlib

I'll submit you a patch once I've finished the other stuffs. I'll make it happen!

[scchess]

I'll need to wrap Period. The Period class in QuantLib looks like this:

Period() : length(0), units(Days) {}

I can certainly ask a user to give me those arguments. While I'd want to generalize the curve code, I don't want to expose everything from QuantLib. It's a very deep learning curve if we do, we should keep it as simple as possible while still being useful.

I prefer to ask for a string representation for the period, such as "10d" rather than Period(10, Days). Our C++ code should parse the string pretty easily. What do you think?

[eddelbuettel]

post1: Thanks for the link. I will try to take a look, but time is tight...

post2: There are some patches in QL upstream to generalize to intra-day. Eventually we'll want that too. How to go from user to code is a little tricky. I defined some constants at the R level similar to the C++ enums. My instinct is that maybe we should keep mapping from "10d" to calling Period(10,Days) at the R level as this side code is brittle. To a first approximation, just use a vector of dates in calendar or business day offsets? These are just thoughts though.... good to first discuss.

[scchess]

It's fine if you don't have time. I can work out the implementation details myself.

I think it'll be a good idea to do it once and correct. If we should support intra-day, we should as well do it now. My QuantLib copy doesn't support intra-day, so I'll need to update it.

I'm not sure I understand "a vector of dates in calendar or business day offsets". Do you think you can elaborate a bit more?

[eddelbuettel]

Sorry: intra-day is not uet in QL proper, but is being talked about. There are patches. So "not yet" but we should keep it in mind.

I meant to say that instead of passing "10d 20d 1m 1m10d ..." which we would have to parse, send in a vector of floats (for fractional days) or ints: 10, 20, 31, 41, ...

QL already a bunch of conventions for daycounts. So I was just suggesting to keep it simple for now -- the parsing of date offsets may be an unnecessary detail.

And I just glanced at the diff between your version and mine and that looks pretty clean. May make sense to not have it drift apart too much....

[scchess]

Ok. I agree. I'll implement your idea.

[eddelbuettel]

:+1:

[scchess]

I've done the implementation. However, it'll be a large patch and I don't think it'll be accepted. I'll find a way to cut the patch into smaller pieces.