Hi,
We have some bonds that pay half-yearly coupons in February and August. These coupons are defined to be paid on 28 February and 31 August, regardless of whether it's a leap year or not. For example, in 2020, the coupon will pay on 28 February. Reference: http://www.treasury.gov.za/divisions/alm/2010/R213.pdf
At the moment the schedule generator can't handle this specific instance. As a workaround I generate a normal schedule with endOfMonth=true and then manually alter the schedule by looping through the generated dates and adjusting the 29 February entries.
If this is a common occurrence in other markets I'd like to enhance the Schedule constructor with a parameter to indicate that leap years should not pay out on 29 February. If this isn't common elsewhere, I'll stick to my workaround.
Your comments, please? thanks, Francois Botha
------------------------------------------------------------------------------ The best possible search technologies are now affordable for all companies. Download your FREE open source Enterprise Search Engine today! Our experts will assist you in its installation for $59/mo, no commitment. Test it for FREE on our Cloud platform anytime! http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
It seems bonds are boring. :) Luigi/other devs, do you have any objections to me adding such a parameter to force the schedule generator to ignore leap year days?
regards Francois Francois Botha
On 26 May 2014 14:38, Francois Botha <[hidden email]> wrote:
------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
I'm not sure. On the one hand Schedule has a lot of parameters
already, its constructor is a 300-lines monster, and if we add another flag we'd need to make sure that we cover all the 2^N combinations, so I wouldn't be very happy about this. On the other hand, I don't have another solution (except your workaround). We should think of some ways to decouple the generation strategies (the DateGeneration::Rule enum might be a step in that direction). Well, I don't know. Try adding the parameter and let's see how much of a change it is. Luigi On Thu, May 29, 2014 at 11:18 AM, Francois Botha <[hidden email]> wrote: > It seems bonds are boring. :) > > Luigi/other devs, do you have any objections to me adding such a parameter > to force the schedule generator to ignore leap year days? > > regards > Francois > > Francois Botha > > > On 26 May 2014 14:38, Francois Botha <[hidden email]> wrote: >> >> Hi, >> >> We have some bonds that pay half-yearly coupons in February and August. >> These coupons are defined to be paid on 28 February and 31 August, >> regardless of whether it's a leap year or not. For example, in 2020, the >> coupon will pay on 28 February. Reference: >> http://www.treasury.gov.za/divisions/alm/2010/R213.pdf >> >> At the moment the schedule generator can't handle this specific instance. >> As a workaround I generate a normal schedule with endOfMonth=true and then >> manually alter the schedule by looping through the generated dates and >> adjusting the 29 February entries. >> >> If this is a common occurrence in other markets I'd like to enhance the >> Schedule constructor with a parameter to indicate that leap years should not >> pay out on 29 February. If this isn't common elsewhere, I'll stick to my >> workaround. >> >> Your comments, please? >> >> thanks, >> Francois Botha > > > > ------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > _______________________________________________ > QuantLib-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-users > -- <https://implementingquantlib.blogspot.com> <https://twitter.com/lballabio> ------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Ok thanks. I'll do the change and let's see how it goes. As an alternative, I'm comfortable with the workaround of 'hacking' the schedule after it has been generated, but I need to be able to replicate that process using QuantlibXL. To do that, I'd have to generate a schedule from a vector of dates, but still have the full interface available. This is currently not possible.
Francois Botha
On 29 May 2014 12:06, Luigi Ballabio <[hidden email]> wrote: I'm not sure. On the one hand Schedule has a lot of parameters ------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Yes, we should make the full interface available from both constructors. The problem is probably to figure out what periods are regular, but the information could be passed as an additional parameter. Luigi On May 29, 2014 1:47 PM, "Francois Botha" <[hidden email]> wrote:
------------------------------------------------------------------------------ Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Free forum by Nabble | Edit this page |