quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Fwd: Re: [Quantlib-users] CreditDefaultSwap throws RuntimeError

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

On Tue, 2009-10-27 at 09:53 +0100, Jose Aparicio-Navarro wrote:
> Luigi, forget this, its wrong. I am breaking the test suite. I'll try to give it
> another look when I find the time. Too bad is going to 1.0 like that.

No problem, Jose.  You did an excellent job anyway, and I've no
complaints about 1.0---also, we have to ship it sometimes :)

Luigi


-- 

Never mistake motion for action. 
-- Ernest Hemingway 

Re: [Quantlib-dev] Fwd: Re: [Quantlib-users] CreditDefaultSwap throws RuntimeError

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

Luigi, forget this, its wrong. I am breaking the test suite. I'll try to give it
another look when I find the time. Too bad is going to 1.0 like that.
Regards
Pepe

Quoting Jose Aparicio-Navarro <ja...@fr...>:

> Sorry I left this behind. I gave it another thought and I was missing the
> situation where the yieldRef date is within one period and the probRef on a
> later one.
>
> As a reminder the problem might arise on certain ordering combinations of the
> yield and default probability curves reference dates within a schedule.
> Intermediate times are defined in a way that might lead to request
> probabilities or DFs before the ref dates.
>
> In the midpoint we request probs at the end points of the coupon and DFs at
> those plus the default time (midpoint). In the integral we request probs and
> DFs
> at integrations points.
>
> So the midpoint needs:
> 1.- T_midP  >= refYield
> 2.- T_effStart >= refYield  <-guaranteed by hasOccurred and def. of effStart
> 3.- T_end   >= refYield  <-guaranteed by the hasOccurred on the coupon
> 4.- T_effstart >= refProb
> 5.- T_end   >= refProb
>
> 1.- If today >=refYield this point is guaranteed. It is the mid-point within
> the fraction of the interval in the future ('future' defined by the yield ref
> date). So it could be before the proba curve ref date. This does not pose a
> technical problem since we do not request probabilities at that mid point.
> Might pose conscientiousness problems having the default time before prob=1
> though. The probRef might be a few coupon periods ahead.
>
> So redefinging:
>    87     Date effectiveStartDate =
>    88         (startDate <= settlementDate && settlementDate <= endDate) ?
>                      settlementDate : startDate;
> does the trick.
>
> In general, rather than defining a few extra times as I was saying in
> previous
> posts we could have require arguments_.leg[i]->hasOccurred(refProbDate) on
> top
> of the settlement.....which might leave behind coupons that have not yet
> occurred from the Yield point of view.
>
> Or we can require refYield >= refProb to hold; I can make sense of this
> situation in terms of the meaning of the probabilities but not of the
> reverse.
> This would seem to address the new CDS convention definitions where
> one has partial information today on whether the name has defaulated already,
> but thats not what I want to solve now. This inforces 4 & 5 with the current
> code.
>
> I would go for this last one, at least is simple, what do you think?
>
> Things are similar for the integration engine.
>
> All this logic might need to be reviewed when the new conventions for the CDS
> contracts (the lookback protection in this case) are implemented but thats a
> different problem.
>
> Regards
> Pepe
>
> PS: I admit you woke me up with the previous mail, but this does not
> mean I am sending this for any particular version.
>
> Quoting Luigi Ballabio <lui...@gm...>:
>
> > On Mon, 2009-10-05 at 11:31 +0200, Jose Aparicio-Navarro wrote:
> > > Quoting Luigi Ballabio <lui...@gm...>:
> > > Yep, lets make it the TS ref date. Moving this
> > >
> > > Date effectiveStartDate =
> > >    (startDate <= today && today <= endDate) ? today : startDate;
> > >
> > > into:
> > >
> > > Date effectiveStartDate =
> > >     (startDate <= settlementDate && settlementDate <= endDate) ?
> > >         settlementDate : startDate;
> > >
> > > works for both cds engines.
> >
> > Except I'd leave the start date alone and correct the default date
> > instead, if possible. No?
> >
> > Luigi
> >
> >
> > --
> >
> > There is no opinion so absurd that some philosopher will not
> > express it.
> > -- Marcus Tullius Cicero, "Ad familiares"
> >
> >
> >
>
>
>

