Possible problem on bermuda swaptions: 2

[Luca Berardi]

Hi Luigi,

as I told you in my previous email it seems to me there is a problem
with rollback over hull-white trees. I wrote a piece of code
reproducing it, which I'm sending out in the attachment.  This is the
point: considering (discretized) discount bonds, they get initialized
correctly (at 1.) but after rollback the have in some point of the
tree, values greater than one, which seems unacceptable to me.
I tried to go have a look at the Tree code, but got confused with the
TrinomialBranching mechanics...

The attachments:
latticeTest.cpp -> is the code reproducing the above behavior.
latticeDebug.txt-> is the output describing the (possible) error.

Ciao,
Luca




__________________________________________________________________
Tiscali Adsl 3 Mega Flat, 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi in Rete alla supervelocita'
a soli 29.95 euro al mese senza limiti di tempo. Attivati entro
il 28 Febbraio 2005, 3 MESI sono GRATIS
Scopri come http://abbonati.tiscali.it/adsl/sa/2flat_tc/

[Luigi Ballabio]

On 02/24/05 10:48:53, Luca Berardi wrote:
>
> as I told you in my previous email it seems to me there is a problem
> with rollback over hull-white trees. I wrote a piece of code
> reproducing it, which I'm sending out in the attachment.  This is the
> point: considering (discretized) discount bonds, they get initialized
> correctly (at 1.) but after rollback the have in some point of the
> tree, values greater than one, which seems unacceptable to me.

Luca,
        no, that is correct. The Hull-White model allows negative rates  
(I'm told it's a known weakness of the model) resulting in discounts  
greater than 1 in some regions of the tree.

Instead, the problem in the new release seems to be some date  
synchronization: namely, due to date adjustment it may happens that an  
exercise date is one or two days earlier than a fixed-coupon payment. This  
leads to incorrect pricing as the underlying of the option will include  
such payment---which it shouldn't. I'm testing a patch to fix the issue; I  
should be able to make it available in a few hours.

Later,
        Luigi

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

Prediction is very difficult, especially of the future.
-- Niels Bohr

[Luca Berardi]

>Luca,
> no, that is correct. The Hull-White model allows negative rates
>(I'm told it's a known weakness of the model) resulting in discounts
>greater than 1 in some regions of the tree.

I do agree. In my posting #2 I didn't make myself very clear on
this. I hope I was more precise in posting #3. The hull-white model
gives the short rate as the sum of a ornstein-uhlenbeck diffusion
process and a fitting curve function...Hence, it's not a matter
whether the short rate can be negative (this is always theoretically
possible), but if the short rate can be negative for the tree created
with a given set of parameters for the hull-white model (spatial step,
sigma and reverse speed and the fitting function). Trying to
investigate all the possible sources of the mispricing I was afraid
that the tree was not built correctly (but now I realize I cannot find
any differences between the hull-white tree construction in releases
0.3.7 and 0.3.8 ...am I right?) ...but -as you're pointing out- this
is not the problem.

>Instead, the problem in the new release seems to be some date
>synchronization: namely, due to date adjustment it may happens that an

>exercise date is one or two days earlier than a fixed-coupon payment. This
>leads to incorrect pricing as the underlying of the option will include

>such payment---which it shouldn't. I'm testing a patch to fix the issue;
>I should be able to make it available in a few hours.

This is an extremely interesting issue, and I had the chance to
discuss it thoroughly with a trader recently. He explained to me that
the very successive cashflow of the underlying swap after the exercise
date should NEVER be considered in the bermuda swaption pricing. So
the correct behavior would be alwasy to disregard this cashflow:
unlike bonds, swaps do not have accrued interests to pay for.
In particular if the exercise date is also a payment date, the current
payment is discarded.

Ciao,
Luca





__________________________________________________________________
Tiscali Adsl 3 Mega Flat, 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi in Rete alla supervelocita'
a soli 29.95 euro al mese senza limiti di tempo. Attivati entro
il 28 Febbraio 2005, 3 MESI sono GRATIS
Scopri come http://abbonati.tiscali.it/adsl/sa/2flat_tc/

[Luigi Ballabio]

On 02/24/05 11:52:05, Luca Berardi wrote:
>
> >Instead, the problem in the new release seems to be some date
> >synchronization: namely, due to date adjustment it may happens that an
> >exercise date is one or two days earlier than a fixed-coupon payment.
>
> This is an extremely interesting issue, and I had the chance to
> discuss it thoroughly with a trader recently. He explained to me that
> the very successive cashflow of the underlying swap after the exercise
> date should NEVER be considered in the bermuda swaption pricing.

Yes, that is the correct behavior. The following patch (tested on the  
BermudanSwaption example, which did give different results in 0.3.7 and  
0.3.8---somehow this escaped testing) should fix this; you can try and  
apply it to the QuantLib 0.3.8 sources to see if you get the correct  
figures.

Later,
        Luigi

diff -r -C 3 QuantLib-0.3.8/ql/Instruments/swaption.cpp QuantLib-0.3.8-
patched/ql/Instruments/swaption.cpp
*** QuantLib-0.3.8/ql/Instruments/swaption.cpp Mon Oct 25 16:00:28 2004
--- QuantLib-0.3.8-patched/ql/Instruments/swaption.cpp Thu Feb 24 10:53:17  
2005
***************
*** 85,90 ****
--- 85,120 ----
                     "fair swap rate null or not set");
          QL_REQUIRE(fixedBPS != Null<Real>(),
                     "fixed swap BPS null or not set");
+     }
+
+     namespace {
+
+         inline bool withinPreviousWeek(Time t1, Time t2) {
+             static const Time dt = 1.0/52;
+             return t1-dt <= t2 && t2 <= t1;
+         }
+
+         inline bool withinNextWeek(Time t1, Time t2) {
+             static const Time dt = 1.0/52;
+             return t1 <= t2 && t2 <= t1+dt;
+         }
+
+     }
+
+     void Swaption::arguments::adjust() {
+         // Date adjustments can get time vectors out of synch.
+         // Here, we try and collapse similar dates.
+         for (Size i=0; i<stoppingTimes.size(); i++) {
+             Time exercise = stoppingTimes[i];
+             for (Size j=0; j<fixedPayTimes.size(); j++){
+                 if (withinNextWeek(exercise, fixedPayTimes[j]))
+                     fixedPayTimes[j] = exercise;
+             }
+             for (Size k=0; k<floatingResetTimes.size(); k++) {
+                 if (withinPreviousWeek(exercise,floatingResetTimes[k]))
+                     floatingResetTimes[k] = exercise;
+             }
+         }
      }

  }
diff -r -C 3 QuantLib-0.3.8/ql/Instruments/swaption.hpp QuantLib-0.3.8-
patched/ql/Instruments/swaption.hpp
*** QuantLib-0.3.8/ql/Instruments/swaption.hpp Fri Sep 17 12:05:42 2004
--- QuantLib-0.3.8-patched/ql/Instruments/swaption.hpp Thu Feb 24 10:36:14  
2005
***************
*** 77,82 ****
--- 77,83 ----
  //        Exercise::Type exerciseType;
  //        std::vector<Time> exerciseTimes;
          void validate() const;
+         void adjust();
      };

      //! %Results from swaption calculation
diff -r -C 3 QuantLib-0.3.8/ql/argsandresults.hpp QuantLib-0.3.8-patched/
ql/argsandresults.hpp
*** QuantLib-0.3.8/ql/argsandresults.hpp Wed Apr 21 17:00:26 2004
--- QuantLib-0.3.8-patched/ql/argsandresults.hpp Thu Feb 24 10:30:49  
2005
***************
*** 36,41 ****
--- 36,42 ----
        public:
          virtual ~Arguments() {}
          virtual void validate() const = 0;
+         virtual void adjust() {}
      };

      //! base class for generic result groups
diff -r -C 3 QuantLib-0.3.8/ql/instrument.hpp QuantLib-0.3.8-patched/ql/
instrument.hpp
*** QuantLib-0.3.8/ql/instrument.hpp Fri Sep 17 12:05:40 2004
--- QuantLib-0.3.8-patched/ql/instrument.hpp Thu Feb 24 10:31:10 2005
***************
*** 137,142 ****
--- 137,143 ----
          engine_->reset();
          setupArguments(engine_->arguments());
          engine_->arguments()->validate();
+         engine_->arguments()->adjust();
          engine_->calculate();
          const Value* results = dynamic_cast<const Value*>(engine_-
>results());
          QL_ENSURE(results != 0,

[Luca Berardi]

Luigi, thanks for the mail. I had quick look at the patch and have
some comments:

1) you are silently assuming that exercise dates coincide with payment
   dates of the underlying swap. Of course there might be some
   de-synchronization due to dates adjustment as you pointed out, but
   still it's not possible to deal with cases where the exercise dates
   are quite different from the swap's payment dates. The trader I
   talked to, told me that usually exercise dates are ten (business)
   days before the payment dates of the underlying swap, and with the
   adjustment carried out through the  new adjust() method you cannot take
   into account such a long temporal shift. Of course it could be
   possible to extend the adjustment for a period longer than a week,
   but then you get a mispricing due to moving payment dates to
   exercise dates. In general it would be nice not to require that
   exercise dates must "roughly" coincide with the dates in the
   underlying swap's schedule.

2) It's ok to shift backwards the payment dates of the fixed leg to
   match the exercise dates, but why do you need to shift the fixing
   dates of the floating leg forward (again to match the nearest
   exercise date)?

Ciao,
Luca.


-----Messaggio originale-----
Da: Luigi Ballabio [mailto:[hidden email]]
Inviato: giovedì 24 febbraio 2005 12:18
A: Luca Berardi
Cc: [hidden email]
Oggetto: [Quantlib-users] Bermudan swaption patch (was Re: Possible
problem on bermudaswaptions)



On 02/24/05 11:52:05, Luca Berardi wrote:
>
> >Instead, the problem in the new release seems to be some date
> >synchronization: namely, due to date adjustment it may happens that an
> >exercise date is one or two days earlier than a fixed-coupon payment.
>
> This is an extremely interesting issue, and I had the chance to
> discuss it thoroughly with a trader recently. He explained to me that
> the very successive cashflow of the underlying swap after the exercise
> date should NEVER be considered in the bermuda swaption pricing.

Yes, that is the correct behavior. The following patch (tested on the
BermudanSwaption example, which did give different results in 0.3.7 and

0.3.8---somehow this escaped testing) should fix this; you can try and
apply it to the QuantLib 0.3.8 sources to see if you get the correct
figures.

Later,
        Luigi




__________________________________________________________________
Tiscali Adsl 3 Mega Flat, 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi in Rete alla supervelocita'
a soli 29.95 euro al mese senza limiti di tempo. Attivati entro
il 28 Febbraio 2005, 3 MESI sono GRATIS
Scopri come http://abbonati.tiscali.it/adsl/sa/2flat_tc/

[Luca Berardi]

Still on the exercise dates issue:

Assume for simplicity that the floating and fixed leg of the
underlying swap have the same schedule. In pricing the bermuda
swaption one should discard the very successive payment after the
current exercise date.
If the floating and fixed leg have different schedules (e.g. funding
leg pays quarterly and fixed annually) things get more complicated
because all the swap cashflows following the current exercise dates
must be discarded until we reach the second cashflow of the lower
frequency leg.

I realize that getting things working correctly (should my
interpretation be indeed correct) is not an easy task in the current
framework. This is because the DiscretizedSwaption does not know of
the underlying swap's cashflows. A possible workaround would be to
rewrite the pricing engine as to rollback the swaption and the swap
together...maybe?  Could I be of any help?

>-- Messaggio Originale --
>From: Luigi Ballabio <[hidden email]>
>To: Luca Berardi <[hidden email]>
>Cc: [hidden email]
>Subject: [Quantlib-users] Bermudan swaption patch (was Re: Possible problem
>on bermuda
> swaptions)
>Date: Thu, 24 Feb 2005 11:17:54 +0000
>
>
>
>On 02/24/05 11:52:05, Luca Berardi wrote:
>>
>> >Instead, the problem in the new release seems to be some date
>> >synchronization: namely, due to date adjustment it may happens that an
>> >exercise date is one or two days earlier than a fixed-coupon payment.
>>
>> This is an extremely interesting issue, and I had the chance to
>> discuss it thoroughly with a trader recently. He explained to me that
>> the very successive cashflow of the underlying swap after the exercise
>> date should NEVER be considered in the bermuda swaption pricing.
>
>Yes, that is the correct behavior. The following patch (tested on the
>BermudanSwaption example, which did give different results in 0.3.7 and

>
>0.3.8---somehow this escaped testing) should fix this; you can try and

