QuantLib-Python related issues

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

QuantLib-Python related issues

Ashish Kulkarni-7
Greetings,

I've been working with QuantLib-Python, and I've noted some issues 
related to that.

1] QL-Python doesn't work with SWIG 1.3.22; I initally downloaded that 
(being the latest version) and compilation failed. I didn't go too much 
into the causes, but when I switched to 1.3.21 (the one which was used 
to generate the released version) everything worked smoothly. I tried 
this on a Win2K system, with the prebuilt binary from www.swig.org
Maybe if this is replicated on other systems, we could add a note to the 
documentation mentioning this.

2] The setup.py script in QuantLib-Python does not reference "grid.i", 
which causes it to be missing from the distribution. This problem is 
also present in the latest CVS version; see http://tinyurl.com/49zqh

3] The SWIG sources did not contain the BarrierOption instrument 
(although they did have Barrier::Type), and also a few pricing engines. 
I've added those that I required; some may still be missing.

I've attached a patch for #3 (it's rather trivial) against 
Quantlib-0.3.7, it should work for the CVS version too (behind a 
firewall, cannot access CVS).

BTW, are there any plans to add a Python-specific documentation similiar 
to wxPython using Epydoc? I imagine some change in the SWIG bindings or 
generation options would be needed.

http://www.wxpython.org/docs/api/


It's been real nice working with QuantLib :-)

Regards,
Ashish

-------------------------------------------------------------------
Ashish Kulkarni                
+91-022-55928914               +91-09820549057

"This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively "ICICI Group"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects."


diff -dcr SWIG_old/grid.i SWIG/grid.i
*** /dev/null Tue Nov  2 12:39:22 2004
--- SWIG/grid.i Tue Nov  2 12:39:50 2004
***************
*** 0 ****
--- 1,94 ----
+ /*
+  Copyright (C) 2004 StatPro Italia srl
+
+  This file is part of QuantLib, a free-software/open-source library
+  for financial quantitative analysts and developers - http://quantlib.org/
+
+  QuantLib is free software: you can redistribute it and/or modify it under the
+  terms of the QuantLib license.  You should have received a copy of the
+  license along with this program; if not, please email [hidden email]
+  The license is also available online at http://quantlib.org/html/license.html
+
+  This program is distributed in the hope that it will be useful, but WITHOUT
+  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+  FOR A PARTICULAR PURPOSE.  See the license for more details.
+ */
+
+ #ifndef quantlib_grid_i
+ #define quantlib_grid_i
+
+ %include common.i
+ %include types.i
+ %include stl.i
+
+ %{
+ using QuantLib::TimeGrid;
+ %}
+
+ class TimeGrid : public std::vector<Time> {
+     #if defined(SWIGPYTHON) || defined(SWIGRUBY)
+     %rename(__len__)   size;
+     #elif defined(SWIGMZSCHEME) || defined(SWIGGUILE)
+     %rename("length")  size;
+     #endif
+   public:
+     // empty time-grid
+     TimeGrid() {}
+     // regularly spaced time-grid
+     TimeGrid(Time end, Size steps);
+     %extend {
+         // time-grid with mandatory time points
+         TimeGrid(const std::vector<Time>& times) {
+             return new TimeGrid(times.begin(), times.end());
+         }
+         // time-grid with mandatory time points and steps
+         TimeGrid(const std::vector<Time>& times, Size steps) {
+             return new TimeGrid(times.begin(), times.end(), steps);
+         }
+     }
+     Size size() const;
+     %extend {
+         #if defined(SWIGPYTHON) || defined(SWIGRUBY)
+         Time __getitem__(Integer i) {
+             Integer size_ = static_cast<Integer>(self->size());
+             if (i>=0 && i<size_) {
+                 return (*self)[i];
+             } else if (i<0 && -i<=size_) {
+                 return (*self)[size_+i];
+             } else {
+                 throw std::out_of_range("time-grid index out of range");
+             }
+             QL_DUMMY_RETURN(0.0)
+         }
+         Time dt(Integer i) const {
+             Integer size_ = static_cast<Integer>(self->size());
+             if (i>=0 && i<size_) {
+                 return self->dt(i);
+             } else if (i<0 && -i<=size_) {
+                 return self->dt(size_+i);
+             } else {
+                 throw std::out_of_range("time-grid index out of range");
+             }
+             QL_DUMMY_RETURN(0.0)
+         }
+         #elif defined(SWIGMZSCHEME) || defined(SWIGGUILE)
+         Time ref(Size i) {
+             if (i<self->size())
+                 return (*self)[i];
+             else
+                 throw std::out_of_range("time-grid index out of range");
+             QL_DUMMY_RETURN(0.0)
+         }
+         Time dt(Size i) {
+             if (i<self->size())
+                 return self->dt(i);
+             else
+                 throw std::out_of_range("time-grid index out of range");
+             QL_DUMMY_RETURN(0.0)
+         }
+         #endif
+     }
+ };
+
+
+ #endif
diff -dcr SWIG_old/old_pricers.i SWIG/old_pricers.i
*** SWIG_old/old_pricers.i Wed May 19 13:48:26 2004
--- SWIG/old_pricers.i Tue Nov  2 12:10:14 2004
***************
*** 30,72 ****
  // Analytic pricers
 
  %{
- using QuantLib::Barrier;
- typedef Barrier::Type BarrierType;
-
- BarrierType barrierTypeFromString(std::string s) {
-     s = StringFormatter::toLowercase(s);
-     if (s == "downin")
-         return Barrier::DownIn;
-     else if (s == "downout")
-         return Barrier::DownOut;
-     else if (s == "upin")
-         return Barrier::UpIn;
-     else if (s == "upout")
-         return Barrier::UpOut;
-     else
-         QL_FAIL("unknown barrier type: "+s);
- }
-
- std::string barrierTypeToString(BarrierType t) {
-     switch (t) {
-       case Barrier::DownIn:
-         return "DownIn";
-       case Barrier::DownOut:
-         return "DownOut";
-       case Barrier::UpIn:
-         return "UpIn";
-       case Barrier::UpOut:
-         return "UpOut";
-       default:
-         QL_FAIL("unknown barrier type");
-     }
- }
- %}
-
- MapToString(BarrierType,barrierTypeFromString,barrierTypeToString);
-
-
- %{
  using QuantLib::CliquetOptionPricer;
  %}
 