[Quantlib-dev] Prerelease tarballs

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

Hi all,
	if you have any cycles to spare during the weekend, please download and
try out the tarballs at <http://quantlib.org/prerelease/>.  They're not
yet the final ones, but they're pretty close.  Report here any problems
you may have.  I'd particularly appreciate if you tried the library on
cygwin or mingw, as I don't have a test environment for those platforms.

Thanks,
	Luigi


-- 

There are two ways of constructing a software design. One way is to 
make it so simple that there are obviously no deficiencies. And the 
other way is to make it so complicated that there are no obvious 
deficiencies. 
-- C. A. R. Hoare 

[Quantlib-dev] [ quantlib-Bugs-2884530 ] montecarlomodel.hpp

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

Bugs item #2884530, was opened at 2009-10-23 09:55
Message generated for change (Tracker Item Submitted) made by riccardolongoni
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2884530&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: Riccardo (riccardolongoni)
Assigned to: Nobody/Anonymous (nobody)
Summary: montecarlomodel.hpp

Initial Comment:
In file motecarlomodel.hpp, method MonteCarloModel<MC,RNG,S>::addSamples, line nb 99 reads:

sample_type path = pathGenerator_->next();

Therefore a copy of path is made. This is not necessary, and in fact you can replace it with

const sample_type & path = pathGenerator_->next();

This will improve the performances of the MonteCarlo simulations.

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

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

[Quantlib-dev] Release branches created

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

Hi all,
	I've just created the branches for the next releases.  The branch for
release 0.9.9 is at
<https://quantlib.svn.sourceforge.net/svnroot/quantlib/branches/R000909-branch>; as usual, bug fixes go here and new stuff goes on the trunk (note, though, that new stuff is now no longer allowed to break backward compatibility.)

Since 0.9.9 is practically a beta for 1.0, I've also created a branch
for release 1.0 from the same code base.  The branch is at
<https://quantlib.svn.sourceforge.net/svnroot/quantlib/branches/R01000x-branch>; for the time being, no work should be done there except specific changes for 1.0 (such as changing version number and output file names.)

Later,
	Luigi


-- 

Hofstadter's Law: 
It always takes longer than you expect, even when you take 
Hofstadter's Law into account. 

Re: [Quantlib-dev] QuantLib-SWING: is it possible to use polymorphism?

[Andrea <mar...@go...>]

On 21/10/09 15:55, Luigi Ballabio wrote:
> On Mon, 2009-10-19 at 10:53 +0100, Andrea wrote:
>> I've tried to use polymorphism in QuantLib-SWING Java version
>>
>> Something like
>>
>> class MyPayoff extends Payoff {}
>
> Andrea,
> 	unfortunately, polymorphism doesn't currently work across languages.
> Sorry.
>
> Luigi

Indeed.
I've tried to use directors and it seems to work well if there are no shared_ptr involved.

My problem now is

given

class A; (with some virtual functions)

class B
{
	virtual boost::shared_ptr<A> a() = 0;
};

I don't seem to be able to create a shared_ptr in the target language.
Everything would be very easy if instead of the shared_ptr the code had a raw pointer.
I guess I need some SWIG expert here.

Re: [Quantlib-dev] QuantLib-SWING: is it possible to use polymorphism?

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

On Mon, 2009-10-19 at 10:53 +0100, Andrea wrote:
> I've tried to use polymorphism in QuantLib-SWING Java version
> 
> Something like
> 
> class MyPayoff extends Payoff {}

Andrea,
	unfortunately, polymorphism doesn't currently work across languages.
Sorry.

Luigi



-- 

Ninety percent of everything is crap. 
--- Theodore Sturgeon 

[Quantlib-dev] [ quantlib-Bugs-2883169 ] def events not triggered in fwd time

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

Bugs item #2883169, was opened at 2009-10-21 13:41
Message generated for change (Tracker Item Submitted) made by japaricio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2883169&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: Aparicio-Navarro Jose (japaricio)
Assigned to: Nobody/Anonymous (nobody)
Summary: def events not triggered in fwd time

Initial Comment:
The current code fails to determine the time relevance of an event respect to a contract key when the check is on a forward date. 
To reproduce the bug test for defaults on an issuer on a forward date on an issuer with events in the future but prior to that test forward date.

The problem comes from the test being performed only for the system date in the wrong method. Since the time relevance of a credit event depends on the type of the event (there might be delays for applicability) this should be polymorphically implemented in a separate method to the credit event type match check. 

In the code fix there is a default behaviour in the base class which just tests for hasOccurred, derived classes could implement their own time relevance policies.

impacted files:
issuer.cpp
defaultevent.Xpp

No client code impact.

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

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

Re: [Quantlib-dev] Fwd: Re: [Quantlib-users] CreditDefaultSwap throws RuntimeError

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

Sorry I left this behind. I gave it another thought and I was missing the
situation where the yieldRef date is within one period and the probRef on a
later one.

As a reminder the problem might arise on certain ordering combinations of the
yield and default probability curves reference dates within a schedule.
Intermediate times are defined in a way that might lead to request
probabilities or DFs before the ref dates.

In the midpoint we request probs at the end points of the coupon and DFs at
those plus the default time (midpoint). In the integral we request probs and DFs
at integrations points.

So the midpoint needs:
1.- T_midP  >= refYield
2.- T_effStart >= refYield  <-guaranteed by hasOccurred and def. of effStart
3.- T_end   >= refYield  <-guaranteed by the hasOccurred on the coupon
4.- T_effstart >= refProb
5.- T_end   >= refProb

1.- If today >=refYield this point is guaranteed. It is the mid-point within
the fraction of the interval in the future ('future' defined by the yield ref
date). So it could be before the proba curve ref date. This does not pose a
technical problem since we do not request probabilities at that mid point.
Might pose conscientiousness problems having the default time before prob=1
though. The probRef might be a few coupon periods ahead.

So redefinging:
   87     Date effectiveStartDate =
   88         (startDate <= settlementDate && settlementDate <= endDate) ?
                     settlementDate : startDate;
does the trick.

In general, rather than defining a few extra times as I was saying in previous
posts we could have require arguments_.leg[i]->hasOccurred(refProbDate) on top
of the settlement.....which might leave behind coupons that have not yet
occurred from the Yield point of view.

Or we can require refYield >= refProb to hold; I can make sense of this
situation in terms of the meaning of the probabilities but not of the reverse.
This would seem to address the new CDS convention definitions where
one has partial information today on whether the name has defaulated already,
but thats not what I want to solve now. This inforces 4 & 5 with the current
code.

I would go for this last one, at least is simple, what do you think?

Things are similar for the integration engine.

All this logic might need to be reviewed when the new conventions for the CDS
contracts (the lookback protection in this case) are implemented but thats a
different problem.

Regards
Pepe

PS: I admit you woke me up with the previous mail, but this does not
mean I am sending this for any particular version.

Quoting Luigi Ballabio <lui...@gm...>:

> On Mon, 2009-10-05 at 11:31 +0200, Jose Aparicio-Navarro wrote:
> > Quoting Luigi Ballabio <lui...@gm...>:
> > Yep, lets make it the TS ref date. Moving this
> >
> > Date effectiveStartDate =
> >    (startDate <= today && today <= endDate) ? today : startDate;
> >
> > into:
> >
> > Date effectiveStartDate =
> >     (startDate <= settlementDate && settlementDate <= endDate) ?
> >         settlementDate : startDate;
> >
> > works for both cds engines.
>
> Except I'd leave the start date alone and correct the default date
> instead, if possible. No?
>
> Luigi
>
>
> --
>
> There is no opinion so absurd that some philosopher will not
> express it.
> -- Marcus Tullius Cicero, "Ad familiares"
>
>
>

Re: [Quantlib-dev] SmileSection

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

On Tue, 2009-10-20 at 18:22 +0200, Ferdinando Ametrano wrote:
> And just to get the record straight in public: I trust you on whatever
> design re-factoring you might perform. Always. :-)

...provided that I understand the underlying financial point, that
sometimes you have to beat into my thick skull :)  Thanks for the kind
words, though.

Luigi

P.S. Oh, and I've committed the changes. The class should be more or
less ok now.


-- 

There are no rules of architecture for a castle in the clouds. 
-- Gilbert K. Chesterton 

[Quantlib-dev] About to branch

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

Hi all,
	if nobody objects, I'll branch for release 0.9.9/1.0 later today or
tomorrow.

Luigi


-- 

It is better to know some of the questions than all of the answers. 
-- James Thurber 

Re: [Quantlib-dev] Question to the Leap function in the Date class

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

On Wed, 2009-10-21 at 11:50 +0200, Ferdinando Ametrano wrote:
> I suggest you to just replace the current implementation with
> 
> #include <boost/date_time/gregorian/gregorian.hpp>
> [...]
> namespace QuantLib {
> [...]
>    bool Date::isLeap(Year y) {
>        return boost::gregorian::gregorian_calendar::is_leap_year(y);
>    }
> [...]
> }
> 
> I will commit this change unless objections are raised

Ok, but wait until after we branch for release.

Luigi


-- 

The doctrine of human equality reposes on this: that there is no man 
really clever who has not found that he is stupid. 
-- Gilbert K. Chesterson 

Re: [Quantlib-dev] Question to the Leap function in the Date class

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

Hi Alexander

> I've got an exception using the Date class Leap function. I've checked the
> code and found out that the function is limited to the range 1900..2200.
The
> implementation of the leap function is quite simple. Is there a
performance
> reason to implement it like this? If it is possible I would like to extend
> this function.

I suggest you to just replace the current implementation with

#include <boost/date_time/gregorian/gregorian.hpp>
[...]
namespace QuantLib {
[...]
   bool Date::isLeap(Year y) {
       return boost::gregorian::gregorian_calendar::is_leap_year(y);
    }
[...]
}

I will commit this change unless objections are raised

ciao -- Nando

PS any volunteer for QuantLib::Date boostification, i.e. usage of
boost::gregorian in the implementation of QuantLib::Date ?

Re: [Quantlib-dev] How can I get involved?

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

Hi Scott

welcome 'on board'

> Please let me know how I can become involved

I have a suggestion.

The InterestRateIndex::fixing method uses Index(TimeSeries)Manager to
look for historical fixings. The time series must have been provided
before in order to avoid a "missing fixing" run time exception. In my
current Excel environment this is the operational weakest point.

It would be nice to provide some SourceManager hook before the
exception for run-time queries to an ordered list of sources (DB,
Reuters, Bloomberg) in order to try to get the fixing from the sources
and extend the time series

Of course the hook should be elegant enough to factor all custom
settings, transcodings, configurations, etc in some easy to extend C++
code or XLM config file. QuantLib might ship with an empty code stub
and/or provide examples for Reuters / Bloomberg, SQLite, generic SQL
query, OTL

Even a SQLite refactoring of Index(TimeSeries)Manager would be interesting...

ciao -- Nando

Re: [Quantlib-dev] strange formula

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

On Wed, 2009-10-21 at 07:42 +1100, Mark joshi wrote:
> It does look wrong. All terms should be discounted equally.
> 
> I am a little surprised that the tests for Normal BGM work if the
> Bachelier formula is wrong.

In the current test, all cases are at-the-money forward so d=0 and it
doesn't matter whether d*phi(h) is discounted or not.

Luigi


-- 

No, I'm not interested in developing a powerful brain. All I'm after 
is just a mediocre brain, something like the president of American 
Telephone and Telegraph Company. 
-- Alan Turing on the possibilities of a thinking machine, 1943. 

[Quantlib-dev] Question to the Leap function in the Date class

[Alexander L. <ale...@go...>]

Hello all,

I've got an exception using the Date class Leap function. I've checked the
code and found out that the function is limited to the range 1900..2200. The
implementation of the leap function is quite simple. Is there a performance
reason to implement it like this? If it is possible I would like to extend
this function.

Cheers

Alexander

[Quantlib-dev] How can I get involved?

[Scotty42 <sco...@co...>]

Hello,

I am an out of work quant developer (more a senior developer who has come to
quantitative finance). While I am in am engaged in a career transition, I
would like to lend my skills to the QuantLib project. I am proficient at
C/C++, VB/VBA and database systems and I have worked on both cash &
derivatives based on interest rates, credit & commodities. I am not sure
where to start, but maybe I could work on bug fixes, refactoring/redesign,
extensions and/or creating samples and test suites. Please let me know how I
can become involved.

Regards,
Scott L. Robik
-- 
View this message in context: http://www.nabble.com/How-can-I-get-involved--tp25984770p25984770.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] strange formula

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

It does look wrong. All terms should be discounted equally.

I am a little surprised that the tests for Normal BGM work if the
Bachelier formula is wrong.

best

Mark


2009/10/21 Dima <dim...@go...>:
> Appart from the discount question: there are different versions of the
> original SDE and consequently different formulas:
>
> Page 3, Equation 2.1b:
> - http://www.mat.univie.ac.at/~schachermayer/pubs/preprnts/prpr0121.pdf
>
> Page 3, equation 3
> - http://pascal.iseg.utl.pt/~matfin/publicar/MathFin_MRGrossinho_3.pdf
>
> - There's another one for the standard ABM in a book that I have
>
> In any case the discounting will have to be applied to both terms
>
>
>
>
>
> 2009/10/20 Ferdinando Ametrano <na...@am...>
>>
>> On Tue, Oct 20, 2009 at 6:04 PM, Luigi Ballabio
>> <lui...@gm...> wrote:
>> > Any thoughts? (or facts?)
>> I agree with the correction Chris suggested below.
>> I just would love a confirmation from Mark, since he suggested
>> Bachelier, even if all errors are mine :-)
>>
>> ciao -- Nando
>>
>> > On Tue, 2009-10-13 at 09:18 -0700, Chris Kenyon wrote:
>> >> I don't understand the bachelierBlackFormula in QL which reads (with
>> >> tests removed):
>> >>
>> >> bachelierFormula(Option::Type optionType,
>> >>                                Real strike,
>> >>                                Real forward,
>> >>                                Real stdDev,
>> >>                                Real discount)
>> >>     {
>> >>         ...
>> >>         Real d = (forward-strike)*optionType, h = d/stdDev;
>> >>         if (stdDev==0.0)
>> >>             return discount*std::max(d, 0.0);
>> >>         CumulativeNormalDistribution phi;
>> >>         Real result = discount*stdDev*phi.derivative(h) + d*phi(h);
>> >>
>> >>     return result;
>> >>     }
>> >>
>> >> I think that in the result line the discount should be applied to all
>> >> the terms.  There is no test in the test-suite specifically for the
>> >> bachelier.  The only time it appears is in marketmodel.
>> >>
>> >> Supporting evidence comes from my own derivation (which can be wrong,
>> >> of course) and some books.  In books you have to take care to include
>> >> the discounting because often they are just talking about Bachelier
>> >> (the person) who ignored interest rates.
>> >>
>> >> The other evidence is that the terms have the wrong dimensions, i.e. d
>> >> is (forward-strike) which is paid in the future but is not discounted.
>> >> Hence I don't see any way that the formula can be correct.
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>



-- 
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] strange formula

[Dima <dim...@go...>]

Appart from the discount question: there are different versions of the
original SDE and consequently different formulas:

Page 3, Equation 2.1b:
- http://www.mat.univie.ac.at/~schachermayer/pubs/preprnts/prpr0121.pdf

Page 3, equation 3
- http://pascal.iseg.utl.pt/~matfin/publicar/MathFin_MRGrossinho_3.pdf

- There's another one for the standard ABM in a book that I have

In any case the discounting will have to be applied to both terms





2009/10/20 Ferdinando Ametrano <na...@am...>

> On Tue, Oct 20, 2009 at 6:04 PM, Luigi Ballabio
> <lui...@gm...> wrote:
> > Any thoughts? (or facts?)
> I agree with the correction Chris suggested below.
> I just would love a confirmation from Mark, since he suggested
> Bachelier, even if all errors are mine :-)
>
> ciao -- Nando
>
> > On Tue, 2009-10-13 at 09:18 -0700, Chris Kenyon wrote:
> >> I don't understand the bachelierBlackFormula in QL which reads (with
> >> tests removed):
> >>
> >> bachelierFormula(Option::Type optionType,
> >>                                Real strike,
> >>                                Real forward,
> >>                                Real stdDev,
> >>                                Real discount)
> >>     {
> >>         ...
> >>         Real d = (forward-strike)*optionType, h = d/stdDev;
> >>         if (stdDev==0.0)
> >>             return discount*std::max(d, 0.0);
> >>         CumulativeNormalDistribution phi;
> >>         Real result = discount*stdDev*phi.derivative(h) + d*phi(h);
> >>
> >>     return result;
> >>     }
> >>
> >> I think that in the result line the discount should be applied to all
> >> the terms.  There is no test in the test-suite specifically for the
> >> bachelier.  The only time it appears is in marketmodel.
> >>
> >> Supporting evidence comes from my own derivation (which can be wrong,
> >> of course) and some books.  In books you have to take care to include
> >> the discounting because often they are just talking about Bachelier
> >> (the person) who ignored interest rates.
> >>
> >> The other evidence is that the terms have the wrong dimensions, i.e. d
> >> is (forward-strike) which is paid in the future but is not discounted.
> >> Hence I don't see any way that the formula can be correct.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] strange formula

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

On Tue, Oct 20, 2009 at 6:04 PM, Luigi Ballabio
<lui...@gm...> wrote:
> Any thoughts? (or facts?)
I agree with the correction Chris suggested below.
I just would love a confirmation from Mark, since he suggested
Bachelier, even if all errors are mine :-)

ciao -- Nando

> On Tue, 2009-10-13 at 09:18 -0700, Chris Kenyon wrote:
>> I don't understand the bachelierBlackFormula in QL which reads (with
>> tests removed):
>>
>> bachelierFormula(Option::Type optionType,
>>                                Real strike,
>>                                Real forward,
>>                                Real stdDev,
>>                                Real discount)
>>     {
>>         ...
>>         Real d = (forward-strike)*optionType, h = d/stdDev;
>>         if (stdDev==0.0)
>>             return discount*std::max(d, 0.0);
>>         CumulativeNormalDistribution phi;
>>         Real result = discount*stdDev*phi.derivative(h) + d*phi(h);
>>
>>     return result;
>>     }
>>
>> I think that in the result line the discount should be applied to all
>> the terms.  There is no test in the test-suite specifically for the
>> bachelier.  The only time it appears is in marketmodel.
>>
>> Supporting evidence comes from my own derivation (which can be wrong,
>> of course) and some books.  In books you have to take care to include
>> the discounting because often they are just talking about Bachelier
>> (the person) who ignored interest rates.
>>
>> The other evidence is that the terms have the wrong dimensions, i.e. d
>> is (forward-strike) which is paid in the future but is not discounted.
>> Hence I don't see any way that the formula can be correct.

Re: [Quantlib-dev] SmileSection

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

On Tue, Oct 20, 2009 at 5:10 PM, Luigi Ballabio
<lui...@gm...> wrote:
> initializeExerciseTime should be protected, right?

yes it should.

And just to get the record straight in public: I trust you on whatever
design re-factoring you might perform. Always. :-)

ciao -- Nando

PS ok, well... almost always ;-)

Re: [Quantlib-dev] strange formula

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

Nando,
	following up on Chris' report (quoted below for the people on
quantlib-dev joining us after the break; hi, fellows.)  I tried making
the correction and running the market-model test (which, it appears, is
truly the only place where the formula is used, besides being exported
to Excel.)  The min and max errors don't change at all---I guess
d*phi(h) is too low to make a difference in that case---so there's no
conclusive evidence.  However, some research seems to support Chris'
view that the discount should be applied to both terms.

Any thoughts? (or facts?)

Thanks,
	Luigi



On Tue, 2009-10-13 at 09:18 -0700, Chris Kenyon wrote:
> I don't understand the bachelierBlackFormula in QL which reads (with
> tests removed):
> 
> bachelierFormula(Option::Type optionType,
>                                Real strike,
>                                Real forward,
>                                Real stdDev,
>                                Real discount)
>     {
>         ...
>         Real d = (forward-strike)*optionType, h = d/stdDev;
>         if (stdDev==0.0)
>             return discount*std::max(d, 0.0);
>         CumulativeNormalDistribution phi;
>         Real result = discount*stdDev*phi.derivative(h) + d*phi(h);
> 
>     return result;
>     }
> 
> I think that in the result line the discount should be applied to all
> the terms.  There is no test in the test-suite specifically for the
> bachelier.  The only time it appears is in marketmodel.
> 
> Supporting evidence comes from my own derivation (which can be wrong,
> of course) and some books.  In books you have to take care to include
> the discounting because often they are just talking about Bachelier
> (the person) who ignored interest rates.
> 
> The other evidence is that the terms have the wrong dimensions, i.e. d
> is (forward-strike) which is paid in the future but is not discounted.
> Hence I don't see any way that the formula can be correct.
> 
> I don't want to change it without some feedback but I do think it need
> changing.
> 
> Best,
> Chris
> 
> 
> 

-- 

Just remember what ol' Jack Burton does when the earth quakes, the 
poison arrows fall from the sky, and the pillars of Heaven shake. Yeah, 
Jack Burton just looks that big old storm right in the eye and says, 
"Give me your best shot. I can take it." 
-- Jack Burton, "Big trouble in Little China" 

Re: [Quantlib-dev] SmileSection

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

On Tue, 2009-10-20 at 16:06 +0200, Ferdinando Ametrano wrote:
> On Tue, Oct 20, 2009 at 3:25 PM, Luigi Ballabio
> <lui...@gm...> wrote:
> > Oh---and also smileSection->volatility(Null<Real>()) returning the ATM
> > volatility [*], when there's a perfectly serviceable atmLevel method
> > that can be used for writing volatility(atmLevel()).
> 
> The point here is:
> 1) to have the interface gracefully degrade to the flat-smile case
> 2) the traders I work for claim it's too much effort to specify a
> strike even for non-flat smile, since unless differently specified,
> volatility tout-court is the atm one

Well, I'm a lazy Italian myself, but in this case I'd go for clarity :)


> > why is exerciseTime() public when it's only used internally?
> no strong reason beside he fact that all termstructures' interfaces
> are also time based so it might be sensible for a smile to know where
> it stands along the time dimension

Point taken.  It stays public then.

On the other hand, initializeExerciseTime should be protected, right?

Luigi


-- 

Glendower: I can call spirits from the vasty deep. 
Hotspur: Why, so can I, or so can any man; 
But will they come when you do call for them? 
-- King Henry the Fourth Part I, Act III, Scene I 

Re: [Quantlib-dev] SmileSection

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

On Tue, 2009-10-20 at 07:16 -0700, Chris Kenyon wrote:
> In fact why bother with Impl methods at all?  Why not just make
> volatility and variance virtual?  PIMPL is handy when the implementers
> can be changed (i.e. ptr to another class) but just calling another
> method doesn't really seem to qualify.  Just my musings.

In this case it's not pimpl, it's Template Method. I guess it was
written this way to mimic the other term structures, even if there's no
added functionality in this case (there could be, though---e.g., in
volatility() one could check the strike limits.)

Luigi


-- 

Lubarsky's Law of Cybernetic Entomology: 
There is _always_ one more bug. 

Re: [Quantlib-dev] SmileSection

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

On Tue, 2009-10-20 at 15:11 +0200, Ferdinando Ametrano wrote:
> On Tue, Oct 20, 2009 at 2:46 PM, Chris Kenyon <chr...@ya...> wrote:
> Anyway I wonder if we might reserve exerciseTime for
> time-from-referenceDate()-to-exercise and then deal with
> time-for-volatility-to-build-up in volatilityImpl / varianceImpl.
> Would this choice make your code more complex or unnatural ?
> I.e. add a varianceTime (time-for-volatility-to-build-up) when it is
> not equal to exerciseTime (time-from-referenceDate()-to-exercise)

I raise:  why is exerciseTime() public when it's only used internally?

Luigi


-- 

Never mistake motion for action. 
-- Ernest Hemingway