>apply it to the QuantLib 0.3.8 sources to see if you get the correct
>figures.
>
>Later,
> Luigi
>
>diff -r -C 3 QuantLib-0.3.8/ql/Instruments/swaption.cpp QuantLib-0.3.8-

>patched/ql/Instruments/swaption.cpp
>*** QuantLib-0.3.8/ql/Instruments/swaption.cpp Mon Oct 25 16:00:28 2004
>--- QuantLib-0.3.8-patched/ql/Instruments/swaption.cpp Thu Feb 24 10:53:17
>
>2005
>***************
>*** 85,90 ****
>--- 85,120 ----
>                     "fair swap rate null or not set");
>          QL_REQUIRE(fixedBPS != Null<Real>(),
>                     "fixed swap BPS null or not set");
>+     }
>+
>+     namespace {
>+
>+         inline bool withinPreviousWeek(Time t1, Time t2) {
>+             static const Time dt = 1.0/52;
>+             return t1-dt <= t2 && t2 <= t1;
>+         }
>+
>+         inline bool withinNextWeek(Time t1, Time t2) {
>+             static const Time dt = 1.0/52;
>+             return t1 <= t2 && t2 <= t1+dt;
>+         }
>+
>+     }
>+
>+     void Swaption::arguments::adjust() {
>+         // Date adjustments can get time vectors out of synch.
>+         // Here, we try and collapse similar dates.
>+         for (Size i=0; i<stoppingTimes.size(); i++) {
>+             Time exercise = stoppingTimes[i];
>+             for (Size j=0; j<fixedPayTimes.size(); j++){
>+                 if (withinNextWeek(exercise, fixedPayTimes[j]))
>+                     fixedPayTimes[j] = exercise;
>+             }
>+             for (Size k=0; k<floatingResetTimes.size(); k++) {
>+                 if (withinPreviousWeek(exercise,floatingResetTimes[k]))
>+                     floatingResetTimes[k] = exercise;
>+             }
>+         }
>      }
>
>  }
>diff -r -C 3 QuantLib-0.3.8/ql/Instruments/swaption.hpp QuantLib-0.3.8-

>patched/ql/Instruments/swaption.hpp
>*** QuantLib-0.3.8/ql/Instruments/swaption.hpp Fri Sep 17 12:05:42 2004
>--- QuantLib-0.3.8-patched/ql/Instruments/swaption.hpp Thu Feb 24 10:36:14
>
>2005
>***************
>*** 77,82 ****
>--- 77,83 ----
>  //        Exercise::Type exerciseType;
>  //        std::vector<Time> exerciseTimes;
>          void validate() const;
>+         void adjust();
>      };
>
>      //! %Results from swaption calculation
>diff -r -C 3 QuantLib-0.3.8/ql/argsandresults.hpp QuantLib-0.3.8-patched/
>
>ql/argsandresults.hpp
>*** QuantLib-0.3.8/ql/argsandresults.hpp Wed Apr 21 17:00:26 2004
>--- QuantLib-0.3.8-patched/ql/argsandresults.hpp Thu Feb 24 10:30:49
>2005
>***************
>*** 36,41 ****
>--- 36,42 ----
>        public:
>          virtual ~Arguments() {}
>          virtual void validate() const = 0;
>+         virtual void adjust() {}
>      };
>
>      //! base class for generic result groups
>diff -r -C 3 QuantLib-0.3.8/ql/instrument.hpp QuantLib-0.3.8-patched/ql/
>
>instrument.hpp
>*** QuantLib-0.3.8/ql/instrument.hpp Fri Sep 17 12:05:40 2004
>--- QuantLib-0.3.8-patched/ql/instrument.hpp Thu Feb 24 10:31:10 2005
>***************
>*** 137,142 ****
>--- 137,143 ----
>          engine_->reset();
>          setupArguments(engine_->arguments());
>          engine_->arguments()->validate();
>+         engine_->arguments()->adjust();
>          engine_->calculate();
>          const Value* results = dynamic_cast<const Value*>(engine_-
>>results());
>          QL_ENSURE(results != 0,
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
><a href="http://ads.osdn.com/?ad_ide95&alloc_id396&op=click">http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

__________________________________________________________________
Tiscali Adsl 3 Mega Flat, 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi in Rete alla supervelocita'
a soli 29.95 euro al mese senza limiti di tempo. Attivati entro
il 28 Febbraio 2005, 3 MESI sono GRATIS
Scopri come http://abbonati.tiscali.it/adsl/sa/2flat_tc/

[Luigi Ballabio]

On 02/24/05 15:05:24, Luca Berardi wrote:

>
> Luigi, thanks for the mail. I had quick look at the patch and have
> some comments:
>
> 1) you are silently assuming that exercise dates coincide with payment
>    dates of the underlying swap. Of course there might be some
>    de-synchronization due to dates adjustment as you pointed out, but
>    still it's not possible to deal with cases where the exercise dates
>    are quite different from the swap's payment dates. The trader I
>    talked to, told me that usually exercise dates are ten (business)
>    days before the payment dates of the underlying swap, and with the
>    adjustment carried out through the  new adjust() method you cannot
>    take into account such a long temporal shift. Of course it could be
>    possible to extend the adjustment for a period longer than a week,
>    but then you get a mispricing due to moving payment dates to
>    exercise dates. In general it would be nice not to require that
>    exercise dates must "roughly" coincide with the dates in the
>    underlying swap's schedule.