--- 30,35 ----
diff -dcr SWIG_old/options.i SWIG/options.i
*** SWIG_old/options.i Wed May 12 09:47:04 2004
--- SWIG/options.i Tue Nov  2 12:19:12 2004
***************
*** 57,62 ****
--- 57,99 ----
 
  MapToString(OptionType,optionTypeFromString,optionTypeToString);
 
+ // barrier types
+ %{
+ using QuantLib::Barrier;
+ typedef Barrier::Type BarrierType;
+
+ BarrierType barrierTypeFromString(std::string s) {
+     s = StringFormatter::toLowercase(s);
+     if (s == "downin")
+         return Barrier::DownIn;
+     else if (s == "downout")
+         return Barrier::DownOut;
+     else if (s == "upin")
+         return Barrier::UpIn;
+     else if (s == "upout")
+         return Barrier::UpOut;
+     else
+         QL_FAIL("unknown barrier type: "+s);
+ }
+
+ std::string barrierTypeToString(BarrierType t) {
+     switch (t) {
+       case Barrier::DownIn:
+         return "DownIn";
+       case Barrier::DownOut:
+         return "DownOut";
+       case Barrier::UpIn:
+         return "UpIn";
+       case Barrier::UpOut:
+         return "UpOut";
+       default:
+         QL_FAIL("unknown barrier type");
+     }
+ }
+ %}
+
+ MapToString(BarrierType,barrierTypeFromString,barrierTypeToString);
+
 
  // payoff
 
***************
*** 339,343 ****
--- 376,488 ----
      }
  };
 
+ // Barrier Option
+
+ %{
+ using QuantLib::BarrierOption;
+ typedef boost::shared_ptr<Instrument> BarrierOptionPtr;
+ %}
+
+
+ %rename(BarrierOption) BarrierOptionPtr;
+ class BarrierOptionPtr : public boost::shared_ptr<Instrument> {
+     #if defined(SWIGMZSCHEME) || defined(SWIGGUILE)
+     %rename("dividend-rho")       dividendRho;
+     %rename("implied-volatility") impliedVolatility;
+     #endif
+   public:
+     %extend {
+         BarrierOptionPtr(BarrierType barrierType,
+                 Real barrier,
+                 Real rebate,
+                 const boost::shared_ptr<StochasticProcess>& process,
+                 const boost::shared_ptr<Payoff>& payoff,
+                 const boost::shared_ptr<Exercise>& exercise,
+                 const boost::shared_ptr<PricingEngine>& engine
+                    = boost::shared_ptr<PricingEngine>()) {
+             boost::shared_ptr<StrikedTypePayoff> stPayoff =
+                  boost::dynamic_pointer_cast<StrikedTypePayoff>(payoff);
+             QL_REQUIRE(stPayoff, "wrong payoff given");
+             boost::shared_ptr<BlackScholesProcess> bsProcess =
+                 boost::dynamic_pointer_cast<BlackScholesProcess>(process);
+             QL_REQUIRE(bsProcess, "wrong stochastic process given");
+             return new BarrierOptionPtr(
+                 new BarrierOption(barrierType, barrier, rebate,
+                                   bsProcess,stPayoff,exercise,engine));
+         }
+         Real errorEstimate() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)
+                  ->errorEstimate();
+         }
+         Real delta() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)->delta();
+         }
+         Real gamma() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)->gamma();
+         }
+         Real theta() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)->theta();
+         }
+         Real vega() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)->vega();
+         }
+         Real rho() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)->rho();
+         }
+         Real dividendRho() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)
+                  ->dividendRho();
+         }
+         Real strikeSensitivity() {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)
+                  ->strikeSensitivity();
+         }
+         Volatility impliedVolatility(Real targetValue,
+                                      Real accuracy = 1.0e-4,
+                                      Size maxEvaluations = 100,
+                                      Volatility minVol = 1.0e-4,
+                                      Volatility maxVol = 4.0) {
+             return boost::dynamic_pointer_cast<BarrierOption>(*self)
+                  ->impliedVolatility(targetValue,accuracy,maxEvaluations,
+                                      minVol,maxVol);
+         }
+     }
+ };
+
+ // Barrier Pricing Engine and Analytic Digital Engine
+
+ %{
+ using QuantLib::AnalyticBarrierEngine;
+ typedef boost::shared_ptr<PricingEngine> AnalyticBarrierEnginePtr;
+ %}
+
+ %rename(AnalyticBarrierEngine) AnalyticBarrierEnginePtr;
+ class AnalyticBarrierEnginePtr
+     : public boost::shared_ptr<PricingEngine> {
+   public:
+     %extend {
+         AnalyticBarrierEnginePtr() {
+             return new AnalyticBarrierEnginePtr(
+                 new AnalyticBarrierEngine);
+         }
+     }
+ };
+
+ %{
+ using QuantLib::AnalyticDigitalAmericanEngine;
+ typedef boost::shared_ptr<PricingEngine> AnalyticDigitalAmericanEnginePtr;
+ %}
+
+ %rename(AnalyticDigitalAmericanEngine) AnalyticDigitalAmericanEnginePtr;
+ class AnalyticDigitalAmericanEnginePtr
+     : public boost::shared_ptr<PricingEngine> {
+   public:
+     %extend {
+         AnalyticDigitalAmericanEnginePtr() {
+             return new AnalyticDigitalAmericanEnginePtr(
+                 new AnalyticDigitalAmericanEngine);
+         }
+     }
+ };
 
  #endif
Reply | Threaded
Open this post in threaded view
|

Re: QuantLib-Python related issues

Luigi Ballabio-2
Greetings,

At 10:20 02/11/2004, Ashish Kulkarni wrote:

>I've been working with QuantLib-Python, and I've noted some issues
>related to that.
>
>1] QL-Python doesn't work with SWIG 1.3.22; I initally downloaded that
>(being the latest version) and compilation failed. I didn't go too much
>into the causes, but when I switched to 1.3.21 (the one which was used
>to generate the released version) everything worked smoothly. I tried
>this on a Win2K system, with the prebuilt binary from www.swig.org
>Maybe if this is replicated on other systems, we could add a note to the
>documentation mentioning this.

SWIG 1.3.22 hadn't been released at the time we released QuantLib 0.3.7,
which is why the issue isn't mentioned. The version of QL-Python in CVS
should work with the latest SWIG as far as I recall, but I'll check it.


>2] The setup.py script in QuantLib-Python does not reference "grid.i",
>which causes it to be missing from the distribution. This problem is
>also present in the latest CVS version; see http://tinyurl.com/49zqh

Ouch, right. Thanks.


>3] The SWIG sources did not contain the BarrierOption instrument
>(although they did have Barrier::Type), and also a few pricing engines.
>I've added those that I required; some may still be missing.

Yes, sadly the bindings tend to stay behind the library.

>I've attached a patch for #3 (it's rather trivial) against
>Quantlib-0.3.7, it should work for the CVS version too (behind a
>firewall, cannot access CVS).

Thanks, I'll add them as soon as I get a chance (the box on which I do
QuantLib development is currently down.)


>BTW, are there any plans to add a Python-specific documentation similiar
>to wxPython using Epydoc? I imagine some change in the SWIG bindings or
>generation options would be needed.

Last I heard, someone was working on patching SWIG to generate docstrings
in the bindings. That would allow PyDoc to work some magic. But I don't
know whether that is ready for prime-time.


>It's been real nice working with QuantLib :-)
Thanks,
         Luigi




Reply | Threaded
Open this post in threaded view
|

Re: QuantLib-Python related issues

Ashish Kulkarni-7
hello,

Luigi Ballabio wrote:
[snip]
>> 3] The SWIG sources did not contain the BarrierOption instrument
>> (although they did have Barrier::Type), and also a few pricing engines.
>> I've added those that I required; some may still be missing.
> 
> Yes, sadly the bindings tend to stay behind the library.
> 

I'm willing to take up maintaining the SWIG bindings (although I'll be 
using mostly the Python ones for now). Also, it looks likely that I'll 
be attempting to develop a QuantLib Java/JNI binding for my company 
sometime in the future, which I can (hopefully) contribute back to QuantLib.

>> BTW, are there any plans to add a Python-specific documentation similiar
>> to wxPython using Epydoc? I imagine some change in the SWIG bindings or
>> generation options would be needed.
> 
> Last I heard, someone was working on patching SWIG to generate 
> docstrings in the bindings. That would allow PyDoc to work some magic. 
> But I don't know whether that is ready for prime-time.

The patch for that is already in SWIG CVS; see http://tinyurl.com/3zl9n

BTW, does anyone know when is the release of QuantLib 0.3.8 expected?

Thanks,
Ashish

"This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively "ICICI Group"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects."

Reply | Threaded
Open this post in threaded view
|

Re: QuantLib-Python related issues

Luigi Ballabio-2
Cheers,

At 05:29 03/11/2004, Ashish Kulkarni wrote:
>Luigi Ballabio wrote:
>[snip]
> > Yes, sadly the bindings tend to stay behind the library.
>
>I'm willing to take up maintaining the SWIG bindings (although I'll be
>using mostly the Python ones for now).

You're welcome. Contact Ferdinando for write-access to CVS. Tell him I sent
you :)  (he's reading this anyway)

>  Also, it looks likely that I'll
>be attempting to develop a QuantLib Java/JNI binding for my company
>sometime in the future, which I can (hopefully) contribute back to QuantLib.

Good. Are you planning to adapt the existing SWIG interfaces, or to
hand-craft  the bindings?


> > Last I heard, someone was working on patching SWIG to generate
> > docstrings in the bindings. That would allow PyDoc to work some magic.
> > But I don't know whether that is ready for prime-time.
>
>The patch for that is already in SWIG CVS; see http://tinyurl.com/3zl9n

Cool. As SWIG 1.3.23 is scheduled for release in a few days, we'd have time
for adding this to 0.3.8.

>BTW, does anyone know when is the release of QuantLib 0.3.8 expected?

I created the 0.3.8 release branch a few days ago. Unfortunately, the
laptop I use for QuantLib development broke soon after that, which will
prevent me from working on it until I get it fixed or I get a replacement.
But in any case, 0.3.8 should be out by the end of this month.

Later,
         Luigi




Reply | Threaded
Open this post in threaded view
|

Re: QuantLib-Python related issues

Ashish Kulkarni-7
> You're welcome. Contact Ferdinando for write-access to CVS. Tell him I 
> sent you :)  (he's reading this anyway)

will do :-)

>>  Also, it looks likely that I'll
>> be attempting to develop a QuantLib Java/JNI binding for my company
>> sometime in the future, which I can (hopefully) contribute back to 
>> QuantLib.
> 
> Good. Are you planning to adapt the existing SWIG interfaces, or to 
> hand-craft  the bindings?

I plan to adapt the existing SWIG interfaces to Java; however due to the
non-dynamic nature of Java and absence of operator overloading there may
be differences in the way things are handled. Maintaining seperate 
bindings isn't worth it ... :-)

I've already given it a dry-run, and it seemed to do things reasonably 
well (didn't try to run it, though). I think it shouldn't take too much 
effort once I've understood out all the SWIG-Java interface options. 
Maybe we could have that done by 0.3.8, or a few weeks after that :-)

Cheers,
Ashish

"This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively "ICICI Group"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects."

Reply | Threaded
Open this post in threaded view
|

Re: QuantLib-Python related issues

Luigi Ballabio-2
At 10:16 03/11/2004, Ashish Kulkarni wrote:
>I plan to adapt the existing SWIG interfaces to Java; however due to the
>non-dynamic nature of Java and absence of operator overloading there may
>be differences in the way things are handled. Maintaining seperate
>bindings isn't worth it ... :-)

No, it isn't.

>I've already given it a dry-run, and it seemed to do things reasonably
>well (didn't try to run it, though). I think it shouldn't take too much
>effort once I've understood out all the SWIG-Java interface options.
>Maybe we could have that done by 0.3.8, or a few weeks after that :-)

Let's make it a few weeks after that :)
0.3.8 is almost finalized, and the only things I'd add at this time are
bug-fixes, docs, and the odd small feature (such as adding
     %feature("autodoc") *
to the wrappers.)

Later,
         Luigi