Some thoughts.

[a akpitidis]

Hi ,

 

I tried to add to 8.0 the CAD vanilla swaps for the curve building and i came across with some design issues, mainlly because i don't want to change existing modules of the library.  However, i want to reuse most of the core code.

 

It turn out that i have no option but i need to either change existing modules or replicate existing code to new modules.

 

In my mind someone who wants to extend a library shouldn't have to change existing files, but the library needs to provide the appropriate hooks (i.e. interfaces, template classes/functions  and so on).  At the same time, as we all know, that takes time and effort, and in the main time the DIY solution fits most clients :).

 

Here are some sugestions for the future:

 

1. Create a template class VanillaSwapG ( G for generic), the coupontype should be the template parameters and they should be propagated down to the construction of the floating leg.

 

2. A typedef will define the existing VanillaSwap class.

 

3. Those template arguments should be propagated upwards to MakeVanillaSwap and SwapRateHelper.

 

4. Finally, i need to be able to hook my own code into the

SwapRateHelper::initializeDates  as i need to set the custom floating leg tenor, which is different from the index tenor.  Then again that extra information needs to come from somewhere, but then i need to have my new SwapRateHelper class, but i don't want to copy existing code.

 

Any thoughts? 

Who decides what changes go into repository?

I really like the library, but i need to be able to enhance it, so it does what i want to do and at the same time i don't want to redo the changes everytime a new release comes up.

 

Regards

Tasos

 

 

 

---

Sent from Yahoo! Mail.
The World 's Favourite Email.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

Hi Tasos

it might help to know in more details what kind of problems you had,
otherwise it is harder to provide feedback about your suggestions.
Anyway I anticipate my guess/suggestion. You might write your own
CADSwapHelper deriving from RateHelper or SwapHelper and and wrap in
that RateHelper your custom Swap.
The VanillaSwap is just an helper class, for fully customized swap you
should use the Swap class.

Finally: if you can contribute your modifications they could go in the
code base and you would not have to apply them to each release ;-)

ciao -- Nando

On Thu, Mar 6, 2008 at 7:10 PM, a akpitidis <[hidden email]> wrote:

> Hi ,
>
> I tried to add to 8.0 the CAD vanilla swaps for the curve building and i
> came across with some design issues, mainlly because i don't want to change
> existing modules of the library.  However, i want to reuse most of the core
> code.
>
> It turn out that i have no option but i need to either change existing
> modules or replicate existing code to new modules.
>
> In my mind someone who wants to extend a library shouldn't have to change
> existing files, but the library needs to provide the appropriate hooks (i.e.
> interfaces, template classes/functions  and so on).  At the same time, as we
> all know, that takes time and effort, and in the main time the DIY solution
> fits most clients :).
>
> Here are some sugestions for the future:
>
> 1. Create a template class VanillaSwapG ( G for generic), the coupontype
> should be the template parameters and they should be propagated down to the
> construction of the floating leg.
>
> 2. A typedef will define the existing VanillaSwap class.
>
> 3. Those template arguments should be propagated upwards to MakeVanillaSwap
> and SwapRateHelper.
>
> 4. Finally, i need to be able to hook my own code into the
> SwapRateHelper::initializeDates  as i need to set the custom floating leg
> tenor, which is different from the index tenor.  Then again that extra
> information needs to come from somewhere, but then i need to have my new
> SwapRateHelper class, but i don't want to copy existing code.
>
> Any thoughts?
> Who decides what changes go into repository?
> I really like the library, but i need to be able to enhance it, so it does
> what i want to do and at the same time i don't want to redo the changes
> everytime a new release comes up.
>
> Regards
> Tasos
>
>
>
>
>
>  ________________________________
>  Sent from Yahoo! Mail.
>  The World 's Favourite Email.
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
>  QuantLib-dev mailing list
>  [hidden email]
>  https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Thu, 2008-03-06 at 18:10 +0000, a akpitidis wrote:
> I tried to add to 8.0 the CAD vanilla swaps for the curve building and
> i came across with some design issues, mainlly because i don't want to
> change existing modules of the library.  However, i want to reuse most
> of the core code.
>  
> In my mind someone who wants to extend a library shouldn't have to
> change existing files, but the library needs to provide the
> appropriate hooks (i.e. interfaces, template classes/functions  and so
> on).

We all agree here. However...

> At the same time, as we all know, that takes time and effort, and in
> the main time the DIY solution fits most clients :).

It's not just that. Generalization can be applied if one knows in what
direction to generalize. For instance, until you wrote about your
problem, I wasn't aware of the CAD convention, not could I have imagined
it. Since early generalization risks going in the wrong direction and
burdening the code with unused abstractions, I prefer waiting for use
cases such as yours and generalize based on actual need.


> Here are some sugestions for the future:
>  
> 1. Create a template class VanillaSwapG ( G for generic), the
> coupontype should be the template parameters and they should be
> propagated down to the construction of the floating leg.
>  
> 3. Those template arguments should be propagated upwards to
> MakeVanillaSwap and SwapRateHelper.

Does your coupon's constructor take the same number of arguments as the
existing IborCoupon? Otherwise, one would also have to generalize coupon
creation so that it has a common interface (we'd probably need some kind
of factory.)


> 4. Finally, i need to be able to hook my own code into the
> SwapRateHelper::initializeDates  as i need to set the custom floating
> leg tenor, which is different from the index tenor.  Then again that
> extra information needs to come from somewhere, but then i need to
> have my new SwapRateHelper class, but i don't want to copy existing
> code.

This kind of hook is already provided by the language. You can inherit
from SwapRatehelper and override SwapRateHelper::initializeDates (you
don't need to copy any code; you can call the parent-class method after
executing the CAD-specific code.) The extra data can go in the derived
class.

Luigi


--

It is always the best policy to tell the truth, unless, of course,
you are an exceptionally good liar.
-- Jerome K. Jerome



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev