quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Heads up - 0.3.5

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

Hi all,
	I'll be branching for release 0.3.5 in a couple of days.  
Anybody wanting to contribute new code for the release (possibly minor  
additions--I wouldn't throw big changes in at this point, so I might  
revert the change and re-contribute it on the trunk afterwards) should  
do so now.

The above applies to new features--the branch will of course be open  
for bug-fixes before the actual release.

Later,
	Luigi

[Quantlib-dev] [ quantlib-Feature Requests-910972 ] Add Greeks to Binomial Vanilla Engine

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

Feature Requests item #910972, was opened at 2004-03-06 07:41
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=910972&group_id=12740

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Greeks to Binomial Vanilla Engine

Initial Comment:
delta, gamma, theta, vega, rho, etc.  ought to be added 
to the binomial vanilla engine.   many would consider 
this "core" functionality of any serious library.  if i can 
find the time, i will look into it myself as Luigi and others 
have suggested.  phil k. (wr...@ya...)

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

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

[Quantlib-dev] [ quantlib-Bugs-899650 ] Svd GetV routine bug

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Svd GetV routine bug

Initial Comment:
There seems to be a problem with the singular value 
decomposition getV() routine.  beyond the first row, the 
right singular vectors (rows of the "V" matrix) are being 
returned with bad values.  Rick 
(wdg...@ya...)

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2004-03-02 14:10

Message:
Logged In: YES 
user_id=75450

The report could not be verified (the class passes its unit
test, and no test case was provided where it fails.)


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

Comment By: Luigi Ballabio (lballabio)
Date: 2004-02-27 17:27

Message:
Logged In: YES 
user_id=75450

The SVD routine does pass consistency tests added to the 
test-suite. Do you have any test case to show for which it 
doesn't work?

Thanks,
        Luigi


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

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

Re: [Quantlib-dev] Warming up for 0.3.5

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

On 2004.02.16 10:25, Ferdinando Ametrano wrote:
> At 10:27 AM 2/13/2004, Luigi Ballabio wrote:
>>         it'd be nice to roll out release 0.3.5 sometime during March
> It's ok with me. I would go for a freeze in late February or early  
> March, with target release date late March.

Hi all,
	it might be time for a quick check.

>> What is the status?
> Few tests fail with Borland because of some 0/0 in the code.
> The same (?) tests fail with Visual C++ if _controlfp(_EM_INEXACT,  
> _MCW_EM ) is enforced (see  
> http://www.wilmott.com/messageview.cfm?catid=10&threadid=9481)
> I think we should solve this issue.

Hmm. Tricky. One should run the tests in the debugger until he finds  
the division by zero. But I'm not sure that I have the time to do it  
right now. Unless someone volunteers to tackle it, it's going to be  
fixed in the release after this one.

What I would do in any case is add a list of known bugs to the  
distribution.

> There are 3 open bugs:  
> http://sourceforge.net/tracker/?group_id=12740&atid=112740
> The last one it's easy to fix, the first two are open since April and  
> September 2002 :(

Ditto. Known bugs---except for the Veteran Day thing which is small  
enough.

> There are also 2 feature requests  
> (http://sourceforge.net/tracker/?group_id=12740&atid=362740): the  
> first one will stay open for a long time, what about the second one?

Well, what can I say? The mere thought of automatically replacing  
double with Real throughout fill me with dread :)

Were I to do it, at least I would use the occasion to go through the  
class interfaces and check whether a given double should be replaced  
with a generic Real or a more specific Rate, DiscountFactor, Spread,  
Volatility (do we have this one?) or whatever. Then I could set loose  
an automatic replace on the remaining doubles (those inside method and  
function bodies.)

But this takes time too, so it would probably be done best bit by bit.  
Needless to say, it wouldn't be done for this release :)

> Last but not least the multi-dimensional Monte Carlo simulation  
> framework should probably be labelled as beta for the time being, at  
> least until it is proven to work with Brownian Bridge + low  
> discrepancy sequences

Ok for me.

Thoughts? Any other issue? When should we create the 0.3.5 branch?

Later,
	Luigi

[Quantlib-dev] [ quantlib-Bugs-899650 ] Svd GetV routine bug

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Svd GetV routine bug

Initial Comment:
There seems to be a problem with the singular value 
decomposition getV() routine.  beyond the first row, the 
right singular vectors (rows of the "V" matrix) are being 
returned with bad values.  Rick 
(wdg...@ya...)

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2004-02-27 17:27

Message:
Logged In: YES 
user_id=75450

The SVD routine does pass consistency tests added to the 
test-suite. Do you have any test case to show for which it 
doesn't work?

Thanks,
        Luigi


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

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

Re: [Quantlib-dev] Warming up for 0.3.5

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

On 2004.02.17 00:47, Liguo Song wrote:
> RPM source package should be OK, right?

Yes, they should. However, I'll make the usual test tarball before  
release. We can check at that time.

Later,
	Luigi

[Quantlib-dev] [ quantlib-Bugs-899650 ] Svd GetV routine bug

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

Bugs item #899650, was opened at 2004-02-18 07:42
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=899650&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Svd GetV routine bug

Initial Comment:
There seems to be a problem with the singular value 
decomposition getV() routine.  beyond the first row, the 
right singular vectors (rows of the "V" matrix) are being 
returned with bad values.  Rick 
(wdg...@ya...)

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

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

Re: [Quantlib-dev] Warming up for 0.3.5

[Liguo S. <lig...@va...>]

On Mon, 16 Feb 2004, Luigi Ballabio wrote:

> On 2004.02.16 10:25, Ferdinando Ametrano wrote:
> > For 0.3.5 I would prefer not to ship binaries. My idea is that  
> > QuantLib is for quantitative developers that must be able to  
> > recompile the library, and should be able to compile and run the test  
> > suite. What do you think about it?
> 
> I second that. As a matter of fact, I've been arguing that for quite  
> some time :)
RPM source package should be OK, right? It is just that managing
installation and upgrade is much easier with RPM. Recompiling and
running test suite is all part of the source RPM.

Re: [Quantlib-dev] Warming up for 0.3.5

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

On 2004.02.16 10:25, Ferdinando Ametrano wrote:
> For 0.3.5 I would prefer not to ship binaries. My idea is that  
> QuantLib is for quantitative developers that must be able to  
> recompile the library, and should be able to compile and run the test  
> suite. What do you think about it?

I second that. As a matter of fact, I've been arguing that for quite  
some time :)

> If I got it right boost is going to be optional for 0.3.5. I for one  
> vote to have it as requirement for 0.3.6: if everybody agree we  
> should make clear that 0.3.5 is transitional toward boost.

Yes, that was the idea.

> BTW Luigi: any chance about using the boost test suite instead of  
> cppunit? Have you ever compared the two approaches?

Yes, I've been looking at the boost test framework for another project.  
It should be relatively painless to switch.

Later,
	Luigi

Re: [Quantlib-dev] Warming up for 0.3.5

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

At 10:27 AM 2/13/2004, Luigi Ballabio wrote:
>         it'd be nice to roll out release 0.3.5 sometime during March
It's ok with me. I would go for a freeze in late February or early March, 
with target release date late March.

>What is the status?
Few tests fail with Borland because of some 0/0 in the code.
The same (?) tests fail with Visual C++ if _controlfp(_EM_INEXACT, _MCW_EM 
) is enforced (see 
http://www.wilmott.com/messageview.cfm?catid=10&threadid=9481)
I think we should solve this issue.

There are 3 open bugs: 
http://sourceforge.net/tracker/?group_id=12740&atid=112740
The last one it's easy to fix, the first two are open since April and 
September 2002 :(

There are also 2 feature requests 
(http://sourceforge.net/tracker/?group_id=12740&atid=362740): the first one 
will stay open for a long time, what about the second one?

>  Is anybody working (or about to work) on something
>he'd like to finish before the 0.3.5 branch is created?
Yes, I would like to finish few things about interpolation I was working 
on. Of course should it take longer than the end of February it will ship 
in 0.3.6

For 0.3.5 I would prefer not to ship binaries. My idea is that QuantLib is 
for quantitative developers that must be able to recompile the library, and 
should be able to compile and run the test suite. What do you think about it?

I will try to upgrade the Win32 installer to NSIS 2

If I got it right boost is going to be optional for 0.3.5. I for one vote 
to have it as requirement for 0.3.6: if everybody agree we should make 
clear that 0.3.5 is transitional toward boost. BTW Luigi: any chance about 
using the boost test suite instead of cppunit? Have you ever compared the 
two approaches?

Last but not least the multi-dimensional Monte Carlo simulation framework 
should probably be labelled as beta for the time being, at least until it 
is proven to work with Brownian Bridge + low discrepancy sequences

ciao -- Nando 

[Quantlib-dev] Warming up for 0.3.5

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

Hi all,
	it'd be nice to roll out release 0.3.5 sometime during March  
(you know, spring and all that :)
What is the status? Is anybody working (or about to work) on something  
he'd like to finish before the 0.3.5 branch is created?

Later,
	Luigi

Re: [Quantlib-dev] Undefined symbol

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

On 2004.02.03 08:09, Andre Louw wrote:
> BlackVolTermStructure (documented as an abstract class) defines 3
> virtual functions, timeDerivative,strikeDerivative, 
> strikeSecondDerivative. On the SWIG side it is used as a class, which  
> results in undefined symbols when importing QuantLib in Python!?

Andre,
	BlackVolTermStructure no longer defines those functions---at  
least since version 0.3.4. Are you sure you're not including some old  
version you got lying around?

Later,
	Luigi

[Quantlib-dev] multipathgenerator.hpp

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

Hi all

line 122 and 128 of multipathgenerator.hpp: sqrt_dt is defined and assigned 
a value but it is never
used. Should I be worried?

Sorry I don't have time enough to read and understand the full code now...

ciao -- Nando

===========================

template <class SG>
inline const typename MultiPathGenerator<SG>::sample_type&
MultiPathGenerator<SG>::next() const {
     typedef typename SG::sample_type sequence_type;
     const sequence_type& sequence_ = generator_.nextSequence();

     Array asset(numAssets_);
     Array temp(numAssets_);
     next_.weight = sequence_.weight;

     for (Size j = 0; j < numAssets_; j++) {
         asset[j] = diffusionProcs_[j]->x0();
     }

     TimeGrid timeGrid = next_.value[0].timeGrid();
     double dt;
     double sqrt_dt;
     Time t;
     for (Size i = 0; i < next_.value[0].size(); i++) {
         Size offset = i*numAssets_;
         t = timeGrid[i+1];
         dt = timeGrid.dt(i);
         sqrt_dt = QL_SQRT(dt);
         std::copy(sequence_.value.begin()+offset,
                   sequence_.value.begin()+offset+numAssets_,
                   temp.begin());

         temp = sqrtCorrelation_ * temp;

         for (Size j=0; j<numAssets_; j++) {
             next_.value[j].drift()[i] = dt * diffusionProcs_[j]->drift(t, 
asset[j]);
             next_.value[j].diffusion()[i] = - temp[j] *
                QL_SQRT(diffusionProcs_[j]->variance(t, asset[j], dt));
             asset[j] *= QL_EXP(next_.value[j].drift()[i] +
                 next_.value[j].diffusion()[i]);
         }
     }

     return next_;
}

[Quantlib-dev] Undefined symbol

[Andre L. <an...@de...>]

Hi,

BlackVolTermStructure (documented as an abstract class) defines 3 virtual 
functions, timeDerivative,strikeDerivative,strikeSecondDerivative. On the 
SWIG side it is used as a class, which results in undefined symbols when 
importing QuantLib in Python!?

Any fixes, suggestions?

Thanx Andre

[Quantlib-dev] [ quantlib-Bugs-887769 ] Wrong documentation for NewYork calendar

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

Bugs item #887769, was opened at 2004-01-30 13:35
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=887769&group_id=12740

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniele De Francesco (qq7te)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong documentation for NewYork calendar

Initial Comment:
I don't know how big of a deal it is, but I was quite
surprised to find out that although the documentation
states that Veteran's Day is considered a holiday in
the New York calendar, that is not true in the code. 



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

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

Re: [Quantlib-dev] binary barrier options replaced by digital options

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

Hi Dirk

>RQuantLib does. So I'd need to redo my code. Which should be doable. But as
>you asked what would break ...

ok: I will wait for you to confirm that you moved from binarybarrier to 
vanilla with binary payoff and America exercise before removing the 
binarybarrier code. If you have any problem just ask and I'll try to help you.

Usually I support the practice of deprecating code for the new release and 
removing the code in the next release, but this time I would prefer to 
remove the code in order not to have to back-port the fixes I did from 
American digital options to binary barrier options.

ciao -- Nando

Re: [Quantlib-dev] binary barrier options replaced by digital options

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

On Wed, Jan 21, 2004 at 12:59:02PM +0100, Ferdinando Ametrano wrote:
> As of now both the "binary barrier" and the "American digital" options are 
> available in the QuantLib CVS. I am going to deprecated few files (in 
> parenthesis the suggested alternative):
> 1) ql/MonteCarlo/binarybarrierpathpricer.*pp 
> (ql/MonteCarlo/digitalpathpricer.*pp)
> 2) ql/PricingEngines/Barrier/analyticamericanbinarybarrierengine.*pp 
> (ql/PricingEngines/Vanilla/analyticamericanengine.*pp)
> 3) ql/PricingEngines/Barrier/analyticeuropeanbinarybarrierengine.*pp 
> (ql/PricingEngines/Vanilla/analyticeuropeanengine.*pp)
> 4) ql/PricingEngines/Barrier/mcbinarybarrierengine.hpp 
> (ql/PricingEngines/Vanilla/mcdigitalengine.hpp)
> 5) ql/Instruments/binarybarrieroption.*pp (ql/Instruments/vanillaoption.*pp)
> 
> I'm considering removing the deprecated files before the next release, 
> unless anyone relies on them. I would do this for sake of clarity and 

