quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Please don't yell at me...

[Keith W. <kw...@gm...>]

Keith Weintraub <kw1958 <at> gmail.com> writes:

> 
> Folks,
>    I posted the message below to the users list but got no response.  
> Maybe you developers are more knowledgeable or inclined to reply.
> 
> Sorry in advance for posting to both places.
> 
> Thanks in advance for any help you can give me,
> KW
> 

.... Omitted original users list post that was attached here.


I have some more info. Here is the error message that I captured from running
gdb on the command line (thanks for the suggestion Andreas):

   [Switching to process 545 local thread 0x2d03]
   Re-enabling shared library breakpoint 1
   /SourceCache/gdb/gdb-962/src/gdb/dwarf2read.c:7593: internal-error: could 
   not find partial DIE in cache

   A problem internal to GDB has been detected,
   further debugging may prove unreliable.

After that the debugger is dead.

As always thanks in advance for the much needed help,
KW

[Quantlib-dev] Confronting the upfront

[Jose Aparicio-N. <ja...@fr...>]

Hi all,
I have modified the cds to include upfront and running quotes. It affects the
 cds, their engines and the calibration helpers. Although there are quite a
few changes the interfaces do not change much and existing client code will
still work (at the price of misnaming the helpers a bit... )

I have split the bootstrap helpers in two different ones, each one corresponds
 to a different quotation mode and they target a different spread in the
bootstrapping.

Upfront quotes have a standardised/conventional mapping to a 'conventional
spread', this is done by means of a conventional recovery rate (different to
the market one) and a standard model (JPM is the public/ISDA standard for
this convention mapping). This is why I included the new member, methods,
 spreads and cashflow. I have put the upfront flow in a different "leg".
There are three spreads now, the upfront, the running and the conventional.

Computing the implicit conventional is done with the library models and not
 with the JPM standard which is becoming public for .... maybe this reason?
 Anyway, so a difference might appear. Models performing interpolations on HRs
 directly rather than on the intensities or the probabilities will give
different results.

Theres an impact on the cds options so these change too but internally only.
I have forced the options to be referring to running only quoted swaps. I
havent think much on this but looks like one could model through  Blacks the
forward upfront in the same way the forward running is. But what I am not
sure is that a Black forward running model is compatible with (implies also
a) a Black forward upfront and what the relation among the volatilies are
now.
I have no idea how the options are going to be quoted now. There is the
possibility of performing a transformation in another constructor to a
running only equivalent underlying cds and continue as it is.
Anyone has experience on this, or from another context, FI?

There are a few decissions on legs and helpers with which you might disagree,
 please do comment on these.
For instance the way the BPS is interpreted now. Or I have added schedule to
the helpers as a member, this might increase compilation time.

Luigi, do you think this code can be included for the next release? I have
taken the pain of writting it in two flavours, the old and new interfaces so
anyone can test it.

Regards
Pepe

Re: [Quantlib-dev] building under x64

[Mark j. <mar...@gm...>]

As far as I can tell the type of Size is

const unsigned __int64

I am never very keen on using code with __ in it. What do you think?

Mark


2009/3/4 Luigi Ballabio <lui...@gm...>:
> On Tue, 2009-03-03 at 17:00 +1100, Mark joshi wrote:
>> OK i've committed a new version that works with x64.
>
> Good, thanks.
>
>> I've added a preprocessor macro x64 to indicate that building is under x64.
>>
>> I've removed the default value for the null template and added
>> specializations for array and IntervalPrice.
>> I've put the specializations for these in their header files rather
>> than in null.hpp since this makes more
>> sense from a levelization viewpoint (and I couldn't get it to compile
>> with them null.hpp.)
>
> True. I've just moved the Date specialization to date.hpp as well.
>
>
>> I've also added a specialization under x64 only for Size.
>
> This works, but I'm still curious about what native type Size actually
> is (it's typedef to size_t, but that's not native either.)  I'd rather
> specialize the template for the native type, to reduce the risk of
> conflicts between specializations.  May you run the preprocessor on
> types.hpp and see how size_t is defined?  I don't know how to do it from
> the IDE---you'll probably have to call the x64 compiler from the command
> line (see <http://msdn.microsoft.com/en-us/library/x4d2c09s.aspx>) as
>
> cd path/to/QuantLib
> cl /E /I. /Ipath/to/boost ql\types.hpp > types.pp
>
> You'll get a truckload of code. After that, look for size_t in types.pp.
>
>
>> I'll look into dealing with the lexical_cast issue.
>
> Ok, thanks.
>
> Luigi
>
>
> --
>
> The wisdom of the wise and the experience of the ages are perpetuated
> by quotations.
> -- Benjamin Disraeli
>
>
>



-- 
Quant Job Interview Questions and Answers is now out: www.markjoshi.com

Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

Re: [Quantlib-dev] Please don't yell at me...

[Andreas S. <an...@sp...>]

Keith,

Keith Weintraub schrieb:

>> I have taken the Bonds example code (exactly) and rebuilt it  
>> successfully as a separate project in eclipse (just as if I was  
>> writing the code myself). Both the Debug and Release versions build  
>> and run successfully (with identical output) from the command line.

Have you debugged the example with gdb on the command line?

[Quantlib-dev] Please don't yell at me...

[Keith W. <kw...@gm...>]

Folks,
   I posted the message below to the users list but got no response.  
Maybe you developers are more knowledgeable or inclined to reply.

Sorry in advance for posting to both places.

Thanks in advance for any help you can give me,
KW


> Can't debug QuantLib Bond example on Mac in Eclipse.
> From: Keith Weintraub <kw1958 <at> gmail.com>
> Subject: Can't debug QuantLib Bond example on Mac in Eclipse.
> Newsgroups: gmane.comp.finance.quantlib.user
> Date: 2009-03-02 15:31:35 GMT
>
> Folks,
>   I have more info now on my problem. Just not enough for me to  
> solve it with my limited knowledge of this environment.
>
> To reiterate my situation I have successfully built Boost and  
> QuantLib. The QuantLib example program Bonds runs fine from the  
> command line.
>
> I have taken the Bonds example code (exactly) and rebuilt it  
> successfully as a separate project in eclipse (just as if I was  
> writing the code myself). Both the Debug and Release versions build  
> and run successfully (with identical output) from the command line.
>
> I can even run the release version successfully from within Eclipse.
>
> When I try to run the code in the debugger in Eclipse I get the  
> following:
>
>     [Switching to process 574 local thread 0x2d03]
>     Re-enabling shared library breakpoint 1
>     /SourceCache/gdb/gdb-962/src/gdb/dwarf2read.c:7593: internal- 
> error: could not find partial DIE in cache
>
>     A problem internal to GDB has been detected,
>     further debugging may prove unreliable.
>
>
> and the debugger will not run.
>
> Any help you can give me with this would be greatly appreciated.
>
> Thanks,
> KW


--

Re: [Quantlib-dev] building under x64

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

On Tue, 2009-03-03 at 17:00 +1100, Mark joshi wrote:
> OK i've committed a new version that works with x64.

Good, thanks.

> I've added a preprocessor macro x64 to indicate that building is under x64.
> 
> I've removed the default value for the null template and added
> specializations for array and IntervalPrice.
> I've put the specializations for these in their header files rather
> than in null.hpp since this makes more
> sense from a levelization viewpoint (and I couldn't get it to compile
> with them null.hpp.)

True. I've just moved the Date specialization to date.hpp as well.


> I've also added a specialization under x64 only for Size.

This works, but I'm still curious about what native type Size actually
is (it's typedef to size_t, but that's not native either.)  I'd rather
specialize the template for the native type, to reduce the risk of
conflicts between specializations.  May you run the preprocessor on
types.hpp and see how size_t is defined?  I don't know how to do it from
the IDE---you'll probably have to call the x64 compiler from the command
line (see <http://msdn.microsoft.com/en-us/library/x4d2c09s.aspx>) as

cd path/to/QuantLib
cl /E /I. /Ipath/to/boost ql\types.hpp > types.pp

You'll get a truckload of code. After that, look for size_t in types.pp.


> I'll look into dealing with the lexical_cast issue.

Ok, thanks.

Luigi


-- 

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

Re: [Quantlib-dev] building under x64

[Mark j. <mar...@gm...>]

OK i've committed a new version that works with x64.

I've added a preprocessor macro x64 to indicate that building is under x64.

I've removed the default value for the null template and added
specializations for array and IntervalPrice.
I've put the specializations for these in their header files rather
than in null.hpp since this makes more
sense from a levelization viewpoint (and I couldn't get it to compile
with them null.hpp.)

I've also added a specialization under x64 only for Size.

I'll look into dealing with the lexical_cast issue.

mark





2009/2/17 Bojan Nikolic <bo...@bn...>:
>
> Hi Mark,
>
> Mark joshi <mar...@gm...> writes:
>
>> Ok I tried inserting
>>
>> template <>
>>     class Null<Size> {
>>       public:
>>         Null() {}
>>         operator Size() const { return Size(QL_NULL_INTEGER); }
>>     };
>>
>> into null.hpp and it didn't help.
>
> I guess you tried combining this with:
>
>    //! template class providing a null value for a given type.
>    template <class Type>
>    class Null;
>
> to check no further compilation errors come up?
>
>> As far as i can tell, the template specialization did nothing.
>
> You should be able to just printing the Null value to check it is not
> zero, i.e., std::cout<< Null<Size>();
> c
> Without a Windows setup this is now all guess work, but :
>
> In termstructure.cpp:
>
>> namespace QuantLib {
>>
>>     TermStructure::TermStructure(const DayCounter& dc)
>>     : moving_(false),
>>       updated_(true),
>>       settlementDays_(Null<Size>()),
>>       dayCounter_(dc) {}
>
> Here we try to convert Size to Natural as settlementDays_ is declared Natural
>
>>     TermStructure::TermStructure(const Date& referenceDate,
>>                                  const Calendar& cal,
>>                                  const DayCounter& dc)
>>     : moving_(false), calendar_(cal),
>>       referenceDate_(referenceDate), updated_(true),
>>       settlementDays_(Null<Natural>()),
>>       dayCounter_(dc) {}
>
> Here we use Natural to assign to Natural
>
>>
>> // rest of file
>
> I would try replacing the first settlementDays_(Null<Size>()) with
> settlementDays_(Null<Natural>())
>
>
> Best,
> Bojan
>
> --
> Bojan Nikolic          ||          http://www.bnikolic.co.uk
>



-- 
Quant Job Interview Questions and Answers is now out: www.markjoshi.com

Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

[Quantlib-dev] [ quantlib-Bugs-2637105 ] error in method expectation of BlackScholesMerton process

[SourceForge.net <no...@so...>]

Bugs item #2637105, was opened at 2009-02-25 15:16
Message generated for change (Comment added) made by heckl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Michael Heckl (heckl)
Assigned to: Luigi Ballabio (lballabio)
Summary: error in method expectation of BlackScholesMerton process

Initial Comment:
The method "expectation(Time t0, Real x0, Time dt)" does wrong calculations. I tried it for a BlackScholesMerton Process and the result is wrong. After following up the code i found out that the method calculates:

return x0 * std::exp(dx);


where  dx comes from

Real EulerDiscretization::drift(const StochasticProcess1D& process,
                                    Time t0, Real x0, Time dt) const {
        return process.drift(t0, x0)*dt;
    }

And the process drift from
Real GeneralizedBlackScholesProcess::drift(Time t, Real x) const {
        Real sigma = diffusion(t,x);
        // we could be more anticipatory if we know the right dt
        // for which the drift will be used
        Time t1 = t + 0.0001;
        return riskFreeRate_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - dividendYield_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - 0.5 * sigma * sigma;
    }


This is simply wrong. What is wrong is that you didnt consider the Jenson inequality. Since exp is a strictly convex function we have:

let X_t be the BlackScholes Merton Process and S_t be ln(X_t) the related log-process, then
exp{E[S_t]}=exp{E[ln(X_t)]}<E[exp{ln(X_t)}]=E[X_t]

But the method expectation calculates the left side which is always to small. You can easily illustrate it if you choose the BlackScholesMerton Process in a way that the drift is 0. Check out the attached code for clarification.

Greetings
Michael

----------------------------------------------------------------------

>Comment By: Michael Heckl (heckl)
Date: 2009-03-02 15:22

Message:
No, sorry, regrettably i dont have an easy patch to fix this bug.

I was trying a few things but in the end it turned out more difficult to
fix this bug then you would expect considering it only takes a little
change in the mathematical formula.

It is not possible to simply adjust the method:
- StochasticProcess1D::expectation(Time t0, Real x0, Time dt)
or the method
- Real GeneralizedBlackScholesProcess::apply(Real x0, Real dx)

those methods do the math. But the problem is that they are both used by
the method:
- Real ExtendedBlackScholesMertonProcess::evolve

which is responsible to do generate the pathes. So a change in one of the
upper methods which calculate the expected value immediatly affects the
"evolve" method and therefore we get wrong pathes.

imho the easiest way would be to make a new method and change the names to
make it more intuitional (i.e. make it more obvious what method calculates
what values; does the value belong to the process or the log-process; what
does the value describe?). The new method could look something like:

Real StochasticProcess1D::expectationOfX(Time t0, Real x0, Time dt) const
{
        Real sigma = diffusion(t0,x0);
        Real mue = drift(t0,x0);
        Real dx = (mue+0.5*sigma*sigma)*dt;
        return apply(x0, dx);
    }

----------------------------------------------------------------------

Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-27 12:18

Message:
You're right.  The problem comes from the process being born as an exp
wrapper for the underlying log process.  The expectation doesn't work.  Do
you have a patch that makes it return the correct value?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

[Quantlib-dev] Towards version 1.0 - plans for home stretch

[Chris K. <chr...@ya...>]

- inflation curves need to include seasonality.  According to Chris
Kenyon, this will be done shortly---correct, Chris? Any schedule?


Hi Luigi,
 
Re inflation there are a number of changes in the pipeline:
1) add the calibration stability updates for inflation vol

2) add the tests for the inflation vol 
3) move the inflation vol to the main area (i.e. out of experimental)
4) add seasonality (multiplicative)

Timeframe realistically is around three to four weeks,
say the end of March.  How does that suit for these steps?  I'd like to have infl vol out of experimental for 1.0, what do you think?
 
Regards,
Chris

Re: [Quantlib-dev] Towards version 1.0 - plans for home stretch

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

On Fri, 2009-02-27 at 19:02 +0100, Ferdinando Ametrano wrote:
> I'll clean up that code next week. From what I remember the different
> OptionletStrippers fulfilled different needs, so will rename and
> document them, while redundant SwaptionVolCurveX should just disappear

Great, thanks.

Luigi


-- 

Do the right thing. It will gratify some people and astonish the rest. 
-- Mark Twain 

Re: [Quantlib-dev] Towards version 1.0 - plans for home stretch

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

On Fri, Feb 27, 2009 at 3:57 PM, Luigi Ballabio
<lui...@gm...> wrote:
> - we should clean up the OptionletStripper1/OptionletStripper2 classes
> (are they all still needed? Can they have better names?)  The same goes
> for SwaptionVolCurveX.  Nando, any thoughts on these ones?

I'll clean up that code next week. From what I remember the different
OptionletStrippers fulfilled different needs, so will rename and
document them, while redundant SwaptionVolCurveX should just disappear

ciao -- Nando

[Quantlib-dev] Towards version 1.0 - plans for home stretch

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

