Problem within the Bond YieldSolver class...

[Toyin Akin]

Hi,

Okay, after playing around a bit within the Bond classes, there can be
situations where the implied Yield will not reprice the bond exactly
(yield() function of the Bond class). This is because there is a minor
difference between the implementation between the computation of the dirty
price within the YieldSolver (dirtyPriceFromYield() function) and the
performCalculation class of the Bond class.

Basically it's the way accrual periods are computed when the datedDate is
before the SettleDate
for the first cashflow.

Within the dirtyPriceFromYield() function, for the first cashflow period,
the call eventually ends up calling yearFraction, passing all four date
parameters (ie - does not default the last 2 date parameters).

However within the performCalculation() function of the Bond class, within
the call to discount(), the yearfraction is computed in a similar way to the
yearFraction function, but without the use of the last 2 date parameters.
Thus the coverage computed, especially in the presence of accrual periods
are different.

In my local copy, I thought about changing the code within the
performCalculation() function so that for the first accrual period, I
compute a 'Time' variable instead of using the 'Date' variable and then
passing this to the discount() function. The Time variable would have been
produced using all four date parameters of the yearFraction() function,
however this does not work as this accrual period is priced correctly, but
the next period is not as the 'Time' parameter implied within the discount()
function is really the sum of the first 'incorrect' (for the lack of a
better word) accrual period + the the following periods.

The dirtyPriceFromYield() function is a little smarter in that basically it
computes the accrual period for the first coshflow and then works out the
accural period for the next period and adds this to the first period
(indirectly that is via the multiplication of the discount factors...).

I've included a little graphic of the inputs that I have used within the
FixedCouponBond function.

I've also included my own solution within a text file which is consistent
with the code within the YieldSolver class ( more specifically the
dirtyPriceFromYield() function ).

Sorry about the waffle...

Toy out.

[Toyin Akin]

One other thing to make this a bit clearer...

When I say "it does not reprice the bond correctly", I do the following...

Use the Bond's yield() function to imply out the yield.

Then construct a new bond object with exactly the same parameters as the
first, but this time pass in a flat Yieldcurve with the implied yield value.
you do not get the same dirty price once you have PV-ed the second bond.

Toy out.

>From: "Toyin Akin" <[hidden email]>
>To: [hidden email]
>CC: [hidden email]
>Subject: [Quantlib-users] Problem within the Bond YieldSolver class...
>Date: Tue, 06 Dec 2005 18:27:50 +0000
>
>Hi,
>
>Okay, after playing around a bit within the Bond classes, there can be
>situations where the implied Yield will not reprice the bond exactly
>(yield() function of the Bond class). This is because there is a minor
>difference between the implementation between the computation of the dirty
>price within the YieldSolver (dirtyPriceFromYield() function) and the
>performCalculation class of the Bond class.
>
>Basically it's the way accrual periods are computed when the datedDate is
>before the SettleDate
>for the first cashflow.
>
>Within the dirtyPriceFromYield() function, for the first cashflow period,
>the call eventually ends up calling yearFraction, passing all four date
>parameters (ie - does not default the last 2 date parameters).
>
>However within the performCalculation() function of the Bond class, within
>the call to discount(), the yearfraction is computed in a similar way to
>the yearFraction function, but without the use of the last 2 date
>parameters. Thus the coverage computed, especially in the presence of
>accrual periods are different.
>
>In my local copy, I thought about changing the code within the
>performCalculation() function so that for the first accrual period, I
>compute a 'Time' variable instead of using the 'Date' variable and then
>passing this to the discount() function. The Time variable would have been
>produced using all four date parameters of the yearFraction() function,
>however this does not work as this accrual period is priced correctly, but
>the next period is not as the 'Time' parameter implied within the
>discount() function is really the sum of the first 'incorrect' (for the
>lack of a better word) accrual period + the the following periods.
>
>The dirtyPriceFromYield() function is a little smarter in that basically it
>computes the accrual period for the first coshflow and then works out the
>accural period for the next period and adds this to the first period
>(indirectly that is via the multiplication of the discount factors...).
>
>I've included a little graphic of the inputs that I have used within the
>FixedCouponBond function.
>
>I've also included my own solution within a text file which is consistent
>with the code within the YieldSolver class ( more specifically the
>dirtyPriceFromYield() function ).
>
>Sorry about the waffle...
>
>Toy out.
>

><< BondGraphic.gif >>


><< BondCode.txt >>

[Toyin Akin]

Hi,

Within the accuralAmount() function of the Bond class, if one has a Bond
where the settlement date passed in is equal to a coupon payment date and
the QL_TODAYS_PAYMENTS flag is enabled within the config file, I think the
function should return zero.

However right now it returns a whole coupon amount thus the value of the
CleanPrice is incorrect.

I believe if you simply change the

cashFlows_[i]->date() >= settlement

logic to

cashFlows_[i]->date() > settlement

then this should fix it.

Probably the logic reversed for the elseif statement also ( > to >= ).

Toy out.

[Luigi Ballabio]

On 12/07/2005 12:04:27 PM, Toyin Akin wrote:
>
> Within the accuralAmount() function of the Bond class, if one has a  
> Bond where the settlement date passed in is equal to a coupon payment  
> date and the QL_TODAYS_PAYMENTS flag is enabled within the config  
> file, I think the function should return zero.

No, it shouldn't. It must return zero if QL_TODAYS_PAYMENTS is not  
defined, since in that case the coupon is gone. If enabled, the coupon  
is still part of the bond and the accrued amount is returned  
accordingly.

Luigi

----------------------------------------

Steinbach's Guideline for Systems Programming:
        Never test for an error condition you don't know how to handle.

[Luigi Ballabio]

On 12/06/2005 07:27:50 PM, Toyin Akin wrote:

> Okay, after playing around a bit within the Bond classes, there can  
> be situations where the implied Yield will not reprice the bond  
> exactly (yield() function of the Bond class). This is because there  
> is a minor difference between the implementation between the  
> computation of the dirty price within the YieldSolver  
> (dirtyPriceFromYield() function) and the performCalculation class of  
> the Bond class.
>
> [...]
>
> In my local copy, I thought about changing the code within the  
> performCalculation() function so that for the first accrual period, I  
> compute a 'Time' variable instead of using the 'Date' variable and  
> then passing this to the discount() function.

Maybe, but this can give an incorrect discount when the yield term  
structure is not constant (as you're basically passing a time  
corresponding to a different date.)

I'm not sure of how to go about this one. We might ask the term  
structure for the rates over the coupon and compound them to get the  
discount...

Luigi


----------------------------------------

Just remember what ol' Jack Burton does when the earth quakes, the
poison arrows fall from the sky, and the pillars of Heaven shake. Yeah,
Jack Burton just looks that big old storm right in the eye and says,
"Give me your best shot. I can take it."
-- Jack Burton, "Big trouble in Little China"

[Toyin Akin]

##############################################"
No, it shouldn't. It must return zero if QL_TODAYS_PAYMENTS is not  defined,
since in that case the coupon is gone. If enabled, the coupon  is still part
of the bond and the accrued amount is returned  accordingly.
##############################################"

I'm playing devil's avocate here but...

If QL_TODAYS_PAYMENTS  is defined, isn't there an inflow of the coupon also
that we recieve from the current BOND holder?

(Assuming that we are paying to the bond holder the full price
Clean+Accured. He can't keep the coupon payment he's about to recieve
because we have paid him it in the full price, thus he gives it to us)

Thus total cashflow is Clean+Accured - Accured = Clean.

If we are to PAY this dirtyprice than we have to recieve the coupon. Thus
ending up with the CleanPrice again, implying that the accured amount is
zero.

Does that work?!! Ahhhh... I knew BOND's were troublesome...!!

Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: [Quantlib-users] Re: accrualAmount() function within the bond
>class...
>Date: Fri, 09 Dec 2005 13:24:34 +0000
>
>
>On 12/07/2005 12:04:27 PM, Toyin Akin wrote:
>>
>>Within the accuralAmount() function of the Bond class, if one has a  Bond
>>where the settlement date passed in is equal to a coupon payment  date and
>>the QL_TODAYS_PAYMENTS flag is enabled within the config  file, I think
>>the function should return zero.
>
>No, it shouldn't. It must return zero if QL_TODAYS_PAYMENTS is not  
>defined, since in that case the coupon is gone. If enabled, the coupon  is
>still part of the bond and the accrued amount is returned  accordingly.
>
>Luigi
>
>----------------------------------------
>
>Steinbach's Guideline for Systems Programming:
> Never test for an error condition you don't know how to handle.
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Toyin Akin]

Sounds good, basically the same logic within the dirtyPriceFromYield()
function.

Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: [Quantlib-users] Re: Problem within the Bond YieldSolver class...
>Date: Fri, 09 Dec 2005 13:34:50 +0000
>
>
>On 12/06/2005 07:27:50 PM, Toyin Akin wrote:
>>Okay, after playing around a bit within the Bond classes, there can  be
>>situations where the implied Yield will not reprice the bond  exactly
>>(yield() function of the Bond class). This is because there  is a minor
>>difference between the implementation between the  computation of the
>>dirty price within the YieldSolver  (dirtyPriceFromYield() function) and
>>the performCalculation class of  the Bond class.
>>
>>[...]
>>
>>In my local copy, I thought about changing the code within the  
>>performCalculation() function so that for the first accrual period, I  
>>compute a 'Time' variable instead of using the 'Date' variable and  then
>>passing this to the discount() function.
>
>Maybe, but this can give an incorrect discount when the yield term  
>structure is not constant (as you're basically passing a time  
>corresponding to a different date.)
>
>I'm not sure of how to go about this one. We might ask the term  structure
>for the rates over the coupon and compound them to get the  discount...
>
>Luigi
>
>
>----------------------------------------
>
>Just remember what ol' Jack Burton does when the earth quakes, the
>poison arrows fall from the sky, and the pillars of Heaven shake. Yeah,
>Jack Burton just looks that big old storm right in the eye and says,
>"Give me your best shot. I can take it."
>-- Jack Burton, "Big trouble in Little China"
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On 12/09/2005 03:23:35 PM, Toyin Akin wrote:
>
> (Assuming that we are paying to the bond holder the full price  
> Clean+Accured. He can't keep the coupon payment he's about to recieve  
> because we have paid him it in the full price, thus he gives it to us)
>
> Thus total cashflow is Clean+Accured - Accured = Clean.
>
> If we are to PAY this dirtyprice than we have to recieve the coupon.

So far, so good...

> Thus ending up with the CleanPrice again, implying that the
> accured amount is zero.

No, I don't see the implication.

Anyway, the situation on a payment date when QL_TODAYS_COUPONS is  
defined is basically the same as the situation one day before the  
payment date: the coupon amount is included in the dirty price and the  
accrued amount is (almost) the amount of the coupon. If yesterday's  
situation makes sense to you, I don't see why today's situation  
doesn't, given that the coupon still wasn't paid.

Later,
        Luigi

----------------------------------------

I hate quotations.
-- Ralph Waldo Emerson

[Toyin Akin]

But,

Yesterday if we bought the BOND, we paid the Dirty Price and today we
recieve the coupon. Thus the PV over the two days is roughly the clean
price.

If we look at today and tomorrow...

If Today we are buying the BOND and we pay the dirtyprice. Who get's the
BOND coupon payment (remember that QL_TODAYS_COUPONS  is defined so the
coupon is paid today also).

If the current BOND holder recieves the coupon then our outflow today is the
dirty price. Come tomorrow, no coupon inflow and thus the value is no-where
equal to the first scenario of yesterday and Today. Basically I would never
buy a BOND on a coupon payment, much cheaper to buy it a day before coupon
payment.

If however we recieve the coupon as well as paying out the dirtyprice
(today), this coupon payment has to go somewhere? It's not added to
tomorrow's PV as QL_TODAYS_COUPONS is defined as recieving this Today.

If this coupon payment is not included anywhere then again we have paid out
the dirty price.
Again, buy the BOND day before a coupon payment.

Unless you are saying that this coupon payment goes into a cash position
which is treated separately from the BOND.

Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: Re: [Quantlib-users] Re: accrualAmount() function within the bond
>class...
>Date: Fri, 09 Dec 2005 14:36:39 +0000
>
>
>On 12/09/2005 03:23:35 PM, Toyin Akin wrote:
>>
>>(Assuming that we are paying to the bond holder the full price  
>>Clean+Accured. He can't keep the coupon payment he's about to recieve  
>>because we have paid him it in the full price, thus he gives it to us)
>>
>>Thus total cashflow is Clean+Accured - Accured = Clean.
>>
>>If we are to PAY this dirtyprice than we have to recieve the coupon.
>
>So far, so good...
>
>>Thus ending up with the CleanPrice again, implying that the
>>accured amount is zero.
>
>No, I don't see the implication.
>
>Anyway, the situation on a payment date when QL_TODAYS_COUPONS is  defined
>is basically the same as the situation one day before the  payment date:
>the coupon amount is included in the dirty price and the  accrued amount is
>(almost) the amount of the coupon. If yesterday's  situation makes sense to
>you, I don't see why today's situation  doesn't, given that the coupon
>still wasn't paid.
>
>Later,
> Luigi
>
>----------------------------------------
>
>I hate quotations.
>-- Ralph Waldo Emerson
>

[Luigi Ballabio]

On 12/09/2005 04:09:50 PM, Toyin Akin wrote:
>
> Yesterday if we bought the BOND, we paid the Dirty Price and today we  
> recieve the coupon. Thus the PV over the two days is roughly the  
> clean price.

If the coupon is still included in the bond (QL_TODAYS_COUPON is
defined) we pay the dirty price and tonight we'll receive the
coupon. The PV is the clean price.


> If Today we are buying the BOND and we pay the dirtyprice. Who get's  
> the BOND coupon payment (remember that QL_TODAYS_COUPONS  is defined  
> so the coupon is paid today also).

We do. You can think of the switch this way:

- QL_TODAY_COUPONS is not defined => coupons are paid first thing in
   the morning;
- QL_TODAY_COUPONS is defined => coupons are paid last thing in the
   afternoon.

If we buy the bond now, we'll be the holders this evening when the  
coupon is paid, so we'll receive the payment.


> If however we recieve the coupon as well as paying out the dirtyprice  
> (today), this coupon payment has to go somewhere?

It's both in today's dirty price and in today's accrued amount, just as  
it was in yesterday's dirty price and accrued amount.


Later (no pun intended,)
        Luigi


----------------------------------------

Call on God, but row away from the rocks.
-- Indian proverb

[Toyin Akin]

>If the coupon is still included in the bond (QL_TODAYS_COUPON is
>defined) we pay the dirty price and tonight we'll receive the
>coupon. The PV is the clean price.

Above you write "equal's to the clean Price if QL_TODAYS_COUPON is defined".

But that's not what the PV equal's when you execute the dirtyPrice()
function as it is today.
The dirtyPrice does not deduct the coupon that is to be recieved.

Okay, so maybe it's a question of timing, the coupon is received tonight so
it's in tomorrow's cashflow etc...

I can't think of an expression to beat your "laters..." remark (!!)

Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: Re: [Quantlib-users] Re: accrualAmount() function within the bond
>class...
>Date: Fri, 09 Dec 2005 15:20:59 +0000
>
>
>On 12/09/2005 04:09:50 PM, Toyin Akin wrote:
>>
>>Yesterday if we bought the BOND, we paid the Dirty Price and today we  
>>recieve the coupon. Thus the PV over the two days is roughly the  clean
>>price.
>
>If the coupon is still included in the bond (QL_TODAYS_COUPON is
>defined) we pay the dirty price and tonight we'll receive the
>coupon. The PV is the clean price.
>
>
>>If Today we are buying the BOND and we pay the dirtyprice. Who get's  the
>>BOND coupon payment (remember that QL_TODAYS_COUPONS  is defined  so the
>>coupon is paid today also).
>
>We do. You can think of the switch this way:
>
>- QL_TODAY_COUPONS is not defined => coupons are paid first thing in
>   the morning;
>- QL_TODAY_COUPONS is defined => coupons are paid last thing in the
>   afternoon.
>
>If we buy the bond now, we'll be the holders this evening when the  coupon
>is paid, so we'll receive the payment.
>
>
>>If however we recieve the coupon as well as paying out the dirtyprice  
>>(today), this coupon payment has to go somewhere?
>
>It's both in today's dirty price and in today's accrued amount, just as  it
>was in yesterday's dirty price and accrued amount.
>
>
>Later (no pun intended,)
> Luigi
>
>
>----------------------------------------
>
>Call on God, but row away from the rocks.
>-- Indian proverb
>