Yes. The point of the patch was more to avoid mispricing in the current  
state of affairs---exercise dates some days in the past should be treated  
differently.

> 2) It's ok to shift backwards the payment dates of the fixed leg to
>    match the exercise dates, but why do you need to shift the fixing
>    dates of the floating leg forward (again to match the nearest
>    exercise date)?

Because due to the way the floating-leg coupons are priced on the tree,  
during rollback they are added to the swap at their fixing date rather than  
at their payment date. A fixing date two days before an exercise date  
refers to a payment happening six months or one year later, which is  
included in the swap the option holder is possibly entering into. If the  
date is not corrected, the exercise condition is applied before adding such  
payment.

> Still on the exercise dates issue:
>
> Assume for simplicity that the floating and fixed leg of the
> underlying swap have the same schedule. In pricing the bermuda
> swaption one should discard the very successive payment after the
> current exercise date.
> If the floating and fixed leg have different schedules (e.g. funding
> leg pays quarterly and fixed annually) things get more complicated
> because all the swap cashflows following the current exercise dates
> must be discarded until we reach the second cashflow of the lower
> frequency leg.

Why the second cashflow? Let's say you have a swaption with exercise today  
(Feb. 24, 2005) and the underlying swap paying annual fixed coupons and  
receiving quarterly floating coupons. It is my understanding that if the  
swaption were exercised, the holder would enter in a swap starting today;  
i.e., he will not receive or pay coupons today (or the next few days) but  
he will indeed receive floating payments in May 2005, August 2005, November  
2005 and February 2006, and pay a fixed coupon in February 2006. Do you  
think otherwise?

Later,
        Luigi

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

Quote me as saying I was misquoted.
-- Groucho Marx

[Luigi Ballabio]

Oops, I forgot.

On 02/24/05 15:05:24, Luca Berardi wrote:
>
> 1) you are silently assuming that exercise dates coincide with payment
>    dates of the underlying swap.

Did you have a chance to use the patched library with your own code? In the  
above approximation, do you obtain the right figures?

> I realize that getting things working correctly (should my
> interpretation be indeed correct) is not an easy task in the current
> framework. This is because the DiscretizedSwaption does not know of
> the underlying swap's cashflows. A possible workaround would be to
> rewrite the pricing engine as to rollback the swaption and the swap
> together...maybe?  Could I be of any help?

It would require some thought. You're welcome to give it a try.

Later,
        Luigi

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

Humphrey's Requirements Uncertainty Principle:
        For a new software system, the requirements will not be completely
        known until after the users have used it.

[Luca Berardi]

You are right. But again you are assuming  that exercise dates coincide with
payment dates of the swap. Let us generalize this a bit.
Assume for example to have a bermuda swaption written on a swap, issue date
5/3/04, fixed leg: annual, floating leg: semi-annual and assume today 25/2/05
is an exercise date. In valuing the swaption you have to consider the swap
starting 5/3/05, hence having first floating coupon at 5/9/05 and first fixed
coupon at 5/3/06.
This is what the trader of mine told me, also explaining that ten (business
days, actually) are standard for settlement operations between the two counterparts.

> Still on the exercise dates issue:
>
> Assume for simplicity that the floating and fixed leg of the
> underlying swap have the same schedule. In pricing the bermuda
> swaption one should discard the very successive payment after the
> current exercise date.
> If the floating and fixed leg have different schedules (e.g. funding
> leg pays quarterly and fixed annually) things get more complicated
> because all the swap cashflows following the current exercise dates
> must be discarded until we reach the second cashflow of the lower
> frequency leg.

Why the second cashflow? Let's say you have a swaption with exercise today

(Feb. 24, 2005) and the underlying swap paying annual fixed coupons and

receiving quarterly floating coupons. It is my understanding that if the

swaption were exercised, the holder would enter in a swap starting today;

i.e., he will not receive or pay coupons today (or the next few days) but

he will indeed receive floating payments in May 2005, August 2005, November

2005 and February 2006, and pay a fixed coupon in February 2006. Do you

think otherwise?

Later,
        Luigi

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

Quote me as saying I was misquoted.
-- Groucho Marx




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
<a href="http://ads.osdn.com/?ad_ide95&alloc_id396&op=click">http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users


__________________________________________________________________
Tiscali Adsl 3 Mega Flat, 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi in Rete alla supervelocita'
a soli 29.95 euro al mese senza limiti di tempo. Attivati entro
il 28 Febbraio 2005, 3 MESI sono GRATIS
Scopri come http://abbonati.tiscali.it/adsl/sa/2flat_tc/

[Luca Berardi]

Hi

I have a question on the new Lattice implementation, regarding the
rollback method:

- in QuantLib 0.3.7 in the implementation of the rollAlmostBack()
  method we have the following lines of code:

00082         for (Integer i=iFrom-1; i>=iTo; i--) {
00083             Array newValues(size(i));
00084             stepback(i, asset->values(), newValues);
00085             asset->time() = t_[i];
00086             asset->values() = newValues;
00087             // skip the very last post-adjustment
00088             if (i != iTo)
00089                 asset->adjustValues();
00090             else
00091                 asset->preAdjustValues();
00092         }
00093     }

- in QuantLib 0.3.8, in the implementation of partialRollBack() -which
  replaces rollAlmostBack- we have the following lines of code:

00077         for (Integer i=iFrom-1; i>=iTo; i--) {
00078             Array newValues(size(i));
00079             stepback(i, asset.values(), newValues);
00080             asset.time() = t_[i];
00081             asset.values() = newValues;
00082             // skip the very last adjustment
00083             if (i != iTo)
00084                 asset.adjustValues();
00085         }
00086     }

It seems that the 'else' section of code has been thrown away, while
the implementation of the rollBack() method has remained the same
between the two releases.

Is there any particular reason for this? Shouldn't it be a source of
mismatch between the two QuantLib releases?

Ciao,
Luca



__________________________________________________________________
Tiscali Adsl 3 Mega Flat, 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi in Rete alla supervelocita'
a soli 29.95 euro al mese senza limiti di tempo. Attivati entro
il 28 Febbraio 2005, 3 MESI sono GRATIS
Scopri come http://abbonati.tiscali.it/adsl/sa/2flat_tc/

[Luigi Ballabio]

On 02/25/05 11:53:12, Luca Berardi wrote:

>
> I have a question on the new Lattice implementation, regarding the
> rollback method:
>
> - in QuantLib 0.3.7 in the implementation of the rollAlmostBack()
>   method we have the following lines of code:
>
> 00082         for (Integer i=iFrom-1; i>=iTo; i--) {
> 00083             Array newValues(size(i));
> 00084             stepback(i, asset->values(), newValues);
> 00085             asset->time() = t_[i];
> 00086             asset->values() = newValues;
> 00087             // skip the very last post-adjustment
> 00088             if (i != iTo)
> 00089                 asset->adjustValues();
> 00090             else
> 00091                 asset->preAdjustValues();
> 00092         }
> 00093     }
>
> - in QuantLib 0.3.8, in the implementation of partialRollBack() -which
>   replaces rollAlmostBack- we have the following lines of code:
>
> 00077         for (Integer i=iFrom-1; i>=iTo; i--) {
> 00078             Array newValues(size(i));
> 00079             stepback(i, asset.values(), newValues);
> 00080             asset.time() = t_[i];
> 00081             asset.values() = newValues;
> 00082             // skip the very last adjustment
> 00083             if (i != iTo)
> 00084                 asset.adjustValues();
> 00085         }
> 00086     }
>
> It seems that the 'else' section of code has been thrown away, while
> the implementation of the rollBack() method has remained the same
> between the two releases.
>
> Is there any particular reason for this? Shouldn't it be a source of
> mismatch between the two QuantLib releases?

Luca,
        apologies---this should have been documented better. Upon migrating  
between the two releases, client code should be modified (which has been  
done in the library, so there's no mismatch due to the change.) See for  
example DiscretizedOption::postAdjustValues(): the 0.3.7 version is:

    void DiscretizedOption::postAdjustValues() {
        method()->rollAlmostBack(underlying_, time());
        switch (exerciseType_) {
          ...
    }

while the 0.3.8 version is:

    void DiscretizedOption::postAdjustValuesImpl() {
        underlying_->partialRollback(time());
        underlying_->preAdjustValues();
        switch (exerciseType_) {
          ...
    }

I'm sure there is a reason for this, but I can't recall it right now. :)
The purpose seems to be that of allowing behavior to be inserted between  
rollback and pre-adjustment, which isn't bad...

Later,
        Luigi

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

Though this be madness, yet there is method in't.
-- Hamlet, Act II, scene II

[Luca Berardi]

Hi Luigi

I have probably found the source of mispricing in bermuda
swaptions. The problem seems to lie in the new implementation of the
class DiscretizedSwap in QuantLib 0.3.8: in fact the DiscretizedSwap
now updates itself in the following way:
- fixed leg: the fixed coupons are added on the payment dates
- floating leg: the floating coupons are added on the fixing dates.

In QL 0.3.7, instead, the DiscretizedSwap updates both the fixed and
floating leg on the fixing dates.

When pricing a swap with lattices, whether a fixed leg is updated on
payment or fixing dates is just the same, but it does make a
difference when pricing bermuda swaptions.  In fact assume to have a
call date at March 1st 2005 and fixing and payment dates (coincident,
for simplicity) of the underlying swap on March 15th.
When rolling back the the swap over the tree we eventually get to
March 1st 2005, and here the swaption apply the exercise condition:
swaption = MAX(discount*previous_swaption_value,value_of_underlying_swap)


But THEN the value of the underlying swap is not correct: indeed the
fixed leg has been updated, since the fixed coupon payment on March
15th has been included, while the floating leg has not been updated
yet, since the floating coupon -to be payed on March 15th 2015- will
be included when the swap is rolled back to March 15th 2014,
i.e. on its corresponding fixing date.
Hence the current implementation of QuantLib bermudan swaptions
overweigths the fixed leg of the underlying swap, clearly bearing a
mispricing.

The problem could be easily fixed by letting the fixed leg of the swap
to be updated on fixing dates, too (which is how things are set in
QuantLib 0.3.7). This also enables to discard the first payment after
the exercise date, which was the issue I raised few messages ago.

Ciao,
Luca


__________________________________________________________________
Tiscali Adsl 3 Mega Flat con 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi con la supervelocita'
a soli 29.95 euro al mese, senza limiti di tempo. E se attivi
entro il 15 Marzo, 3 MESI sono GRATIS!
Scopri come su http://abbonati.tiscali.it/adsl/

[Luigi Ballabio]

On 03/01/05 18:25:17, Luca Berardi wrote:

>
> I have probably found the source of mispricing in bermuda
> swaptions. The problem seems to lie in the new implementation of the
> class DiscretizedSwap in QuantLib 0.3.8: in fact the DiscretizedSwap
> now updates itself in the following way:
> - fixed leg: the fixed coupons are added on the payment dates
> - floating leg: the floating coupons are added on the fixing dates.
>
> In QL 0.3.7, instead, the DiscretizedSwap updates both the fixed and
> floating leg on the fixing dates.

[snipped]

> The problem could be easily fixed by letting the fixed leg of the swap
> to be updated on fixing dates, too (which is how things are set in
> QuantLib 0.3.7). This also enables to discard the first payment after
> the exercise date, which was the issue I raised few messages ago.

Luca,
        it's not a bug, it's unstated requirements :)  When the exercise  
date coincides with the coupon dates, the pricing is correct either way.

However: yes, adding fixed coupons at their reset dates could make it  
easier to implement the exercise lag. But it would not solve the general  
problem. Take a swap paying fixed coupons in March and floating-rate  
coupons in March, June, September and December. Make it the underlying of a  
swaption with exercise date in September. According to your trader's specs,  
the first payment after exercise should be next March; but the current  
implementation (even modifying the fixed-coupon management) would include  
the floating-rate payment in December. Getting the correct start date for  
the underlying swap does require explicit coding.

Later,
        Luigi

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

Newton's Law of Gravitation:
        What goes up must come down.  But don't expect it to come down
        where you can find it.  Murphy's Law applies to Newton's.

[Luca Berardi]

Luigi,

> it's not a bug, it's unstated requirements :)

I'm not sure I understand...what is the purpose of updating the fixed
leg on payment dates and the floating leg on fixing dates? Am I missin
something?

>When the exercise
>date coincides with the coupon dates, the pricing is correct either way.

Yes, provided you apply the patch to synchronize the dates. But even
in this case we are introducing a (very) small error due to dates
shifting, aren't we?

>However: yes, adding fixed coupons at their reset dates could make it
>easier to implement the exercise lag. But it would not solve the general
>problem.

I do agree, but for practical purposes it doesn't matter. In fact
usually exercise dates are few days (e.g. ten) before the dates where
both the fixed and floating leg of the underlying swap pay (so I'm
told). I know it was me to raise the general issue, but these are
quants' fluffs traders do not care about :)

> Getting the correct start date for
>the underlying swap does require explicit coding.

However I've written a pricer to address the general issue (i.e. no
particular constraints on exercise dates) but here again it relies on
a modified version of DiscretizedSwap being updated on PAYMENT dates
(both fixed and floating leg). I might contribute this piece of code,
if you are interested, once the already mentioned legal issues are
solved.

Ciao,
Luca



__________________________________________________________________
Tiscali Adsl 3 Mega Flat con 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi con la supervelocita'
a soli 29.95 euro al mese, senza limiti di tempo. E se attivi
entro il 15 Marzo, 3 MESI sono GRATIS!
Scopri come su http://abbonati.tiscali.it/adsl/

[Luigi Ballabio]

On 03/02/05 15:17:04, Luca Berardi wrote:
>
> I'm not sure I understand...what is the purpose of updating the fixed
> leg on payment dates and the floating leg on fixing dates? Am I missin
> something?

As for floating-coupons, and unless I'm missing something, they can only be  
updated that way since they are calculated by rolling a discount bond back.  
Fixed coupons can be updated both ways; but it is simpler and more  
efficient to add their amount directly on payment date than to roll another  
discount bond back, multiply the result by the coupon amount and add it.

> >When the exercise
> >date coincides with the coupon dates, the pricing is correct either way.
>
> Yes, provided you apply the patch to synchronize the dates. But even
> in this case we are introducing a (very) small error due to dates
> shifting, aren't we?

Yes, we are.
(on a related note: date shifting might not go away completely. When there  
is no exercise lag, we still have to make sure that the reset dates of the  
coupons we do want to include do not fall before the exercise)

> >However: yes, adding fixed coupons at their reset dates could make it
> >easier to implement the exercise lag. But it would not solve the general
> >problem.
>
> I do agree, but for practical purposes it doesn't matter. In fact
> usually exercise dates are few days (e.g. ten) before the dates where
> both the fixed and floating leg of the underlying swap pay (so I'm
> told).

Yes, that's all I ever saw too.

Later,
        Luigi

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

Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away.
-- Antoine de Saint-Exupery