RQuantLib does. So I'd need to redo my code. Which should be doable. But as
you asked what would break ...

Sounds like a cool change. Congrats!

Dirk

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

[Quantlib-dev] binary barrier options replaced by digital options

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

Hi Neil,

I've refactored the code you provided for binary barriers. The main reason 
was that I prefer to look at these options as American exercise option with 
binary payoff, instead of barrier options.

As a matter of fact if one looks at the paper I've attached here one can 
notice that options 1-8 do not depend on the strike, they only depend on 
the barrier level. Just rename the barrier level as strike and one has gone 
from "binary barrier" to "American binary" options.
Namely:
1) down-and-in  cash-at-hit-or-nothing is American 
put  with  cash-at-hit-or-nothing binary payoff
2)   up-and-in  cash-at-hit-or-nothing is American call 
with  cash-at-hit-or-nothing binary payoff
3) down-and-in asset-at-hit-or-nothing is American put  with 
asset-at-hit-or-nothing binary payoff
4)   up-and-in asset-at-hit-or-nothing is American call with 
asset-at-hit-or-nothing binary payoff

5) down-and-in  cash-at-expiry-or-nothing is American 
put  with  cash-at-expiry-or-nothing binary payoff
6)   up-and-in  cash-at-expiry-or-nothing is American call 
with  cash-at-expiry-or-nothing binary payoff
7) down-and-in asset-at-expiry-or-nothing is American put  with 
asset-at-expiry-or-nothing binary payoff
8)   up-and-in asset-at-expiry-or-nothing is American call with 
asset-at-expiry-or-nothing binary payoff