[Luigi Ballabio]

On 12/09/2005 05:13:40 PM, Toyin Akin wrote:
>
>> If the coupon is still included in the bond (QL_TODAYS_COUPON is
>> defined) we pay the dirty price and tonight we'll receive the
>> coupon. The PV is the clean price.
>
> Above you write "equal's to the clean Price if QL_TODAYS_COUPON is  
> defined".

I probably meant the other way around. I even wrote the wrong name for  
the define :)

> Okay, so maybe it's a question of timing, the coupon is received
> tonight so it's in tomorrow's cashflow etc...

No, it's still today's cashflow. Let's try and put it this way.

1) At all times and regardless of whether QL_TODAYS_PAYMENTS is defined,

clean price = dirty price - accrued amount.

2) Upon a coupon payment, both the dirty price and the accrued amount  
drop by the amount of the coupon. Since the clean price is given by  
their difference, it doesn't change.

For instance:

- the bond pays 5$ tomorrow. The dirty price is 102$ and the accrued  
amount is almost 5$. The clean price is 97$. If I buy the bond, I'll  
pay 102$ today and receive 5$ tomorrow. After the payment, I'll be  
short of 97$ in cash and I will hold a bond whose value is the NPV of  
the future coupons.

- Let's say I didn't buy the bond. Forward 2 days. The bond paid 5$  
yesterday. The dirty price dropped and is now 97$; the accrued amount  
dropped and is almost 0. The clean price is still 97$. If I buy the  
bond, I'll pay 97$ and I will hold a bond whose value is the NPV of the  
same future coupons.

- The bond pays today, and QL_TODAYS_PAYMENTS _is not_ defined.
The current holder already received the payment. The dirty price is  
already down to 97$ and the accrued amount is already down to 0. The  
clean price is 97$ as usual. If I buy the bond, I'll pay 97$ and I will  
hold a bond whose value is the NPV of the same future coupons.

- The bond pays today, and QL_TODAYS_PAYMENTS _is_ defined.
The current holder didn't receive the payment yet. The dirty price is  
still 102$ and the accrued amount is still 5$. Not surprisingly, the  
clean price is 97$. If I buy the bond, I'll pay 102$ and receive 5$  
shortly thereafter. When the day closes, I'll be short of 97$ in cash  
and I will hold a bond whose value is the NPV of the now familiar  
future coupons.

Did you expect different figures in any of the above cases?

Luigi



----------------------------------------

I have yet to see any problem, however complicated, which, when you
looked at it in the right way, did not become still more complicated.
-- Poul Anderson

[Toyin Akin]

Okay.

I agree on all four scenarios.

Basically the coupon payment is held in a cash position, thus like you say,
at the end of the day, the final PV is the dirty price of the BOND + the
cash position.

The only thing I was hung up about is that I thought that the final PV of
the BOND should be the dirty price + this CASH position and that the dirty
price should reflect this position.

However you are saying that the BOND's dirty price returns just that, and
that the cash position  is treated on it's own. The BOND class has no
knowledge of this.

Thus a user wishing to build a portfolio of BONDS and to NPV this portfolio
daily has to manage two portfolios. The BOND portfolio and the CASH
portfolio.

Seems that FinancialCAD looks at it the other way. (ie, when you request the
dirty price, it returns the same value as the clean price. It also reports
the accrued as zero). Thus no CASH position to manage.

Interesting... but I think we are on the same page now.

Thanks for the detailed breakdown...

Toy out.


The only issue I had was that the
I agree totally.

