Swap Ratehelper

[Andre Louw-2]

Hi,

I notice that SwapRateHelper gets constructed explicitly on Year bounds. I
realize it's done this way because of  the market convention, but I would
like the functionality of using non-market specified quotes to bootstrap
off.

Is there someone with a strong feeling against making it a bit more
flexible, ie keep the current constructor but add a 'units_' member (which
defaults to Years for the current constructor), which can be specified in a
seperate constructor?

Andre
 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

[Ferdinando M. Ametrano-2]

At 02:16 PM 4/30/2002 +0200, you wrote:
>I notice that SwapRateHelper gets constructed explicitly on Year bounds. I
>realize it's done this way because of  the market convention, but I would
>like the functionality of using non-market specified quotes to bootstrap
>off.
>
>Is there someone with a strong feeling against making it a bit more
>flexible, ie keep the current constructor but add a 'units_' member (which
>defaults to Years for the current constructor), which can be specified in a
>seperate constructor?
for me it's OK, as long as it wraps Instruments::SimpleSwap and it is an
additional constructor

ciao -- Nando

[Luigi Ballabio-4]

At 03:54 PM 4/30/02 +0200, Andre Louw wrote:
>Luigi,
> > I don't have a strong feeling against adding units to the present
> > constructor, either. It's not that big an inconvenience
>
>Except for everybody using it currently?

This is true. However, it is also true that a) I'd like to think that at
release 0.3.0 we are still free to change our minds if we see a drawback in
our earlier choices, and b) last week we changed the TermStructure
interface and the PiecewiseFlatForward constructor; users already have to
change their scripts, and this change might be just another epsilon. Then
again, I'm not suggesting this as the standard process.

>I suppose you can add the units to the end of the parm-list with an
>initialised value of 'Years', but that's not very neat, I would prefer to
>have it next to the number-of-units?
>What's the QuantLib dev community's general rule-of-thumb, I'm used to
>adding a new constructor (minimising the influence on existing codes)?

As for me, no rule-of-thumb valid for all cases. There are times when
multiple constructors give me the feeling that a class is trying to do too
much and should be refactored. However, this is not the case since it is
just a matter of default arguments; I would add a new constructor with the
parameters in the right order and maybe deprecate the old one in order to
remove it in the next release. The latter would depend on this release
being 0.3.0: were it closer to 1.0, I'd leave the old constructor alone.
Also, I would put the common initialization code in a private initialize()
method that both constructors would call, much like you did with the
CompoundForward constructors.

Anyway, mine is just one vote, and we are quite a few now.

Bye,
         Luigi

[Luigi Ballabio-4]

At 02:16 PM 4/30/02 +0200, Andre Louw wrote:
>I notice that SwapRateHelper gets constructed explicitly on Year bounds. I
>realize it's done this way because of  the market convention, but I would
>like the functionality of using non-market specified quotes to bootstrap
>off.
>
>Is there someone with a strong feeling against making it a bit more
>flexible, ie keep the current constructor but add a 'units_' member (which
>defaults to Years for the current constructor), which can be specified in a
>seperate constructor?

I don't have a strong feeling against adding units to the present
constructor, either. It's not that big an inconvenience (and as for my
personal taste, I prefer not to have multiple constructors with a lot of
parameters---one never knows at a glance what one is instantiating)

Bye,
         Luigi

[Ferdinando M. Ametrano-2]

At 07:08 PM 4/30/2002 +0100, Luigi Ballabio wrote:
>I'd like to think that at release 0.3.0 we are still free to change our
>minds if we see a drawback in our earlier choices
Sure! On of the reason this dev list exists is to have here the guys who
actually develop and use QuantLib. QuantLib must fit our needs, so as long
as it's OK for us I wouldn't mind about generic potential complaints

>I would add a new constructor with the parameters in the right order and
>maybe deprecate the old one in order to remove it in the next release. [...]
>Also, I would put the common initialization code in a private initialize()
>method that both constructors would call, much like you did with the
>CompoundForward constructors.
OK

>Anyway, mine is just one vote, and we are quite a few now.
but you know very well that not all votes are equally weighted, and your
vote deserves quite a high weight ;-)

ciao -- Nando