Hi all,
	this year seems a nice year to release version 1.0.  Except for one or
two things that still need changing (see below) I'd go for it with what
we currently have in the repository.  My idea was to call it 0.9.9 and
release it as a kind of beta for 1.0.  In fact, I'd either create a 1.0
release branch at the same time that I create the 0.9.9, or use the same
branch for both.  Once 0.9.9 is released, I'd fix reported bugs (if any)
and release 1.0 after a short while (say, one or two months.)

As for 0.9.9, I'd release it as soon as it's in shape. The couple of
things that are still missing before we can freeze the interfaces are:

- inflation curves need to include seasonality.  According to Chris
Kenyon, this will be done shortly---correct, Chris? Any schedule?

- we should clean up the OptionletStripper1/OptionletStripper2 classes
(are they all still needed? Can they have better names?)  The same goes
for SwaptionVolCurveX.  Nando, any thoughts on these ones?

As I said, at 0.9.9 and onward the interfaces would be frozen---meaning
that client code that compiles against 0.9.9 should compile without
modifications against 1.0 and later releases.  This means that adding
stuff to existing classes is ok, removing or renaming it is not (unless
it's private methods or data members.)

Later,
	Luigi


-- 

A child of five would understand this. Send someone to fetch a child of
five. 
-- Groucho Marx 

Re: [Quantlib-dev] credit modeling, Issuer, etc.

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

On Wed, 2009-02-25 at 19:38 +0100, Jose Aparicio-Navarro wrote:
> Your not alone! I am resiting; but not for long, I guess sending code in
> the old interface format will be bad manners...

Not necessarily. It just stay in the experimental folder.


> Also..., to make things worst I am sending code with some changes for the cds
> and calibration  in a few days. Luigi, you do not know where I park my car,
> right? :-)

Not yet, but one can do a lot of things with Google Earth there days...


> One more point on the Issuer issue: Seniority today is a property of a
> DefaultEvent, while this is a property of debt linked for instance
> to an expected recovery rate.

True. It should probably be removed from DefaultEvent. How about
restructuring? Does it belong?

Luigi


-- 

For every problem there is one solution which is simple, neat, and
wrong. 
-- H. L. Mencken 

Re: [Quantlib-dev] credit modeling, Issuer, etc.

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

On Wed, 2009-02-25 at 16:20 +0100, Roland Lichters wrote:

> What I'd really like to ask here- which credit parts do we want to see
> in the core library in version 1.0? I think version 1.0 deserves more
> than the cds :-). I had hoped that we can get the cds option,
> synthetic cdo, nth to default basket instruments out of experimental
> status by then, to encourage more people to take a look and contribute
> extensions. Do you think this is over-ambitious?

After having hoped to release version 1.0 last year, yes---I think it's
over-ambitious :)  I'd go for 1.0 with what we have now. 

Luigi


-- 

Flon's Law: 
There is not now, and never will be, a language in 
which it is the least bit difficult to write bad programs. 

[Quantlib-dev] Multicore-enabling Discrete Hedging in QuantLib

[Ilya M. <il...@ci...>]

Hello,
 
After some direction from the Wilmott forums, we have parallelized the
discrete hedging example in QuantLib, and got pretty good speed-up: almost
14X on a 16-core system.

Here's the write-up: Multicore-enabling Discrete Hedging in
<http://www.cilk.com/multicore-blog/bid/8542/Multicore-enabling-Discrete-Hed
ging-in-QuantLib> QuantLib

It feels like Cilk++ lends itself well to taking a large library or app like
QuantLib, and creating a multicore-ready version pretty quickly, by
parallelizing just the pieces involved. 
 
I'm curious whether there's other functions in QuantLib folks are interested
in parallelizing?  We'd love to hear from you.
 
Also - Cilk++ is available for download here <http://www.cilk.com> .  Feel
free to grab a copy, and we'd be glad to help.

Cheers,
ilya
 
 
 
Ilya Mirman 
Cilk Arts, Inc.
55 Cambridge Street | Burlington | MA | 01803 | USA
Tel: 781-725-2455 x709 | Mobile: 978-460-1002 | Fax: 781-253-0280 |
 <http://www.cilk.com> www.cilk.com
 
 
<http://www.cilk.com/multicore-blog/bid/8097/Don-t-get-caught-with-your-mult
icore-pants-down> Don't get caught with your multicore pants down!
 
 

[Quantlib-dev] [ quantlib-Bugs-2637105 ] error in method expectation of BlackScholesMerton process

[SourceForge.net <no...@so...>]

Bugs item #2637105, was opened at 2009-02-25 15:16
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Michael Heckl (heckl)
Assigned to: Luigi Ballabio (lballabio)
Summary: error in method expectation of BlackScholesMerton process

Initial Comment:
The method "expectation(Time t0, Real x0, Time dt)" does wrong calculations. I tried it for a BlackScholesMerton Process and the result is wrong. After following up the code i found out that the method calculates:

return x0 * std::exp(dx);


where  dx comes from

Real EulerDiscretization::drift(const StochasticProcess1D& process,
                                    Time t0, Real x0, Time dt) const {
        return process.drift(t0, x0)*dt;
    }

And the process drift from
Real GeneralizedBlackScholesProcess::drift(Time t, Real x) const {
        Real sigma = diffusion(t,x);
        // we could be more anticipatory if we know the right dt
        // for which the drift will be used
        Time t1 = t + 0.0001;
        return riskFreeRate_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - dividendYield_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - 0.5 * sigma * sigma;
    }


This is simply wrong. What is wrong is that you didnt consider the Jenson inequality. Since exp is a strictly convex function we have:

let X_t be the BlackScholes Merton Process and S_t be ln(X_t) the related log-process, then
exp{E[S_t]}=exp{E[ln(X_t)]}<E[exp{ln(X_t)}]=E[X_t]

But the method expectation calculates the left side which is always to small. You can easily illustrate it if you choose the BlackScholesMerton Process in a way that the drift is 0. Check out the attached code for clarification.

Greetings
Michael

----------------------------------------------------------------------

>Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-27 12:18

Message:
You're right.  The problem comes from the process being born as an exp
wrapper for the underlying log process.  The expectation doesn't work.  Do
you have a patch that makes it return the correct value?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

[Quantlib-dev] [ quantlib-Bugs-2637105 ] error in method expectation of BlackScholesMerton process

[SourceForge.net <no...@so...>]

Bugs item #2637105, was opened at 2009-02-25 15:16
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Michael Heckl (heckl)
>Assigned to: Luigi Ballabio (lballabio)
Summary: error in method expectation of BlackScholesMerton process

Initial Comment:
The method "expectation(Time t0, Real x0, Time dt)" does wrong calculations. I tried it for a BlackScholesMerton Process and the result is wrong. After following up the code i found out that the method calculates:

return x0 * std::exp(dx);


where  dx comes from

Real EulerDiscretization::drift(const StochasticProcess1D& process,
                                    Time t0, Real x0, Time dt) const {
        return process.drift(t0, x0)*dt;
    }

And the process drift from
Real GeneralizedBlackScholesProcess::drift(Time t, Real x) const {
        Real sigma = diffusion(t,x);
        // we could be more anticipatory if we know the right dt
        // for which the drift will be used
        Time t1 = t + 0.0001;
        return riskFreeRate_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - dividendYield_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - 0.5 * sigma * sigma;
    }


This is simply wrong. What is wrong is that you didnt consider the Jenson inequality. Since exp is a strictly convex function we have:

let X_t be the BlackScholes Merton Process and S_t be ln(X_t) the related log-process, then
exp{E[S_t]}=exp{E[ln(X_t)]}<E[exp{ln(X_t)}]=E[X_t]

But the method expectation calculates the left side which is always to small. You can easily illustrate it if you choose the BlackScholesMerton Process in a way that the drift is 0. Check out the attached code for clarification.

Greetings
Michael

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

Re: [Quantlib-dev] piecewiseyoyinflationcurve: compilation error using MS VC9 (2008)

[Andreas S. <an...@sp...>]

Hi,

Es schrieb Luigi Ballabio

>> I don't know whether you want to put this in the repository, though ;-)
>
> Only conditionally... Let's try to turn this into a configure test.
> I've stripped the guilty file to a minimum and I'm attaching it to this
> post. Can you check that if you run
>     g++ -c test.cpp
> (or whatever your C++ compiler is called) it does NOT compile, but it
> does when you remove the "class" keyword?

Will do.

> P.S. Another try: does the original file compile if you keep the
> "class", but replace this_curve in the friend declaration with the full
> type? (Piecewise...<Interpolation,etc.etc>)

I tried this already, and no, it doesn't...

Rgds,

Andreas

Re: [Quantlib-dev] piecewiseyoyinflationcurve: compilation error using MS VC9 (2008)

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

On Wed, 2009-02-25 at 10:40 +0100, Andreas Spengler wrote:
> The SUN compiler does not understand friend declarations using templated
> classes.
> 
> A work-around that compiles, strangely enough, is to remove the "class" in
> 
> friend class Bootstrap<this_curve>;
> 
> 
> I don't know whether you want to put this in the repository, though ;-)

Only conditionally... Let's try to turn this into a configure test.
I've stripped the guilty file to a minimum and I'm attaching it to this
post. Can you check that if you run
    g++ -c test.cpp
(or whatever your C++ compiler is called) it does NOT compile, but it
does when you remove the "class" keyword?

Thanks,
	Luigi

P.S. Another try: does the original file compile if you keep the
"class", but replace this_curve in the friend declaration with the full
type? (Piecewise...<Interpolation,etc.etc>)

Luigi


-- 

Newton's Law of Gravitation: 
What goes up must come down. But don't expect it to come down 
where you can find it. Murphy's Law applies to Newton's. 

Re: [Quantlib-dev] credit modeling, Issuer, etc.

[Jose Aparicio-N. <ja...@fr...>]

Quoting Roland Lichters <rol...@go...>:

>...I'm apparently the only one who is still
> using it..
Your not alone! I am resiting; but not for long, I guess sending code in
the old interface format will be bad manners...
>
> What I'd really like to ask here- which credit parts do we want to see in
> the core library in version 1.0? I think version 1.0 deserves more than the
> cds :-). I had hoped that we can get the cds option, synthetic cdo, nth to
> default basket instruments out of experimental status by then, to encourage
> more people to take a look and contribute extensions. Do you think this is
> over-ambitious?
With the times you guys had in mind it might be. We have to get the new issuer
etc ... and then move the code, Ill love to see the correlation part as well
but that needs more work. I am in for trying, the weather is degrading here.

Also..., to make things worst I am sending code with some changes for the cds
and calibration  in a few days. Luigi, you do not know where I park my car,
right? :-)

One more point on the Issuer issue: Seniority today is a property of a
DefaultEvent, while this is a property of debt linked for instance
to an expected recovery rate.
I havent got too far:

CDS---(1)->Debt/Bond--(1)->Seniority--------> ||
                    |-Issuer------------(1)-> ||---> RR (quoted)

But also: Seniority----(1)-> RR(conventional) ; independently of the issuer.

DefaultEvent ----->RealizedRR+DefDate+DefSettlementDate

So the relation is true only if we have present the conventional RR as an
expression of the "seniority of a default". But this is not general.

Regards
Pepe

Re: [Quantlib-dev] credit modeling, Issuer, etc.

[Roland L. <rol...@go...>]

Hi all,
I'm a bit late, but fully agree that the issuer was preliminary. I feel
obliged to make a proposal, as I'm apparently the only one who is still
using it..

What I'd really like to ask here- which credit parts do we want to see in
the core library in version 1.0? I think version 1.0 deserves more than the
cds :-). I had hoped that we can get the cds option, synthetic cdo, nth to
default basket instruments out of experimental status by then, to encourage
more people to take a look and contribute extensions. Do you think this is
over-ambitious?

Best regards,
Roland


On Mon, Feb 23, 2009 at 6:06 PM, Luigi Ballabio <lui...@gm...>wrote:

> On Mon, 2009-02-23 at 10:00 +0100, Jose Aparicio-Navarro wrote:
> > Quoting Luigi Ballabio <lui...@gm...>:
> > > Then again, the current Issuer class is wrong and should not go into
> > > release 1.0 either.  What I would do at this time is to remove the
> class
> > > from the library and pass its components to the methods that were
> > > accepting it.
> >
> > quite, if your short of time and need someone to do this I volunteer,
> just give
> > me a deadline so you have time to review the changes.
>
> No, thanks---it's almost done.
>
> I'll commit it in a couple of days if there are no objections.
>
> Luigi
>
>
> --
>
> Never mistake motion for action.
> -- Ernest Hemingway
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] [ quantlib-Bugs-2637105 ] error in method expectation of BlackScholesMerton process

[SourceForge.net <no...@so...>]

Bugs item #2637105, was opened at 2009-02-25 15:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Heckl (heckl)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in method expectation of BlackScholesMerton process

Initial Comment:
The method "expectation(Time t0, Real x0, Time dt)" does wrong calculations. I tried it for a BlackScholesMerton Process and the result is wrong. After following up the code i found out that the method calculates:

return x0 * std::exp(dx);


where  dx comes from

Real EulerDiscretization::drift(const StochasticProcess1D& process,
                                    Time t0, Real x0, Time dt) const {
        return process.drift(t0, x0)*dt;
    }

And the process drift from
Real GeneralizedBlackScholesProcess::drift(Time t, Real x) const {
        Real sigma = diffusion(t,x);
        // we could be more anticipatory if we know the right dt
        // for which the drift will be used
        Time t1 = t + 0.0001;
        return riskFreeRate_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - dividendYield_->forwardRate(t,t1,Continuous,NoFrequency,true)
             - 0.5 * sigma * sigma;
    }


This is simply wrong. What is wrong is that you didnt consider the Jenson inequality. Since exp is a strictly convex function we have:

let X_t be the BlackScholes Merton Process and S_t be ln(X_t) the related log-process, then
exp{E[S_t]}=exp{E[ln(X_t)]}<E[exp{ln(X_t)}]=E[X_t]

But the method expectation calculates the left side which is always to small. You can easily illustrate it if you choose the BlackScholesMerton Process in a way that the drift is 0. Check out the attached code for clarification.

Greetings
Michael

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2637105&group_id=12740

Re: [Quantlib-dev] Documentation patch for the Brownian bridge path

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

On Wed, 2009-02-25 at 08:05 +0000, Bojan Nikolic wrote:
> Attached is a short patch that should make it clearer how to use the
> Brownian bridge class.

Applied, thanks.

Luigi


-- 

Cogito ergo I'm right and you're wrong. 
-- Blair Houghton 

[Quantlib-dev] [ quantlib-Bugs-2617586 ] config error in CSharp SWIG extension for QuantLib_vc8.sln

[SourceForge.net <no...@so...>]

Bugs item #2617586, was opened at 2009-02-19 22:02
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2617586&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Grant Birchmeier (grantbirchmeier)
>Assigned to: Luigi Ballabio (lballabio)
Summary: config error in CSharp SWIG extension for QuantLib_vc8.sln

Initial Comment:
Compiling the CSharp SWIG extension fails for vc8.  The following easy fix is needed:

For both BermudanSwaption_vc8 and EquityOption_vc8
1) right-click -> Properties -> Build Events
2) change
copy "$(SolutionDir)cpp\bin\vc80\$(ConfigurationName)\NQuantLibc.dll" "$(TargetDir)"
to 
copy "$(SolutionDir)csharp\bin\vc80\$(ConfigurationName)\NQuantLib.dll" "$(TargetDir)"

Notice the change from "cpp" to "csharp" and removing the "c" from NQuantLibc.dll.

Rebuild solution and it should compile cleanly.

----------------------------------------------------------------------

Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-25 11:45

Message:
The bug is now fixed in the Subversion repository.
Thank you for the report.


----------------------------------------------------------------------

Comment By: Grant Birchmeier (grantbirchmeier)
Date: 2009-02-23 16:28

Message:
I'm using Visual Studio 2005 Professional Edition - Microsoft Visual C#
2005.

In the "Project Dependencies" dialog for BermudanSwaption_vc8 project, the
dependencies are NQuantLib_vc8 and NQuantLibc, in that order.

For EquityOption_vc8 project, the only dependency is NQuantLib_vc8.

These settings are as they were out-of-the-box, that is, I did not alter
them.

----------------------------------------------------------------------

Comment By: Luigi Ballabio (lballabio)
Date: 2009-02-23 11:19

Message:
The dependency on NQuantLib should already take care of it. In fact, it
does on my machine.
What version of Visual C# are you using? (Express, Standard...)
If you open the "Project dependencies" dialog on either BermudanSwaption
or EquityOption, do you see NQuantLib as a dependency?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2617586&group_id=12740

Re: [Quantlib-dev] piecewiseyoyinflationcurve: compilation error using MS VC9 (2008)

[Andreas S. <an...@sp...>]

Hi,

> Hmm. At least it worked for VC++9... may you try shuffling things around
> and see if you get it to compile in some way?

The SUN compiler does not understand friend declarations using templated
classes.

A work-around that compiles, strangely enough, is to remove the "class" in

friend class Bootstrap<this_curve>;


I don't know whether you want to put this in the repository, though ;-)


Rgds,

Andreas
-- 
http://aspengler.blogspot.com