It looks like

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: Re: [Quantlib-users] Re: accrualAmount() function within the bond
>class...
>Date: Fri, 09 Dec 2005 17:36:24 +0000
>
>
>On 12/09/2005 05:13:40 PM, Toyin Akin wrote:
>>
>>>If the coupon is still included in the bond (QL_TODAYS_COUPON is
>>>defined) we pay the dirty price and tonight we'll receive the
>>>coupon. The PV is the clean price.
>>
>>Above you write "equal's to the clean Price if QL_TODAYS_COUPON is  
>>defined".
>
>I probably meant the other way around. I even wrote the wrong name for  the
>define :)
>
>>Okay, so maybe it's a question of timing, the coupon is received
>>tonight so it's in tomorrow's cashflow etc...
>
>No, it's still today's cashflow. Let's try and put it this way.
>
>1) At all times and regardless of whether QL_TODAYS_PAYMENTS is defined,
>
>clean price = dirty price - accrued amount.
>
>2) Upon a coupon payment, both the dirty price and the accrued amount  drop
>by the amount of the coupon. Since the clean price is given by  their
>difference, it doesn't change.
>
>For instance:
>
>- the bond pays 5$ tomorrow. The dirty price is 102$ and the accrued  
>amount is almost 5$. The clean price is 97$. If I buy the bond, I'll  pay
>102$ today and receive 5$ tomorrow. After the payment, I'll be  short of
>97$ in cash and I will hold a bond whose value is the NPV of  the future
>coupons.
>
>- Let's say I didn't buy the bond. Forward 2 days. The bond paid 5$  
>yesterday. The dirty price dropped and is now 97$; the accrued amount  
>dropped and is almost 0. The clean price is still 97$. If I buy the  bond,
>I'll pay 97$ and I will hold a bond whose value is the NPV of the  same
>future coupons.
>
>- The bond pays today, and QL_TODAYS_PAYMENTS _is not_ defined.
>The current holder already received the payment. The dirty price is  
>already down to 97$ and the accrued amount is already down to 0. The  clean
>price is 97$ as usual. If I buy the bond, I'll pay 97$ and I will  hold a
>bond whose value is the NPV of the same future coupons.
>
>- The bond pays today, and QL_TODAYS_PAYMENTS _is_ defined.
>The current holder didn't receive the payment yet. The dirty price is  
>still 102$ and the accrued amount is still 5$. Not surprisingly, the  clean
>price is 97$. If I buy the bond, I'll pay 102$ and receive 5$  shortly
>thereafter. When the day closes, I'll be short of 97$ in cash  and I will
>hold a bond whose value is the NPV of the now familiar  future coupons.
>
>Did you expect different figures in any of the above cases?
>
>Luigi
>
>
>
>----------------------------------------
>
>I have yet to see any problem, however complicated, which, when you
>looked at it in the right way, did not become still more complicated.
>-- Poul Anderson
>

[Joseph Wang]

A few questions:

1) Would anyone object if I went into the code and did some refactoring
to make the logic more obvious?  I was thinking in particular of
creating a private method - bool couponIssued(int i)

2) Any thoughts on making QL_TODAYS_DATE a parameter which is settable.  
I was thinking that this would make unit tests easier to write since you
can then run the bond class under both conditions.

3) Anyone have a test case coded up to put into the unit test framework?

[Toyin Akin]

Hi,

I agree about making the QL_TODAYS_DATE parameter settable, however
practically every pricing file will need to be touched as this define is
used a lot.

Anyway, (concerning BONDS only) QuantLib will not handle the recieving of
this Coupon payment on a payment date (even within the NPV() function) and
thus you have to manage this yourself (Regardless of the setting of
QL_TODAYS_DATE ).

Toy out.

>From: Joseph Wang <[hidden email]>
>To: [hidden email]
>Subject: Re: [Quantlib-users] Re: accrualAmount() function within the bond
>class...
>Date: Fri, 09 Dec 2005 14:15:39 -0600
>
>A few questions:
>
>1) Would anyone object if I went into the code and did some refactoring to
>make the logic more obvious?  I was thinking in particular of creating a
>private method - bool couponIssued(int i)
>
>2) Any thoughts on making QL_TODAYS_DATE a parameter which is settable.  I
>was thinking that this would make unit tests easier to write since you can
>then run the bond class under both conditions.
>
>3) Anyone have a test case coded up to put into the unit test framework?
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Toyin Akin]

Hi,