As of now both the "binary barrier" and the "American digital" options are 
available in the QuantLib CVS. I am going to deprecated few files (in 
parenthesis the suggested alternative):
1) ql/MonteCarlo/binarybarrierpathpricer.*pp 
(ql/MonteCarlo/digitalpathpricer.*pp)
2) ql/PricingEngines/Barrier/analyticamericanbinarybarrierengine.*pp 
(ql/PricingEngines/Vanilla/analyticamericanengine.*pp)
3) ql/PricingEngines/Barrier/analyticeuropeanbinarybarrierengine.*pp 
(ql/PricingEngines/Vanilla/analyticeuropeanengine.*pp)
4) ql/PricingEngines/Barrier/mcbinarybarrierengine.hpp 
(ql/PricingEngines/Vanilla/mcdigitalengine.hpp)
5) ql/Instruments/binarybarrieroption.*pp (ql/Instruments/vanillaoption.*pp)

I'm considering removing the deprecated files before the next release, 
unless anyone relies on them. I would do this for sake of clarity and 
because while moving from "binary barrier" to "American binary" I've also 
fixed few bugs and made little improvements which would require some time 
to be applied to binary barriers...

I'm posting this to QuantLib-users since if anyone on this list wants to 
take a look at the code and give some feedback it would be welcome. There 
is also so much work still to do about the greeks of American at-hit and 
American at-expiry, on the MC simulation of the american cash-at-hit and 
American asset binary options, etc.

BTW now American binary engines are available for whatever "vanilla" option 
we have in QuantLib.

ciao -- Nando

Re: [Quantlib-dev] New release

[Liguo S. <lig...@va...>]

Hi, Luigi,

Congratulations!!!!!!!!! The holidays is getting merrier!

My best wishes!


Liguo 



On Tue, 30 Dec 2003, Luigi Ballabio wrote:

> 
> (list administrators: my mistake. Delete the other copy.)
> 
> Hi all,
> 	second and long awaited in a successful series of releases from  
> Luigi and Viviana Ballabio, Matilde was born today at 13:34 CET  
> weighing 3.150 kg (the Americans can do the conversion themselves--and  
> besides, I'm going to need quite a few hours of sleep before I can do  
> the math reliably.)  Mother and child are both well.
> 
> Cheers,
> 	Luigi
> 
> P.S. Yes, I do know that Linus Torvalds made the same joke already. Go  
> ahead and sue me.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 

