american options delta leads to seg.fault.

[Dirk Eddelbuettel]

All,

This is similar to the one I reported last week concerning barrier options.
In this case a simple delta() call on an American option leads to a
seg.fault.  There is a fair chance that I am setting this up the wrong --
suggestions would be welcome -- but I guess QL should not segfault.

Here is how I am building and running the example leading to the segfault:

edd@basebud:/tmp> g++ -Wall -o ao_segfault ao_segfault.cc -lQuantLib
edd@basebud:/tmp> ./ao_segfault
Value: 11.3656
Aborted (core dumped)
edd@basebud:/tmp>

The code is below.

Regards,  Dirk



#include <ql/quantlib.hpp> // make QuantLib known

using namespace QuantLib;

extern "C" {

  Handle<TermStructure> makeFlatCurve(const Handle<Quote>& forward,
                                      DayCounter dc) {
    Date today = Date::todaysDate();
    return Handle<TermStructure>(
         new FlatForward(today, today,
                         RelinkableHandle<Quote>(forward), dc));
  }

  Handle<BlackVolTermStructure> makeFlatVolatility(const Handle<Quote>& vol,
                                                     DayCounter dc) {
    Date today = Date::todaysDate();
    return Handle<BlackVolTermStructure>(
         new BlackConstantVol(today,
                              RelinkableHandle<Quote>(vol), dc));
  }

  enum EngineType { Analytic,
                    JR, CRR, EQP, TGEO, TIAN, LR,
                    PseudoMonteCarlo, QuasiMonteCarlo };

  Handle<VanillaOption>
  makeOption(const Handle<StrikedTypePayoff>& payoff,
             const Handle<Exercise>& exercise,
             const Handle<Quote>& u,
             const Handle<TermStructure>& q,
             const Handle<TermStructure>& r,
             const Handle<BlackVolTermStructure>& vol,
             EngineType engineType) {

    Size binomialSteps = 251;
    Handle<PricingEngine> engine;
    switch (engineType) {
    case Analytic:
      engine = Handle<PricingEngine>(new AnalyticEuropeanEngine);
      break;
    case JR:
      engine = Handle<PricingEngine>(
                 new BinomialVanillaEngine<JarrowRudd>(binomialSteps));
      break;
    case CRR:
      engine = Handle<PricingEngine>(
                new BinomialVanillaEngine<CoxRossRubinstein>(binomialSteps));
    case EQP:
      engine = Handle<PricingEngine>(
                new BinomialVanillaEngine<AdditiveEQPBinomialTree>(
                                                           binomialSteps));
      break;
    case TGEO:
      engine = Handle<PricingEngine>(
                new BinomialVanillaEngine<Trigeorgis>(binomialSteps));
      break;
    case TIAN:
      engine = Handle<PricingEngine>(
                new BinomialVanillaEngine<Tian>(binomialSteps));
      break;
    case LR:
      engine = Handle<PricingEngine>(
                new BinomialVanillaEngine<LeisenReimer>(binomialSteps));
      break;
    case PseudoMonteCarlo:
      engine = MakeMCEuropeanEngine<PseudoRandom>().withStepsPerYear(1)
        .withTolerance(0.05)
        .withSeed(42);
      break;
    case QuasiMonteCarlo:
      engine = MakeMCEuropeanEngine<LowDiscrepancy>().withStepsPerYear(1)
        .withSamples(1023);
      break;
    default:
      QL_FAIL("Unknown engine type");
    }


    Handle<BlackScholesStochasticProcess>
      stochProcess(new
         BlackScholesStochasticProcess(
             RelinkableHandle<Quote>(u),
             RelinkableHandle<TermStructure>(q),
             RelinkableHandle<TermStructure>(r),
             RelinkableHandle<BlackVolTermStructure>(vol)));

    return
      Handle<VanillaOption>(new
            VanillaOption(stochProcess, payoff, exercise, engine));
  }

  int main(void) {
   
    Option::Type optionType = Option::Call;
    Date today = Date::todaysDate();

    double underlying = 100;
    double strike = 100;
    Spread dividendYield = 0.02;
    Rate riskFreeRate = 0.03;
    Time maturity = 0.5;
    int length = int(maturity * 360); // FIXME: this could be better
    double volatility = 0.4;

    // new framework as per QuantLib 0.3.5
    DayCounter dc = Actual360();
    Handle<SimpleQuote> spot(new SimpleQuote(0.0));
    Handle<SimpleQuote> vol(new SimpleQuote(0.0));
    Handle<BlackVolTermStructure> volTS = makeFlatVolatility(vol,dc);
    Handle<SimpleQuote> qRate(new SimpleQuote(0.0));
    Handle<TermStructure> qTS = makeFlatCurve(qRate, dc);
    Handle<SimpleQuote> rRate(new SimpleQuote(0.0));
    Handle<TermStructure> rTS = makeFlatCurve(rRate, dc);

    Date exDate = today.plusDays(length);
    Handle<Exercise> exercise(new EuropeanExercise(exDate));
    //Handle<Exercise> exercise(new AmericanExercise(today, exDate));
    Handle<StrikedTypePayoff>
      payoff(new PlainVanillaPayoff(optionType, strike));
    Handle<VanillaOption> option = makeOption(payoff, exercise, spot,
                                              qTS, rTS, volTS,
                                              JR); // engine
                                              //TGEO); // engine
    spot->setValue(underlying);
    qRate->setValue(dividendYield);
    rRate->setValue(riskFreeRate);
    vol->setValue(volatility);


    std::cout << "Value: " << option->NPV() << std::endl;
    std::cout << "Delta: " << option->delta() << std::endl;

  }
}





--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[Luigi Ballabio-2]

On 2004.04.05 05:54, Dirk Eddelbuettel wrote:
> This is similar to the one I reported last week concerning barrier
> options.
> In this case a simple delta() call on an American option leads to a
> seg.fault.  There is a fair chance that I am setting this up the  
> wrong--suggestions would be welcome -- but I guess QL should not  
> segfault.

Dirk,
        write your main() as:

int main() {

    try {

        ... your stuff here ...

    } catch (std::exception& e) {
        std::cout << e.what() << std::endl;
    }

}

and the segfault will go away. What happens is that the current  
implementation of binomial engines do not provide greeks, and QuantLib  
signals it by throwing an exception when delta() is called.

HTH,
        Luigi

[Dirk Eddelbuettel]

Luigi,

On Mon, Apr 05, 2004 at 01:07:28PM +0200, Luigi Ballabio wrote:
> and the segfault will go away. What happens is that the current  
> implementation of binomial engines do not provide greeks, and QuantLib  

Ah.

> signals it by throwing an exception when delta() is called.

Ok, thanks. Do any of the other engines provide greeks? Would be nice to
still provide them for American options as I used to before 0.3.5.

Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[Ferdinando M. Ametrano-3]

Hi Dirk

>Do any of the other engines provide greeks? Would be nice to
>still provide them for American options as I used to before 0.3.5.

The (old) Finite Difference pricers provide greeks. Unfortunately they
haven't been upgraded to the (new) pricing engine framework yet.

ciao -- Nando

[Ferdinando M. Ametrano-3]

>Do any of the other engines provide greeks? Would be nice to
>still provide them for American options as I used to before 0.3.5.

BTW I hope to provide delta/gamma/theta for all the binomial engines before
0.3.7
I would like to implement the 3-nodes trick, that is to have a tree with
three nodes instead of one at the t=0.0 root: this should provide delta and
gamma, then use Black-Scholes for theta.

ciao -- Nando

[Dirk Eddelbuettel]

Nando,

On Mon, Apr 05, 2004 at 05:10:25PM +0200, Ferdinando Ametrano wrote:
> >Do any of the other engines provide greeks? Would be nice to
> >still provide them for American options as I used to before 0.3.5.
>
> The (old) Finite Difference pricers provide greeks. Unfortunately they
> haven't been upgraded to the (new) pricing engine framework yet.

Could we possibly settle on an understanding that while they are net yet
available in the new framework, we do not nuke the old one?

As you had gently nudged me to convert my few functions to the new pricers
(which I did, and I can live with barrieroptions without greeks), I would
prefer to release the American option code with greeks. Which requires the
old pricer.

Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[Ferdinando M. Ametrano-3]

Hi Dirk

>Could we possibly settle on an understanding that while they are net yet
>available in the new framework, we do not nuke the old one?
Of course this is the approach we have adopted. Even more: when a new
feature is available in a  new release the old equivalent feature is just
deprecated, not nuked. Then in the next release it will be removed.

>As you had gently nudged me to convert my few functions to the new pricers
>(which I did, and I can live with barrieroptions without greeks), I would
>prefer to release the American option code with greeks. Which requires the
>old pricer.
to the best of my knowledge the old pricer FdAmericanOption is still there:
I use it for QuantLibXL! Please let me know if you have problems with it.

Dirk: if we could have the R extension code in a CVS repository I would try
to take care of its  code requirements while developing/changing QuantLib.

ciao -- Nando

[Dirk Eddelbuettel]

On Mon, Apr 05, 2004 at 06:45:01PM +0200, Ferdinando Ametrano wrote:
> Dirk: if we could have the R extension code in a CVS repository I would try
> to take care of its  code requirements while developing/changing QuantLib.

That's probably a good idea. Shall we add it as a branch in the main QL
repository, or should we keep it apart?

I have RQuantLib 0.1.8 (for QL 0.3.5) almost ready. Once I roll that, we
could insert its tarball.

Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[Ferdinando M. Ametrano-3]

Hi Dirk

> > if we could have the R extension code in a CVS repository I would try
> > to take care of its  code requirements while developing/changing QuantLib.
>
>That's probably a good idea. Shall we add it as a branch in the main QL
>repository, or should we keep it apart?

On one hand I would prefer to have it in the main QL repository, on the
other hand the R extension is GPL, so there could be some confusion
about/with the QuantLib (BSD) license.

My opinion is that unless you release the R extension under the QuantLib
license it would be better to have a dedicated SourceForge project. It
could be a QuantLibR project or even a QuantLibGNU project to host any
present and future GPL extension for QuantLib.

What is your preference Dirk?

ciao -- Nando

[Dirk Eddelbuettel]

On Tue, Apr 06, 2004 at 04:31:43PM +0200, Ferdinando Ametrano wrote:

> Hi Dirk
>
> >> if we could have the R extension code in a CVS repository I would try
> >> to take care of its  code requirements while developing/changing
> >QuantLib.
> >
> >That's probably a good idea. Shall we add it as a branch in the main QL
> >repository, or should we keep it apart?
>
> On one hand I would prefer to have it in the main QL repository, on the
> other hand the R extension is GPL, so there could be some confusion
> about/with the QuantLib (BSD) license.
>
> My opinion is that unless you release the R extension under the QuantLib
> license it would be better to have a dedicated SourceForge project. It
> could be a QuantLibR project or even a QuantLibGNU project to host any
> present and future GPL extension for QuantLib.
>
> What is your preference Dirk?

Ok, how about if we put it on alioth.debian.org then?  Non-debianers get
accounts there too, and the codebase is the common sourceforge code before
it went non-free.

Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[Ferdinando M. Ametrano-3]

Hi Dirk

>Ok, how about if we put it on alioth.debian.org then?  Non-debianers get
>accounts there too, and the codebase is the common sourceforge code before
>it went non-free.

it is OK for me.

ciao -- Nando

[Luigi Ballabio-2]

On 2004.04.05 17:15, Ferdinando Ametrano wrote:
> BTW I hope to provide delta/gamma/theta for all the binomial engines  
> before 0.3.7

Nando,
        stop making promises you won't be able to maintain. That's what  
marketing people do :)

Later,
        Luigi

[Luigi Ballabio-2]

Dirk,
        it was impliedVolatility() that gave problems with the old  
American, right? What happens if you edit ql/argsandresults.hpp and  
change line 27 to
#define QL_MIN_VOLATILITY 1.0e-5
(apart from a big recompilation, that is :)

Later,
        Luigi

[Ferdinando M. Ametrano-3]

At 05:09 PM 4/6/2004, Luigi Ballabio wrote:
>On 2004.04.05 17:15, Ferdinando Ametrano wrote:
>>BTW I hope to provide delta/gamma/theta for all the binomial engines
>>before 0.3.7
>
>Nando,
>         stop making promises you won't be able to maintain. That's what
>marketing people do :)

Ok, so this means that now you've cornered me and I really have to do it,
isn't it? :)

ciao -- Nando

[Dirk Eddelbuettel]

Luigi,

On Tue, Apr 06, 2004 at 05:23:17PM +0200, Luigi Ballabio wrote:
>
> Dirk,
> it was impliedVolatility() that gave problems with the old  
> American, right? What happens if you edit ql/argsandresults.hpp and  

Not that I recall :)   Maybe at a point in time way back; right now I was
just trying to use binomial pricer analytics that don't exist.  But I have
to go over RQL in more detail anyway...

> change line 27 to
> #define QL_MIN_VOLATILITY 1.0e-5
> (apart from a big recompilation, that is :)

I'll keep that in mind.

Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page