quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] C++ help needed: singleton.hpp

[Luigi B. <lui...@gm...>]

On Fri, 2007-09-21 at 21:24 +0200, Klaus Spanderen wrote:
> in ql/patterns/singleton.hpp
> 
>    68     template <class T>
>    69     T& Singleton<T>::instance() {

> IMO this function should be declared as inline function to avoid linker 
> problem. 
> 
>  69     inline T& Singleton<T>::instance() {
> 
> Background: I'd problems with this function when linking QL under Windows to a 
> project without including the QL project into my project (simply linked 
> static QL library).

Klaus,
	I'm a bit afraid that declaring it inline might play badly with the
static map. What kind of linker problem did you have?

Luigi


-- 

This gubblick contains many nonsklarkish English flutzpahs, but the 
overall pluggandisp can be glorked from context. 
-- David Moser 

Re: [Quantlib-dev] Monte Carlo Method with Confidence Interval.

[Luigi B. <lui...@gm...>]

On Sat, 2007-09-22 at 02:45 -0700, cypanic wrote:
> Hi all,
> I'm working on an example file, equityOption.cpp. It has some monte carlo
> simulations. I would like to get confidence intervals, when I do the monte
> carlo simulations. Is there any way to calculate the confidence interval
> using Quantlib? If you have any suggestion, please let me know.

option.errorEstimate() should give you the standard error of the
returned NPV.

Luigi



-- 

Within C++, there is a much smaller and cleaner language struggling to
get out. 
-- Bjarne Stroustrup 

Re: [Quantlib-dev] Yield Curve Boostraping Improvements

[Simon I. <s.i...@gm...>]

You might want to examine the paper by Hagan&West on smooth yieldcurve
construction. Their convex monotone spline method gives great results.

Simon



On 10/2/07, newbie73 <lui...@av...> wrote:
>
>
> The choppy forward curves appear regardless of which interpolation method
> is
> used.  The term structure of 3m or 6m forward rates results in a saw-tooth
> term structure which deviates from market by huge amounts.
>
> Regarding the knot points, I was referring to picking maturities that do
> not
> necessarily correspond with the chosen instruments.  The methodology we
> use
> here treats the area between each knot point as its own curve (or curve
> function), so you end up with many separate curves which segment the yield
> curve which are then combined to ensure smooth forward curve generation.
>
> The technique itself is quite old and was developed by Lehman in the late
> 80s, but works well in most cases I've encountered.
>
> - Luis
>
>
> Luigi Ballabio wrote:
> >
> > On Mon, 2007-10-01 at 07:20 -0700, newbie73 wrote:
> >
> >> So far I've been quite happy with the functionality in the QuantLib
> >> library - I'd like to start using it to compare to market pricing.
> >> I've found that the curve stripping methodology produces extremely
> >> jagged forward curves which result in poor pricing of several market
> >> structures.
> >
> > Does this depend on the chosen interpolation?
> >
> >> Also, some algorithmic help in dynamically selecting knot points would
> be
> >> much appreciated as well.  The basic idea is the creation of a smooth
> >> interpolation method for a selected set of knot points for a given
> curve.
> >
> > "Selecting knot points" as in "choosing which instruments to use among
> > the available ones" (which is what Nando referred to) or as in "choosing
> > a set of knots freely, i.e., not necessarily corresponding to instrument
> > maturities"?
> >
> > Later,
> >       Luigi
> >
> >
> > --
> >
> > This gubblick contains many nonsklarkish English flutzpahs, but the
> > overall pluggandisp can be glorked from context.
> > -- David Moser
> >
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.html#a12997264
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Yield Curve Boostraping Improvements

[newbie73 <lui...@av...>]

The choppy forward curves appear regardless of which interpolation method is
used.  The term structure of 3m or 6m forward rates results in a saw-tooth
term structure which deviates from market by huge amounts.

Regarding the knot points, I was referring to picking maturities that do not
necessarily correspond with the chosen instruments.  The methodology we use
here treats the area between each knot point as its own curve (or curve
function), so you end up with many separate curves which segment the yield
curve which are then combined to ensure smooth forward curve generation.

The technique itself is quite old and was developed by Lehman in the late
80s, but works well in most cases I've encountered.

- Luis


Luigi Ballabio wrote:
> 
> On Mon, 2007-10-01 at 07:20 -0700, newbie73 wrote:
> 
>> So far I've been quite happy with the functionality in the QuantLib
>> library - I'd like to start using it to compare to market pricing.
>> I've found that the curve stripping methodology produces extremely
>> jagged forward curves which result in poor pricing of several market
>> structures.
> 
> Does this depend on the chosen interpolation?
> 
>> Also, some algorithmic help in dynamically selecting knot points would be
>> much appreciated as well.  The basic idea is the creation of a smooth
>> interpolation method for a selected set of knot points for a given curve.
> 
> "Selecting knot points" as in "choosing which instruments to use among
> the available ones" (which is what Nando referred to) or as in "choosing
> a set of knots freely, i.e., not necessarily corresponding to instrument
> maturities"?
> 
> Later,
> 	Luigi
> 
> 
> -- 
> 
> This gubblick contains many nonsklarkish English flutzpahs, but the 
> overall pluggandisp can be glorked from context. 
> -- David Moser 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.html#a12997264
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Yield Curve Boostraping Improvements

[Luigi B. <lui...@gm...>]

On Mon, 2007-10-01 at 07:20 -0700, newbie73 wrote:

> So far I've been quite happy with the functionality in the QuantLib
> library - I'd like to start using it to compare to market pricing.
> I've found that the curve stripping methodology produces extremely
> jagged forward curves which result in poor pricing of several market
> structures.

Does this depend on the chosen interpolation?

> Also, some algorithmic help in dynamically selecting knot points would be
> much appreciated as well.  The basic idea is the creation of a smooth
> interpolation method for a selected set of knot points for a given curve.

"Selecting knot points" as in "choosing which instruments to use among
the available ones" (which is what Nando referred to) or as in "choosing
a set of knots freely, i.e., not necessarily corresponding to instrument
maturities"?

Later,
	Luigi


-- 

This gubblick contains many nonsklarkish English flutzpahs, but the 
overall pluggandisp can be glorked from context. 
-- David Moser 

Re: [Quantlib-dev] Yield Curve Boostraping Improvements

[Ferdinando A. <na...@am...>]

Hi Luis

> algorithmic help in dynamically selecting knot points would be
> much appreciated as well.
some algorithms for instruments selection are defined in
QuantLibAddin, see qlRateHelperSelection in qlo/ratehelpers.hpp.
They are not in QuantLib as Luigi has preferred to keep them in the
application layer out of the analytic library so far.

> using an exponential spline across the term structure.
This is something I've been planning for a long time now. We have
Log-Linear interpolation, but what we really need is a logarithmic
adapter of any available interpolation. Then my favorite approach
would be monotone-cubic interpolation of log-discounts

ciao -- Nando

[Quantlib-dev] Yield Curve Boostraping Improvements

[newbie73 <lui...@av...>]

So far I've been quite happy with the functionality in the QuantLib library -
I'd like to start using it to compare to market pricing.  I've found that
the curve stripping methodology produces extremely jagged forward curves
which result in poor pricing of several market structures.

I'd like to add a curve stripping methodology that I've been using with an
internal library at my current work though I definitely need some help in
adding such a change to the library.

Also, some algorithmic help in dynamically selecting knot points would be
much appreciated as well.  The basic idea is the creation of a smooth
interpolation method for a selected set of knot points for a given curve. 
This is done using an exponential spline across the term structure.

Let me know if anyone can help me with this, I'd be glad to discuss the
algorithm further if the support is there.

- Luis
-- 
View this message in context: http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.html#a12980121
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] Is anyone considering implementing 2Factor Vasicek?

[newbie73 <lui...@av...>]

I've been considering working on an implementation though I was curious if
this is already in the works by anyone.  I'd love to work on it, though I
could certainly use some help in understanding some of the concepts
involved.  If anyone has some time to discuss this a bit, please drop me a
note - I'm available to chat on MSN or AIM anytime during the evenings (US
EST) or on the weekends.

Thanks,

- Luis
-- 
View this message in context: http://www.nabble.com/Is-anyone-considering-implementing-2Factor-Vasicek--tf4536387.html#a12947195
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] System interface

[Simon I. <s.i...@gm...>]

Hi,

I'm a newbie to the QuantLib library (but have been a quant for several
years) and really like most of the QuantLib structure but have a particular
suggestion that would make the library much more usable from an integration
& system development perspective.

The library is currently devised (from what I've seen) s.t. the market data
is given to the model or instrument as a specific type or set of types. So,
the ubiquitous IR swap is given a specific YieldTermStructure, the Black
model is given a vol & discount rate etc. I term this pattern the PUSH
method. In it, the business/quant knowledge specific to the model is split
between the model code (where the data is used) and the calling code (where
the data is constructed and allocated to the model.

The benefit of this method is simplicity and the easy ability to follow the
dependencies of a given price.

However, for system development and more complicated products, I much prefer
the PULL method. In this pattern,  a generic market data collection object
is passed to the model and the model itself determines which specific data
is required for pricing.

I'll just outline some of the benefits of this approach:
1) The information on the types of market data that are required is
concentrated in a single place - the model code. There is no need for a
calling system to have code specific to this.

2) It is simple to switch between market data environments - instead of
having to update the handles to every bit of market data, you simply update
the handle to the market data collection object. Then all instruments can be
re-priced with no need to recreate the models.

3) You don't - necessarily - have to create a model externally. If you
specify a default model type for a given instrument, the model can be
constructed internally (the model spec is retrieved from the market data
collection object). This can be very handy when switching between two
different models in a system as the interface stays the same, e.g. the
release cycle of the calling system(s) does not have to be synchronised to
the library and switching models becomes trivial.

4) For more complicated instruments, you might have an option which can be
exercised into 2 or more derivatives. Instead of creating a model which
contains a model (or more than one), each of which requires specific market
data, you can simply let the default model be used for each of the
underlying derivatives.

5) Developing models becomes simpler. If you need another
argument/parameter, you simply register a value or object against the market
data collection object and retrieve it internally from the market data
collection object - no need to change the interface.

Has anyone had this discussion in the past? I've read through all the
documentation I could find and read no mention of this. Perhaps I've been
remiss and this is all explained somewhere. Or perhaps there is another
project specifically for this.

I believe this could be implemented in a simple manner, in addition to the
current interface.
It would require an additional constructor for all instruments/models (stoch
processes) that supported this facility. It would also require additional
descriptive variables within those models (so that the model knows which
yieldcurve or which vol surface is needed). We'd also need some small
additions to allow a change in the market data object (pointing to a new set
of market data) to be passed onto the specific yieldcurves, vols etc.
However, there would be no compulsion to use this new facility and no change
to anyones existing calling conventions. It could be introduced slowly - no
existing instrument or model would HAVE to support this type of access.

I'd be prepared to do the necessary work for this. I've developed in
libraries that allow this facility before. Usually the only tricky part is
determining the descriptive variables. For example, a model requires a EUR
yieldcurve - but which one? EUR Libor or Euribor? Do we require a
discounting curve or a forwarding curve?

 Does anyone have any objections? Or any additions / comments or questions?
I seriously believe that this would add substantial value to the project.

Regards,

Simon

Re: [Quantlib-dev] Credit curves

[Luigi B. <lui...@gm...>]

On Wed, 2007-09-26 at 14:18 +0100, Simon Ibbotson wrote:
> Hi, is there any developer out there planning to contribute a CDS /
> bond curves (using reduced form approach)? I wouldn't want to
> duplicate any work.

There might be a contribution shortly. I don't think that it uses
reduced form approach, but it should at least define a base interface
for the default-probability curve. I'll get back as soon as I know for
sure.

Luigi


-- 

Use every man after his desert, and who shall scape whipping? 
-- Hamlet, Act II, scene II 

Re: [Quantlib-dev] Credit curves

[Ferdinando A. <na...@am...>]

Hi Simon

> is there any developer out there planning to contribute a CDS / bond
> curves (using reduced form approach)? I wouldn't want to duplicate any work.

not anyone I know of. Go ahead: I look forward to your contribution.

ciao -- Nando

[Quantlib-dev] Credit curves

[Simon I. <s.i...@gm...>]

Hi, is there any developer out there planning to contribute a CDS / bond
curves (using reduced form approach)? I wouldn't want to duplicate any work.

Cheers.

Re: [Quantlib-dev] PayoffInterpreter: specify new pay-offs and price them without code recompilation

[Luigi B. <lui...@gm...>]

On Tue, 2007-09-25 at 00:00 -0400, Joseph Wang wrote:
> What would be nice is if there were some standard C++ interfaces which people 
> could using to "hook in" function evaluation systems from any language.  

This can be done already with a combination of polymorphism and the
scripting language API. In Python, for instance, it would be enough to
define a C++ class like the following one and export it to Python via
SWIG:

class PyPayoff : public Payoff {
    PyObject payoff_;     // The payoff defined in Python. It can be
                          // a function or function object.
  public:
    PyPayoff(PyObject* payoff)
    : payoff_(payoff) {         // Store it...
        Py_XINCREF(function_);  // ...and make sure Python doesn't
    }                           // garbage-collect it.
    ~PyPayoff() {
        Py_XDECREF(function_);  // Release it when we're done.
    }
    Real operator()(Real price) const {
        // Call the Python function using the API...
        PyObject* pyResult = PyObject_CallFunction(payoff_,"d",price);
        // ...convert the result from Python...
        Real result = PyFloat_AsDouble(pyResult);
        // ...clean up...
        Py_XDECREF(pyResult);
        // ...and return.
        return result;
    }
    ...
};


Once the above is exported (which can be done in a few lines of SWIG
interface) the payoff can be defined from Python and used, as in:

def my_payoff1(S):   # a regular function
    return sqrt(S)

class my_payoff2:    # a function object
    def __init__(self,K):
        self.K = K
    def __call__(self,S):
        return (S-K)**2

option1 = SomeOption(process, PyPayoff(my_payoff1),
                     exercise, engine)
option2 = SomeOption(process, PyPayoff(my_payoff2(42.0)),
                     exercise, engine)

I'm sure the same can be done in other languages.

Later,
	Luigi


-- 

Poets have been mysteriously silent on the subject of cheese. 
-- Gilbert K. Chesterton 

Re: [Quantlib-dev] PayoffInterpreter: specify new pay-offs and price them without code recompilation

[Joseph W. <jo...@gn...>]

What would be nice is if there were some standard C++ interfaces which people 
could using to "hook in" function evaluation systems from any language.  
Something very simple would be a "function adapter" which defined a function 
that took a double and returned a double,

The trend I've seen in production code is to move away from special built 
payoff engines and toward general purpose scripting languages, because 
special built payoff engines tend in the long run to be unmaintainable.  The 
other trend I've seen is to try to be interpreter agnostic since a typical 
situation is one in which you have two or three custom payoff interpreters 
which are used in various places, and there is an effort to try to start 
merging the code base.

Also as far as payoffs, one thing that needs to be defined is the ability to 
specify a payoff schedule.

One final thing, what would be useful is to create an object in python, 
matlab, R, java or what have you, and this would generate a C++ object which 
would look and act like any other C++ object out there.  This would be useful 
not only in payoffs, but also generally useful both inside and outside of 
quantlib.

Re: [Quantlib-dev] PayoffInterpreter: specify new pay-offs and price them without code recompilation

[Klaus S. <kl...@sp...>]

Hi

strange. Do you compile it (the whole project) as part of the quantlib? If you 
want I'll send you me VS project.

On Monday 24 September 2007 11:34 am, HFQuant wrote:
> Hi,
>
> I am using VS 2005 professional edition and the last Quantlib version
> 0.8.1.
>
> So i changed  your include statements in the EquityOption.cpp file,
> basically including QuantLib.hpp and deleting the others.
>
>
> thks
>
> Klaus Spanderen-2 wrote:
> > On Thursday 20 September 2007 5:21 pm, HFQuant wrote:
> >> Hi,
> >>
> >> i tried to you your tool and running the example EquityOption.cpp. It
> >> compiles but crashes at run time.
> >> Did you have such a feedback before ? (0xC0000005: Access violation
> >> reading
> >> location 0x2183120a.)
> >>
> >> thanks
> >
> > arrg. No hadn't had this feedback before;-(. What operating system are
> > you using? On windows you might want to include the  payoff interpreter
> > project
> > into your quantlib project to avoid any parameter clashes.
> >
> > I checked the source code on Linux using g++-4.1 and on Windows with
> > Visual
> > Studio Express. On Linux the memory checker valgrind didn't report a
> > memery
> > leak or any access violation. I'm compiling against a recent QL version
> > from
> > the SVN head. I
> >
> > cheers
> >
> > --
> > Klaus Spanderen
> > Ludwig Erhard Str. 12
> > 48734 Reken (Germany)
> > E-Mail: kl...@NO... (remove NOSPAM from the address)
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 
Klaus Spanderen
Ludwig Erhard Str. 12
48734 Reken (Germany)
E-Mail: kl...@NO... (remove NOSPAM from the address)

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [12797] trunk/QuantLib/ql

[Luigi B. <lui...@gm...>]

On Sat, 2007-09-22 at 09:56 -0700, na...@us... wrote:
> Revision: 12797
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=12797&view=rev
> Author:   nando
> Date:     2007-09-22 09:56:48 -0700 (Sat, 22 Sep 2007)
> 
> Log Message:
> -----------
> - splitted in hpp/cpp files
> - mandatory calendar input parameter

This commit broke a few examples. Can you have a look at them when you
got a few minutes?

Thanks,
	Luigi


-- 

The surest way to make a monkey of a man is to quote him. 
-- Robert Benchley 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [12795] trunk/QuantLib/ql

[Luigi B. <lui...@gm...>]

On Sat, 2007-09-22 at 09:40 -0700, na...@us... wrote:
> Revision: 12795
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=12795&view=rev
> Author:   nando
> Date:     2007-09-22 09:40:17 -0700 (Sat, 22 Sep 2007)
> 
> Modified: trunk/QuantLib/ql/termstructure.hpp
> ===================================================================
> --- trunk/QuantLib/ql/termstructure.hpp	2007-09-22 13:32:21 UTC (rev 12794)
> +++ trunk/QuantLib/ql/termstructure.hpp	2007-09-22 16:40:17 UTC (rev 12795)
> @@ -102,84 +101,44 @@
>          void checkRange(const Date&,
>                          bool extrapolate) const;
>          //! time-range check
> -        void checkRange(Time,
> +        void checkRange(Time t,
>                          bool extrapolate) const;
>          bool moving_;
> +        Calendar calendar_;
>        private:
>          mutable Date referenceDate_;
>          mutable bool updated_;
>          Natural settlementDays_;
> -        Calendar calendar_;
>          DayCounter dayCounter_;
>      };

Nando,
	the calendar was private on purpose. The information should be accessed
by means of the calendar() method, not the data member. This is because
derived classes can override calendar() and have it return something
else---see ImpliedTermStructure for an example.

Luigi


-- 

The wisdom of the wise and the experience of the ages are perpetuated 
by quotations. 
-- Benjamin Disraeli 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [12837] trunk/QuantLib/ql/voltermstructures/ interestrate/capfloor

[Luigi B. <lui...@gm...>]

On Mon, 2007-09-24 at 03:22 -0700, na...@us... wrote:
> Log Message:
> -----------
> fixing constness
> Luigi: how was it working on your machine with mismatched definition/declaration?

I committed just one of the two files.

Luigi
 

-- 

The young man knows the rules, but the old man knows the exceptions. 
-- O. W. Holmes 

Re: [Quantlib-dev] PayoffInterpreter: specify new pay-offs and price them without code recompilation

[HFQuant <mar...@mo...>]

Hi, 

I am using VS 2005 professional edition and the last Quantlib version 0.8.1. 

So i changed  your include statements in the EquityOption.cpp file,
basically including QuantLib.hpp and deleting the others.


thks


Klaus Spanderen-2 wrote:
> 
> On Thursday 20 September 2007 5:21 pm, HFQuant wrote:
>> Hi,
>>
>> i tried to you your tool and running the example EquityOption.cpp. It
>> compiles but crashes at run time.
>> Did you have such a feedback before ? (0xC0000005: Access violation
>> reading
>> location 0x2183120a.)
>>
>> thanks
>>
> 
> arrg. No hadn't had this feedback before;-(. What operating system are you 
> using? On windows you might want to include the  payoff interpreter
> project 
> into your quantlib project to avoid any parameter clashes. 
> 
> I checked the source code on Linux using g++-4.1 and on Windows with
> Visual 
> Studio Express. On Linux the memory checker valgrind didn't report a
> memery 
> leak or any access violation. I'm compiling against a recent QL version
> from 
> the SVN head. I
> 
> cheers
> 
> -- 
> Klaus Spanderen
> Ludwig Erhard Str. 12
> 48734 Reken (Germany)
> E-Mail: kl...@NO... (remove NOSPAM from the address)
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/PayoffInterpreter%3A-specify-new-pay-offs-and-price-them-without-code-recompilation-tf4470210.html#a12856683
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] FixedRateCoupon contribution

[Luigi B. <lui...@gm...>]

On Sun, 2007-09-23 at 15:32 -0300, Piter Dias wrote:
> I am reviewing the patch I sent some time ago.
> My plan is send Bondvpatch again once there was some changes in QuantLib.
> However, my changes are based on FixedRateCoupon and FixedRateLeg classes
> generalization. I send them attached in this mail.
> The idea is be able to construct more complex cash flow structures and allow
> rates other than simple.
> This patch is backward compatible, tested with QuantLib Test Suite.
> 
> This patch has a little correct in BusinessDaysBetween function of Calendar
> class.

Ok, I'll have a look.

Thanks,
	Luigi


-- 

Present to inform, not to impress; if you inform, you will impress. 
-- Fred Brooks 

[Quantlib-dev] FixedRateCoupon contribution

[Piter D. <pit...@ma...>]

Luigi,

I am reviewing the patch I sent some time ago.
My plan is send Bondvpatch again once there was some changes in QuantLib.
However, my changes are based on FixedRateCoupon and FixedRateLeg classes
generalization. I send them attached in this mail.
The idea is be able to construct more complex cash flow structures and allow
rates other than simple.
This patch is backward compatible, tested with QuantLib Test Suite.

This patch has a little correct in BusinessDaysBetween function of Calendar
class.

Let me know what you think about it.

Thanks a lot.


Piter Dias
pit...@ca...

[Quantlib-dev] FixedRateCoupon contribution

[Piter D. <pit...@ca...>]

Luigi,

I am reviewing the patch I sent some time ago.
My plan is send Bondvpatch again once there was some changes in QuantLib.
However, my changes are based on FixedRateCoupon and FixedRateLeg classes
generalization. I send them attached in this mail.
The idea is be able to construct more complex cash flow structures and allow
rates other than simple.
This patch is backward compatible, tested with QuantLib Test Suite.

This patch has a little correct in BusinessDaysBetween function of Calendar
class.

Let me know what you think about it.

Thanks a lot.


Piter Dias
pit...@ca...

[Quantlib-dev] Monte Carlo Method with Confidence Interval.

[cypanic <cy...@gm...>]

Hi all,
I'm working on an example file, equityOption.cpp. It has some monte carlo
simulations. I would like to get confidence intervals, when I do the monte
carlo simulations. Is there any way to calculate the confidence interval
using Quantlib? If you have any suggestion, please let me know.
Thanks.

-- 
View this message in context: http://www.nabble.com/Monte-Carlo-Method-with-Confidence-Interval.-tf4500464.html#a12835070
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] PayoffInterpreter: specify new pay-offs and price them without code recompilation

[Luigi B. <lui...@gm...>]

Hi Klaus,

On Sep 21, 2007, at 7:51 PM, Klaus Spanderen wrote:
>> Well, I wouldn't put in into the core library anyway; it would be 
>> great
>> to have it available as an additional module.  The point is that I
>> wouldn't commit to that one as "the" payoff interpreter.
>
> The intention is/was to have "a" payoff interpreter at hand to be able 
> to do
> some prototyping when playing around with new payoffs.

Don't worry, I'm aware of the good intention.

> BTW: I know that one can call QL functions from Python etc. via. SWIG. 
> Is it
> also possible to call a Python-Script (which might define a payoff) 
> from C++?

Yes, with some code in the SWIG interface files. I'll try and send an 
example when I get some time.

Luigi

[Quantlib-dev] C++ help needed: singleton.hpp

[Klaus S. <kl...@sp...>]

Hi

in ql/patterns/singleton.hpp

   68     template <class T>
   69     T& Singleton<T>::instance() {
   70         static std::map<Integer, boost::shared_ptr<T> > instances_;
   71         #if defined(QL_ENABLE_SESSIONS)
   72         Integer id = sessionId();
   73         #else
   74         Integer id = 0;
   75         #endif
   76         boost::shared_ptr<T>& instance = instances_[id];
   77         if (!instance)
   78             instance = boost::shared_ptr<T>(new T);
   79         return *instance;
   80     }

IMO this function should be declared as inline function to avoid linker 
problem. 

 69     inline T& Singleton<T>::instance() {

Background: I'd problems with this function when linking QL under Windows to a 
project without including the QL project into my project (simply linked 
static QL library).

any comment?

cheers
-- 
Klaus Spanderen
Ludwig Erhard Str. 12
48734 Reken (Germany)
E-Mail: kl...@NO... (remove NOSPAM from the address)