Maybe you could add an IsFlat() method to the YieldCurve class. (Internally
testing to see if the array size is 1). Then you could switch between the
two implementations (within the BOND's performCalculation() function)
depending on the value of this IsFlat() function.

Although one implementation regardless of how the yieldCurve is structured
is obviously a good thing.

Just an idea...

Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: [Quantlib-users] Re: Problem within the Bond YieldSolver class...
>Date: Fri, 09 Dec 2005 13:34:50 +0000
>
>
>On 12/06/2005 07:27:50 PM, Toyin Akin wrote:
>>Okay, after playing around a bit within the Bond classes, there can  be
>>situations where the implied Yield will not reprice the bond  exactly
>>(yield() function of the Bond class). This is because there  is a minor
>>difference between the implementation between the  computation of the
>>dirty price within the YieldSolver  (dirtyPriceFromYield() function) and
>>the performCalculation class of  the Bond class.
>>
>>[...]
>>
>>In my local copy, I thought about changing the code within the  
>>performCalculation() function so that for the first accrual period, I  
>>compute a 'Time' variable instead of using the 'Date' variable and  then
>>passing this to the discount() function.
>
>Maybe, but this can give an incorrect discount when the yield term  
>structure is not constant (as you're basically passing a time  
>corresponding to a different date.)
>
>I'm not sure of how to go about this one. We might ask the term  structure
>for the rates over the coupon and compound them to get the  discount...
>
>Luigi
>
>
>----------------------------------------
>
>Just remember what ol' Jack Burton does when the earth quakes, the
>poison arrows fall from the sky, and the pillars of Heaven shake. Yeah,
>Jack Burton just looks that big old storm right in the eye and says,
>"Give me your best shot. I can take it."
>-- Jack Burton, "Big trouble in Little China"
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
><a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Joseph Wang]

Looking over the code it doesn't look that bad to refactor things so
that QL_TODAYS_PAYMENT is modularized.  The key seems to create a
routine in Event


bool Event::hasOccurred(Date settlementDate,
#if QL_TODAYS_PAYMENT
bool include_todays_date = true
#else
bool include_todays_date = false
#endif
);

This gets rid of all but one use of  the define

Thoughts?

[Toyin Akin]

Hi,

Is this just for bonds or for the whole library?
How's the convertible bonds code coming along...

I keep seeing the converible bonds header file appearing within the test
unit code and then disappear again!!

Toy out...

>From: Joseph Wang <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: Re: [Quantlib-users] Re: accrualAmount() function within the bond
>class...
>Date: Sat, 10 Dec 2005 02:58:50 -0600
>
>Looking over the code it doesn't look that bad to refactor things so that
>QL_TODAYS_PAYMENT is modularized.  The key seems to create a routine in
>Event
>
>
>bool Event::hasOccurred(Date settlementDate,
>#if QL_TODAYS_PAYMENT
>bool include_todays_date = true
>#else
>bool include_todays_date = false
>#endif
>);
>
>This gets rid of all but one use of  the define
>
>Thoughts?

[Toyin Akin]

Ah,

It just occured to me, I thought your original question was concerning how
the QL_TODAYS_PAYMENT is set in the first place. (ie - set at compilation
time.)

Thus I thought that you wanted to make this user configurable. Set at
run-time instead.

Forgive me.

Hence I guess your proposal concerns only Bond's then?

Toy out...

>From: Joseph Wang <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: Re: [Quantlib-users] Re: accrualAmount() function within the bond
>class...
>Date: Sat, 10 Dec 2005 02:58:50 -0600
>
>Looking over the code it doesn't look that bad to refactor things so that
>QL_TODAYS_PAYMENT is modularized.  The key seems to create a routine in
>Event
>
>
>bool Event::hasOccurred(Date settlementDate,
>#if QL_TODAYS_PAYMENT
>bool include_todays_date = true
>#else
>bool include_todays_date = false
>#endif
>);
>
>This gets rid of all but one use of  the define
>
>Thoughts?

[Luigi Ballabio]

On 12/10/2005 09:58:50 AM, Joseph Wang wrote:
> Looking over the code it doesn't look that bad to refactor things so
> that QL_TODAYS_PAYMENT is modularized.  The key seems to create a
> routine in Event
>
> bool Event::hasOccurred(Date settlementDate,

I like this---thanks for the fix.
On the other hand, I like EventDate less. It seems to be there just to  
give a hasOccurred method to Date. I'll be hacking your code shortly :)

Later,
        Luigi

----------------------------------------

Weiler's Law:
         Nothing is impossible for the man who doesn't have to
         do it himself.