QuantLib › quantlib-dev

Why doesn't there exist a QuantLib Leg Hierachy?

Classic

List

Threaded

4 messages Options

Sebastian Poloczek

Why doesn't there exist a QuantLib Leg Hierachy?

Hello,

I've tried to "reconstruct" a QuantLib swap object in another environment (QuantLib Excel). The idea was to use the swap properties (including private ones if necessary) to construct adequate ObjectHandler::ValueObjects, which can be used to "design" the objects in an excel workbook.

After some coding I've recognized that this seems to be impossible (or at least harder than expected) in the current QuantLib environment. The reason is that there is no QuantLib Leg Hierachy in the library. Each Leg is just a vector of cashflow pointers and it is hard to differentiate if a leg was intended to be an iborleg, a fixedrateleg etc.
For example you use the "helper class" fixedrateleg to (temporarely) create a fixedrateleg. As soon, as you pass it to a swap this fixedrateleg is just casted to a vector of cashflowpointers, loosing the information what it was intended to be. I'm wondering why this "design" was choosen.
I suppose that a structure similar to that:

typedef std::vector<boost::shared_ptr<CashFlow> > Leg;

// concrete FixedRateLeg class
class FixedRateLeg : public Leg {
....
}

//! helper class building a FixedRateLeg
class MakeFixedRateLeg {
// similar to current FixedRateLeg helper class
// cast operator on new FixedRateLeg Class instead of Leg:
// operator FixedRateLeg() const;
}

would be in some circumstances superior to the current structure. This is (for example) the way the swap class (with its child vanillaswap) is organized. Is there a special reason that this "thing" Leg did not get an objecthierachy in QuantLib?

Regards
Sebastian

Jan Ladislav Dussek

Re: Why doesn't there exist a QuantLib Leg Hierachy?

I can't speak for the devs, but one issue with your suggestion as written is that it is generally considered a Bad Idea to derive from STL containers (no virtual destructors, e.g.). More to the point, a Leg should properly be a collection of (possibly heterogeneous) cash flows; the "kind" or "type" of leg you are dealing with is determined by properties of the cash flows that it contains. Any other properties you might like a Leg to have depend on its context, i.e., to the instrument (swap in your case) to which it belongs. So really, the design decision was to split the work between the CashFlow hierarchy and the Instrument hierarchy. There is no need to make the Leg class "smarter".

In QuantLibXL, can create new (possibly complicated) constructors (qlIborLeg and qlFixedRateLeg, say) which stores the type of leg you want in the object repository. You can then plug these Leg objects into the IborLeg and FixedRateLeg slots of your swap constructor.

JLD

> Date: Fri, 16 Nov 2012 09:27:37 -0800
> From: [hidden email]
> To: [hidden email]
> Subject: [Quantlib-dev] Why doesn't there exist a QuantLib Leg Hierachy?
>
>
> Hello,
>
> I've tried to "reconstruct" a QuantLib swap object in another environment
> (QuantLib Excel). The idea was to use the swap properties (including private
> ones if necessary) to construct adequate ObjectHandler::ValueObjects, which
> can be used to "design" the objects in an excel workbook.
>
> After some coding I've recognized that this seems to be impossible (or at
> least harder than expected) in the current QuantLib environment. The reason
> is that there is no QuantLib Leg Hierachy in the library. Each Leg is just a
> vector of cashflow pointers and it is hard to differentiate if a leg was
> intended to be an iborleg, a fixedrateleg etc.
> For example you use the "helper class" fixedrateleg to (temporarely) create
> a fixedrateleg. As soon, as you pass it to a swap this fixedrateleg is just
> casted to a vector of cashflowpointers, loosing the information what it was
> intended to be. I'm wondering why this "design" was choosen.
> I suppose that a structure similar to that:
>
> typedef std::vector<boost::shared_ptr<CashFlow>> Leg;
>
> // concrete FixedRateLeg class
> class FixedRateLeg : public Leg {
> ....
> }
>
> //! helper class building a FixedRateLeg
> class MakeFixedRateLeg {
> // similar to current FixedRateLeg helper class
> // cast operator on new FixedRateLeg Class instead of Leg:
> // operator FixedRateLeg() const;
> }
>
> would be in some circumstances superior to the current structure. This is
> (for example) the way the swap class (with its child vanillaswap) is
> organized. Is there a special reason that this "thing" Leg did not get an
> objecthierachy in QuantLib?
>
> Regards
> Sebastian
>
>
>
> --
> View this message in context: http://old.nabble.com/Why-doesn%27t-there-exist-a-QuantLib-Leg-Hierachy--tp34689442p34689442.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Sebastian Poloczek

Re: Why doesn't there exist a QuantLib Leg Hierachy?

Hi Jan,

you are right that deriving from a STL container may be a bad idea. This problem can be circumvented by redefining the Leg (Class) via composition.

What I'm trying to do is (somehow) making a snapshot of a QuantLib environment, e.g. a swap, including legs, pricing engines, market data objects,... . This snapshot should contain enough information to reopen it in an Excel session. In the current QL Leg design the leg type informations are lost after passing (casting) it into a swap instrument.
For example if you want to "export" a simple QL swap including an iborLeg and a FixedRateLeg into Excel a nice result would be a call to three QLXL functions (either just in single cells or including some fancy parameter boxes): qlswap, qlIborLeg, qlFixedRateLeg. But because the swap has lost the information of the underlying leg types this is difficult to achieve.

I imagine that leg type information could also be helpful in other algorithmic tasks.

Regards,
Sebastian

Luigi Ballabio

Re: Why doesn't there exist a QuantLib Leg Hierachy?

Hi Sebastian,
the problem is that we'd like to provide the means to build a
custom leg more or less manually, and that can play havoc with the
types as set in a hierarchy. For instance, if one wants to create a
fixed-to-floater leg and writes:

Leg l = FloatingRateLeg(...);
l[0] = shared_ptr<CashFlow>(new FixedRateCoupon(...));

then you'd have something which is a floating-rate leg in type, but
not in reality. Trying to prevent this would lead to restrict too
much (in my opinion, at least) the interface of Leg. Actually, I
don't even think I would want to prevent the above code...

Luigi

On Sun, Nov 18, 2012 at 10:37 PM, Sebastian Poloczek
<[hidden email]> wrote:

>
> Hi Jan,
>
> you are right that deriving from a STL container may be a bad idea. This
> problem can be circumvented by redefining the Leg (Class) via composition.
>
> What I'm trying to do is (somehow) making a snapshot of a QuantLib
> environment, e.g. a swap, including legs, pricing engines, market data
> objects,... . This snapshot should contain enough information to reopen it
> in an Excel session. In the current QL Leg design the leg type informations
> are lost after passing (casting) it into a swap instrument.
> For example if you want to "export" a simple QL swap including an iborLeg
> and a FixedRateLeg into Excel a nice result would be a call to three QLXL
> functions (either just in single cells or including some fancy parameter
> boxes): qlswap, qlIborLeg, qlFixedRateLeg. But because the swap has lost the
> information of the underlying leg types this is difficult to achieve.
>
> I imagine that leg type information could also be helpful in other
> algorithmic tasks.
>
> Regards,
> Sebastian
> --
> View this message in context: http://old.nabble.com/Why-doesn%27t-there-exist-a-QuantLib-Leg-Hierachy--tp34689442p34694954.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev