lballabio / quantlib-old

The QuantLib C++ library and extensions (warning: out of date)
http://quantlib.org
471 stars 405 forks source link

Expose additional methods for VanillaSwap in SWIG #335

Closed gouthambs closed 9 years ago

gouthambs commented 9 years ago

Currently a limited set of methods are exposed for VanillaSwap in SWIG. For instance, methods such as floatingLeg and fixedLeg available in C++ are nicer to use than leg[0] and leg[1] exposed currently. This issue is to address these shortcomings.

I can take a stab at working on this issue if there is some interest to take PR.

lballabio commented 9 years ago

Yes, I'll take the PR.

gouthambs commented 9 years ago

@lballabio I wrapped some of the methods in VanillaSwap and I am able to call them from python. For instance, I have wrapped the floatingDayCount as shown below:

const DayCounter& floatingDayCount() {
    return boost::dynamic_pointer_cast<VanillaSwap> (*self)
     ->floatingDayCount();
}

Now, when I inspect the floatingDayCount() method from the VanillaSwap object, I get this:

<QuantLib.QuantLib.DayCounter; proxy of <Swig Object of type 'DayCounter *' at 0x03897D40> >

If I inspect the floating day count object that was originally passed into the VanillaSwap constructor, I get this:

<QuantLib.QuantLib.Actual360; proxy of <Swig Object of type 'QuantLib::Actual360 *' at 0x037FF668> 

I was expecting the inspection of the two to give me identical results since internally they are all references.

Do you know if this some SWIG idiosyncrasy that I am not understanding right? Or is this some issue to be concerned?

My guess is that the difference arises from the fact that latter is a Actual360 object, and the former is cast to its base class. Any light you could shed would be helpful.

lballabio commented 9 years ago

That's to be expected. When you pass the original Actual360 instance, the swap makes a copy (it doesn't take a reference) and stores it as a DayCounter instance. That's what you're seeing returned.