quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] 0.3.6 release

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

Hi all,
	tarballs for the 0.3.6 release (basically 0.3.5 with the  
implied-volatility bug fixed) are available at http://quantlib.org/gm

Since the bug was a serious one, we're releasing the tarballs  
immediately. Unfortunately, this implies that Win32, Debian, Fink and  
RPM packages will lag a few days behind. But I trust this won't be a  
problem.

Later,
	Luigi

Re: [Quantlib-dev] impliedVolatility() bug

[Dirk E. <ed...@de...>]

On Wed, Apr 14, 2004 at 05:13:50PM +0200, Luigi Ballabio wrote:
> 
> Hi all,
> 	this was a nasty one. I'm flirting with the idea of fixing the  
> bug on the 0.3.5 branch and re-releasing it as 0.3.6. Thoughts?

Go for it!  As they say: "Release early, release often".

No harm in finding bugs and fixing them, only in keeping'em under the carpet.

Dirk

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

[Quantlib-dev] impliedVolatility() bug

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

Hi all,
	this was a nasty one. I'm flirting with the idea of fixing the  
bug on the 0.3.5 branch and re-releasing it as 0.3.6. Thoughts?

Later,
	Luigi

[Quantlib-dev] Bug in implied volatility - please read

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

Hi all,
	I just fixed in CVS a serious bug in the impliedVolatility()  
method of all classes derived from OneAssetOption (you can check the  
documentation to see the affected classes) which slipped through the  
test suite and could cause wrong results to be returned if a certain  
sequence of actions were performed. We might consider releasing  
QuantLib 0.3.6 sooner than we thought. In the meantime, here is the way  
to avoid triggering the bug:

a) if you mean to call the impliedVolatility() method on such an  
option, do not pass it a Handle<StochasticProcess> you already passed  
(or intend to pass) to another instrument. Create a new Handle  
containing a newly-allocated process.
b) impliedVolatility() will return the right result. However, after  
calling impliedVolatility(), the option is broken. You might as well  
throw it away and instantiate a new one.

Sorry for the inconvenience,
				Luigi

[Quantlib-dev] [ quantlib-Bugs-934626 ] Excel is hung when calling qlAmericanOption_FD

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

Bugs item #934626, was opened at 2004-04-13 17:09
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=934626&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Excel is hung when calling qlAmericanOption_FD

Initial Comment:
it seems it only happens when the Type = C, and when 
the function template is used.

XL version = 0.35,
OS = XP Professional SP1;
QuantLib & QuantLibXL are compiled off the source code 
by the user using the 0.35 release.



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

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

[Quantlib-dev] Happy Easter everybody!

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

Cheers,
	Luigi

[Quantlib-dev] [ quantlib-Feature Requests-931122 ] RPM SPEC change

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

Feature Requests item #931122, was opened at 2004-04-07 17:14
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=931122&group_id=12740

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Jorge Godoy (godoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM SPEC change

Initial Comment:
It should be interesting to add '-f' to the lines that
'rm' the testing suit from the building directory.

Those lines make the building fail if there's no prior
copy of QuantLib.

Such a change causes no collateral damage, also.

I'm adding a patch that will do such a change.


Thanks for the software! :-)



Jorge Godoy.

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2004-04-09 16:45

Message:
Logged In: YES 
user_id=75450

Jorge,
    it's fixed in CVS now.

Thanks,
        Luigi


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

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

[Quantlib-dev] [ quantlib-Feature Requests-931122 ] RPM SPEC change

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

Feature Requests item #931122, was opened at 2004-04-07 12:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=931122&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Jorge Godoy (godoy)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM SPEC change

Initial Comment:
It should be interesting to add '-f' to the lines that
'rm' the testing suit from the building directory.

Those lines make the building fail if there's no prior
copy of QuantLib.

Such a change causes no collateral damage, also.

I'm adding a patch that will do such a change.


Thanks for the software! :-)



Jorge Godoy.

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

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

Re: [Quantlib-dev] american options delta leads to seg.fault.

[Dirk E. <ed...@de...>]

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

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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 

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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 

Re: [Quantlib-dev] american options delta leads to seg.fault.

[Dirk E. <ed...@de...>]

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

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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 

Re: [Quantlib-dev] american options delta leads to seg.fault.

[Dirk E. <ed...@de...>]

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

Re: [Quantlib-dev] QuantLib-Ruby patch

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

On 2004.04.06 04:09, Mark Treiber wrote:
> I've attached a patch that adds darwin support to QuantLib-Ruby.

Applied, thanks.

Later,
	Luigi

[Quantlib-dev] QuantLib-Ruby patch

[Mark T. <mrt...@en...>]

I've attached a patch that adds darwin support to QuantLib-Ruby.  The 
patch does two things.  The first is that it converts the Binaries 
array (which was an array with a single value anyways) into a string so 
that it supports compiling to a .so as well as a .bundle for darwin.  
The binaries variable then replaces all instances of QuantLibc.so.  The 
second part is that darwin now follows the linux build branches which 
requires additionally modifications to the cfg['LDFLAGS'] variable.  
The changes shouldn't affect the linux build but it should be test 
anyways.

Mark.

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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 

Re: [Quantlib-dev] american options delta leads to seg.fault.

[Dirk E. <ed...@de...>]

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

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

>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 

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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 

Re: [Quantlib-dev] american options delta leads to seg.fault.

[Dirk E. <ed...@de...>]

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

Re: [Quantlib-dev] american options delta leads to seg.fault.

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

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

[Quantlib-dev] american options delta leads to seg.fault.

[Dirk E. <ed...@de...>]

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