[Quantlib-dev] New release

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

(list administrators: my mistake. Delete the other copy.)

Hi all,
	second and long awaited in a successful series of releases from  
Luigi and Viviana Ballabio, Matilde was born today at 13:34 CET  
weighing 3.150 kg (the Americans can do the conversion themselves--and  
besides, I'm going to need quite a few hours of sleep before I can do  
the math reliably.)  Mother and child are both well.

Cheers,
	Luigi

P.S. Yes, I do know that Linus Torvalds made the same joke already. Go  
ahead and sue me.

Re: [Quantlib-dev] Error with old-style implied vol

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

>Sorry but I changed my code in November to use the new pricer framework.
>Right now RQuantLib uses a mixture of old and new pricers / interface;
>eventually I'll convert it all.


well... this is even better ;-)

ciao -- Nando 

[Quantlib-dev] Binary Options

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

Hi Neil

I've just committed slight changes to VanillaOption and BarrierOption in 
order to have them use the Payoff class instead of the (type, stike) couple.
I had some problem with BinaryOption, namely with the enumeration 
CashAtHit, CashAtExpiry.
I would appreciate your feedback about the following.

The classic european call option with binary payoff is H * 1(S-K), where K 
is the strike, H is a cash amount, and 1(x) is 1 if x>=0, 0 if x>0. This is 
a "cash" binary payoff.
The equivalent American option is the so-called One-Touch option: it has 
the same payoff, but it is paid as soon as S>=K.

There is also the option with asset binary payoff, where the payoff is S * 
1(S-K), with its european and american versions.

If I got your CashAtHit right, it is what I would call an american option 
with cash binary payoff.
As for CashAtExpiry, it seems to me like an european lookback option with 
cash binary payoff: at expiry you look back for the max value of the 
underlying during the life of the option and then calculate a cash binary 
payoff using the max value instead of the terminal underlying asset value

I would re-factor your code so that the enumeration CashAtHit, CashAtExpiry 
will disappear,  replaced by european and american options with cash/asset 
binary payoff.

I would then add (probably later) the lookback option, with plain payoff 
and binary payoff.


A related question I have is where to find documentation for the analytic 
American binary engine: any paper you would suggest?

thank you

------------
ciao -- Nando 

Re: [Quantlib-dev] Error with old-style implied vol

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

On Wed, Dec 17, 2003 at 04:16:05PM +0100, Ferdinando Ametrano wrote:
> 
> >> In the process of updating RQuantLib to 0.3.4, I found that my wrappers
> >> around European and American implied vol no longer work. [...]
> >> I include a simple stand-alone below.  It builds fine, compute the NPV 
> >of an
> >> option (just to show that it links right etc pp) but abort on implied 
> >vol.
> 
> Dirk,
> 
> sorry for being so late. In a private conversation Luigi suggested that the 
> problem might be with:
> 
> #define QL_MIN_VOLATILITY 0.0 in ql/argsandresults.hpp
> 
> Could you please change it to
> #define QL_MIN_VOLATILITY 0.000001 in ql/argsandresults.hpp
> and see if your problem disappear?

Sorry but I changed my code in November to use the new pricer framework.
Right now RQuantLib uses a mixture of old and new pricers / interface;
eventually I'll convert it all.

Dirk

-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

Re: [Quantlib-dev] Error with old-style implied vol

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

> > In the process of updating RQuantLib to 0.3.4, I found that my wrappers
> > around European and American implied vol no longer work. [...]
> > I include a simple stand-alone below.  It builds fine, compute the NPV 
> of an
> > option (just to show that it links right etc pp) but abort on implied vol.

Dirk,

sorry for being so late. In a private conversation Luigi suggested that the 
problem might be with:

#define QL_MIN_VOLATILITY 0.0 in ql/argsandresults.hpp

Could you please change it to
#define QL_MIN_VOLATILITY 0.000001 in ql/argsandresults.hpp
and see if your problem disappear?

If this fails I'll investigate further the example you provided.

Thank you

ciao -- Nando 

Re: [Quantlib-dev] Error with old-style implied vol

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

On Thu, Nov 27, 2003 at 04:35:29PM -0600, Dirk Eddelbuettel wrote:
> Given the deafening silence :) as well as some curiousity on my part as to
> whether I'd manage to understand the fancy-pants new-style C++, I turned the
> above example into a small-ish standalone -- see below.

I should hasten to add that my code is a cut-down version of the
test-suite/europeanoption.cpp example. The test-suite/ dir is awesome. Who
needs documentationa anyway :)

Dirk

-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx