A few questions about PiecewiseFlatForward

[Michele Ravani-2]

Hi

I was reading through the code of PiecewiseFlatForward and I have a few
questions:

* Wouldn't it be slightly more efficient to check the condition 'same
maturity date' in the rate helper? Any sorting algorithm should guarantee
that the condition expressed in the function used for the comparison of the
vector elements holds for all of them. The exception could be thrown by the
helper.

* The class takes a reference to a vector of RateHelper handles
owned by another part of the program.

One can change a rate value (obvious), but also one of the vector
items, i.e. substitute an element for another or add another one.
After receiving the notification of a change PiecewiseFlatForward would
bootstrap at the first chance, but at this point there is not guarantee
that the instruments vector is still sorted or doesn't contain instruments
with the same date. Am I missing something?

I know it is a bit extreme, but for instance in a YC server where a
user or another server can request (and change) a 'personal' YC such a
situation could arise.

Ciao

--
Michele Ravani                  [hidden email]
"Those who live hoping, die singing" My Gran

[Michele Ravani-2]

On Fri, 27 Sep 2002 00:16:53 +0200 (CEST) Michele Ravani <[hidden email]> wrote:

MR>
MR> * Wouldn't it be slightly more efficient to check the condition 'same
MR> maturity date' in the rate helper? Any sorting algorithm should

I meant 'RateHelperSolver'

--
Michele Ravani                  [hidden email]
"Those who live hoping, die singing" My Gran

[Luigi Ballabio-2]

Ciao Michele,

At 12:16 AM 9/27/02 +0200, Michele Ravani wrote:
>I was reading through the code of PiecewiseFlatForward and I have a few
>questions:
>
>* Wouldn't it be slightly more efficient to check the condition 'same
>maturity date' in the RateHelperSorter?

Maybe. Which actually means "I don't know." We would save a loop, but we
would add a specific check for equality into RateHelperSorter besides the
present less-than comparison. During the sort, the added check would be
executed N*log(N) times, as opposed to the N times in the present loop.
Really, I don't know. Also, I'm inclined to think that the time saved would
be just a small fraction of the time spent in the bootstrapping proper. Of
course I might be wrong, but as for me, this is the kind of optimizations
that I usually perform only after seeing the output of a profiler...


>* The class takes a reference to a vector of RateHelper handles
>owned by another part of the program.
>
>One can change a rate value (obvious), but also one of the vector
>items, i.e. substitute an element for another or add another one.
>After receiving the notification of a change PiecewiseFlatForward would
>bootstrap at the first chance, but at this point there is not guarantee
>that the instruments vector is still sorted or doesn't contain instruments
>with the same date. Am I missing something?

Yes. The constructor takes a const ref to the vector and _copies_ it. If
one adds/removes/replaces an element in the original vector, this won't
affect the term structure.

Bye for now,
                 Luigi

[Ravani, Michele]

Ciao

> >* Wouldn't it be slightly more efficient to check the condition 'same
> >maturity date' in the RateHelperSorter?
>
> Maybe. Which actually means "I don't know." We would save a
> loop, but we
[snip]
> optimizations
> that I usually perform only after seeing the output of a profiler...

I agree, it was more an academic and kind of aesthetic :o) question

> >* The class takes a reference to a vector of RateHelper handles
> >owned by another part of the program.
[snip]
> Yes. The constructor takes a const ref to the vector and
> _copies_ it. If
> one adds/removes/replaces an element in the original vector,
> this won't
> affect the term structure.

Yes, I completely missed the fact that the member variable instruments_ is an actual copy.
This also means that the TermStructure is constant in terms of composition after being created.
I've come across a few times the need to keep it flexible from this point of view, but it should be rather easy to implement if necessary.

Ciao

"MMS <csfb.com>" made the following
 annotations on 09/27/02 10:35:52
------------------------------------------------------------------------------
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve the right to monitor all e-mail communications through its networks.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted.
Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.


==============================================================================

[Luigi Ballabio-2]

At 10:35 AM 9/27/02 +0200, Ravani, Michele wrote:
>Yes, I completely missed the fact that the member variable instruments_ is
>an actual copy.
>This also means that the TermStructure is constant in terms of composition
>after being created.

True. However, this is somehow compensated by the fact that instruments
usually take a relinkable handle, thus allowing one to do:

RelinkableHandle<TermStructure> h;
SomeInstrument i(..., h, ...);
// here the instrument cannot be priced yet---no actual term structure

std::vector<Handle<RateHelper> > v1;
... // compose v1
h.linkTo(Handle<TermStructure>(new PiecewiseFlatForward(..., v1, ...));

// ok, now the instrument uses the piecewise flat forward we just created
std::cout << i.NPV() << std::endl;

// need to change the composition?
std::vector<Handle<RateHelper> > v2; // or reuse v1 if you want
... // compose v2 or change v1
h.linkTo(Handle<TermStructure>(new PiecewiseFlatForward(..., v2, ...));

// now the instrument will use the new term structure
std::cout << i.NPV() << std::endl;

Bye,
         Luigi