quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Greeks for vanilla binomial - implementation

[steve.affine <st...@af...>]

Concerning the FR to add Greeks
(http://sourceforge.net/tracker/index.php?func=detail&aid=910972&group_id=12740&atid=362740),
I have looked at this today and implemented most of them.

My suggestion is to use points on the binomial tree as per Odergaard
(http://finance-old.bi.no/~bernt/gcc_prog/recipes/recipes.pdf).

This gives delta, gamma & theta in quick and straightforward way without the
need for recomputation. The code in binomialengine.hpp is basically:

        DiscretizedVanillaOption option(arguments_);

		//Go to maturity
        option.initialize(lattice, maturity);

		//Partial derivatives calculated from various points in the binomial tree
(Odegaard)

		//Rollback to third-last step, and get underlying price (s) & option value
(p) at this point
		option.rollback(grid[2]);
		Array va2(option.values());
		QL_ASSERT(va2.size() == 3, "Expect 3 nodes in grid at second step");
		Real p2h = va2[2]; // high-price
		Real p2m = va2[1]; // mid-price
		Real s2 = bslattice->underlying(2, 2); //high price

		//Rollback to second-last step, and get underlying price (s) & option
value (p) at this point
		option.rollback(grid[1]);
		Array va(option.values());
		QL_ASSERT(va.size() == 2, "Expect 2 nodes in grid at first step");
		Real p1 = va[1];

		//Rollback to t=0
        option.rollback(0.0);
		Real p0 = option.presentValue();
		Real s1 = bslattice->underlying(1, 1);

		//Calc partials
		Real delta0 = (p1-p0)/(s1-s0);	//dp/ds
		Real delta1 = (p2h-p1)/(s2-s1);	//dp/ds

		//Return results
		results_.value = p0;
		results_.delta = delta0;
		results_.gamma = 2.0*(delta1-delta0)/(s2-s0);			//d(delta)/ds
		results_.theta = (p2m-p0)/(grid[2]);					//dp/dT

Any comments on this? Does anyone disagree, or think there is a better
method or better place to put this code?

cheers
Steve

affine group limited
http://www.affine.hk 
-- 
View this message in context: http://www.nabble.com/Greeks-for-vanilla-binomial---implementation-tf3504086.html#a9786157
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] Hi

[Karthik K. <ak...@gm...>]

Hi -
  I joined the list recently . I had been using the QuantLib recently and am
interested in contributing to the R-QuantLib port mentioned in the pages. I
was just curious about where I could start . Any pointers to the same is
welcome.

-- 
  Karthik.

Re: [Quantlib-dev] Migration to Subversion - heads up

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

On Mar 30, 2007, at 4:13 PM, Luigi Ballabio wrote:
> 	follow-up: migration is in progress. The Subversion repository will be
> ready by Monday morning (along with instructions.)

The migration is complete. Before jumping in, please read 
<http://quantlib.org/svn.shtml> for information on how to use the 
repository, especially the "Using Subversion" section.

Thanks,
	Luigi

[Quantlib-dev] portfolio optimization example

[Apollo W. <aw...@gw...>]

Is there any Portolio Optimization example using QuantLib? It is interest=
ing that there are nothing about Portfolio class defined in QuantLib. Tho=
ugh in the the framework setup, it is possible to form a Portfolio class =
with the templates. It would be much helpful if it is already implemented=
=2E Thanks.
Apollo.
*************************************************************************=
*********************
This email is being sent to you for your information pursuant to your req=
uest. This information is not warranted=20
as to completeness or accuracy. The views expressed in the message are th=
ose of the individual sender,=20
except where the message states otherwise and the sender is authorized to=
 state them to be the views of=20
George Weiss Associates, Inc. or any of its affiliated entities. This mes=
sage is for the named person's use=20
only. It may contain sensitive and private proprietary or legally privile=
ged information. No confidentiality or=20
privilege is waived or lost by any mistransmission. You must not, directl=
y or indirectly, use, disclose, distribute,=20
print or copy any part of this message if you are not the intended recipi=
ent.
*** eSafe scanned this email for viruses, vandals, and malicious content.=
 ***
*************************************************************************=
*********************

Re: [Quantlib-dev] Migration to Subversion - heads up

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

On Thu, 2007-03-29 at 17:11 +0200, Luigi Ballabio wrote:
> 	we'll be migrating to Subversion during the weekend.

Hi all,
	follow-up: migration is in progress. The Subversion repository will be
ready by Monday morning (along with instructions.)

Later,
	Luigi


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

An ideal world is left as an exercise to the reader. 
-- Paul Graham 

Re: [Quantlib-dev] Compling log4cxx on cygwin

[eric e. <eri...@gm...>]

Hi Marco,

On 3/29/07, Marco Marchioro <Mar...@st...> wrote:
> Hi all,
> I am trying to compile QuantLibAddin with cygwin on windows XP.
> During the process I found that a standard patch (inculded) should
> be applied.
>
> Should I commit the patched file include/log4cxx/helpers/tchar.h
> or should we add the patch with a name like cygwin-diffs-log4cxx.diff
> to the repository?

I would prefer the former - once it's in I'll confirm it works for VC
and linux.  Many thanks for picking this up.

Regards,
Eric

Re: [Quantlib-dev] Plans for future releases and call for contributions

[steve.affine <st...@af...>]

Luigi Ballabio wrote:
> 
> This year, we're planning to finally take the next step and release
> QuantLib 1.0.  I'll draft a plan and ask for specific contributions
> later in this post; but before that, please let me share a few thoughts.
> 

I think this is great news, and look forward to the official release. 

I'm spending a bit of time with QuantLib for some securities consulting work
at Affine, and one general comment about QuantLib is that IMHO it's fairly
complex to use if you just want to do some simple option pricing. 
a) I think it would be great if we can produce some high-level
documentation/tutorials on how the class library is designed, what are the
fundamental classes (Instrument, PricingEngine etc) and how these hang
together. 
b) I think it would also be valuable if we can write some simple facade
classes (or example code) for e.g. vanilla B&S/Binomial where you can just
pass in a simple instrument definition (strike, put/call, expiry etc.),
pricing parameters (underlying, vol, rate) and get the NPV and greeks (maybe
based on the EquityOption.cpp example).

I would imagine that (a) would need to be done by one of the core
developers, but I'd be happy to contribute on (b) if it's something we feel
would be useful.

cheers
Steve

affine group limited
http://www.affine.hk

-- 
View this message in context: http://www.nabble.com/Plans-for-future-releases-and-call-for-contributions-tf3414788.html#a9748449
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] Compling log4cxx on cygwin

[Marco M. <Mar...@st...>]

Hi all,
I am trying to compile QuantLibAddin with cygwin on windows XP.
During the process I found that a standard patch (inculded) should
be applied.

Should I commit the patched file include/log4cxx/helpers/tchar.h
or should we add the patch with a name like cygwin-diffs-log4cxx.diff
to the repository?

Marco Marchioro

Re: [Quantlib-dev] Gauss Kronrod Implementation

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

On Mon, 2007-03-26 at 17:44 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> As you may have noticed I have coded a new implementation of Gauss
> Kronrod integration algorithm (the true one actually). It is coded in
> a slightly different way than other existing integration methods.
> First, I use boost::function to define the integrand, second, it is
> coded as a free (non member) function.
> 
> I use boost::function to avoid templatization. This allow me to store
> the function definition in a cpp file and to provide the same
> flexibility in the integrand definition as with other methods. Do you
> agree with this approach ? or do you prefer the current
> implementation ? ( if you agree I can refactor the existing code
> quickly). 

It's ok. As a matter of fact, we could modify the older integration
functions (the other Gauss-Kronrod, trapezoid, there might be others
which escape me now) so that they use boost::function. I'm not sure that
it's worth defining a typedef Integrand, though. For one thing, it's a
bit too generic. Leaving the raw boost::function type might be clearer.


> As for the second point, I have use a free function because I had no
> better idea. In fact I have the impression that current integration
> framework lacks a bit of consistency. I am tempted to provide an
> abstract base class and make all other inherit from it. Any
> thoughts ? 

Having classes instead of free functions helps generic programming since
it gives all integral classes the same interface, namely,
Real operator()(boost::function<...> F, Real a, Real b) const;
whereas free functions have to be invoked with different numbers of
parameters. If your function were rewritten as a function object, you
would pass epsAbs and epsRel to its constructor, after which it would
have the same interface as the others (and therefore, could replace them
without modifying client code.)

I don't think you'll need an abstract base class. As the common
interface is operator(), client code needing an integrator can be
written as a template taking a generic F or as a non-template taking a
boost::function (although with a rather scary signature.)

Later,
	Luigi

P.S. It should be gaussKronrodNonAdaptive (not "Adaptative")



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

Testing can never demonstrate the absence of errors in software, only 
their presence. 
-- W.E. Dijkstra 

[Quantlib-dev] Migration to Subversion - heads up

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

Hi all,
	we'll be migrating to Subversion during the weekend. If you have code
to commit into the CVS repository (hopefully code that leaves the
library in a compilable state) please do it before tomorrow, March 30th
at 12:00 PM Italian time (11:00 AM London time.) At that time, I'll be
disabling CVS access and start the migration. I'll keep you informed on
the progress.

Later,
	Luigi


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

A debugged program is one for which you have not yet found the 
conditions that make it fail. 
-- Jerry Ogdin 

[Quantlib-dev] [ quantlib-Bugs-1687805 ] CapsStripperTest fails on non-working days

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

Bugs item #1687805, was opened at 2007-03-25 14:56
Message generated for change (Settings changed) made by ericehlers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1687805&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: goncha (victor_gonzalez)
>Assigned to: Francois du Vignaud (fdv1)
Summary: CapsStripperTest fails on non-working days

Initial Comment:
Can anyone help to identify this error when building the testsuite project and let me know whether is a known bug and how can be fixed?

I have sucessfully installed QuantLib, and then decided to installed the XLAddIn, which compiles perfectly too but then when asked by the tutorial reference on the web to build the testsuite in order to check the QuantLib project, the compiler throw the error below which relates to cap volatilities.

I built 
I look forward to hearing from you

Thank you

Victor


Testing flat-volatility stripping...
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 3%
volatility=: 0.179926
relativeError=: -0.0412448
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 4%
volatility=: 0.179893
relativeError=: -0.0595946
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 5%
volatility=: 0.17991
relativeError=: -0.0502123
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 6%
volatility=: 0.179941
relativeError=: -0.0327453
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 7%
volatility=: 0.179967
relativeError=: -0.0184223
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 4%
volatility=: 0.180023
relativeError=: 0.0127118
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 5%
volatility=: 0.180021
relativeError=: 0.0114133

On completion:
Tests completed in 17 m 31 s
Test suite "QuantLib test suite" failed with:
  279 assertions out of 287 passed
  8 assertions out of 287 failed
  277 test cases out of 279 passed
  2 test cases out of 279 failed


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

Comment By: Francois du Vignaud (fdv1)
Date: 2007-03-29 09:23

Message:
Logged In: YES 
user_id=1606867
Originator: NO

This test is failing because the CapStripper (being a TermStructure) uses
an adjusted reference date whereas caps don't.
rgds,
François


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

Comment By: Eric Ehlers (ericehlers)
Date: 2007-03-27 23:43

Message:
Logged In: YES 
user_id=1143221
Originator: NO

Hi Victor,

I just ran the testsuite and it passed OK.  Then I set the clock back to
25 March 2007 - the date of your bug report, and a Sunday - and I got the
exact same failure as you.  So it looks like there's a flaw in the logic of
the CapsStripper test which causes it to fail if run on 25 March 2007 - I
imagine it also fails on any other non-working day.  I'll try to arrange
for this to be fixed in the next release.

In the meantime the temporary workaround is for you to stop working on
weekends.  :-)

Regards,
Eric

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

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

[Quantlib-dev] [ quantlib-Bugs-1687805 ] CapsStripperTest fails on non-working days

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

Bugs item #1687805, was opened at 2007-03-25 12:56
Message generated for change (Comment added) made by fdv1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1687805&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: goncha (victor_gonzalez)
Assigned to: Eric Ehlers (ericehlers)
Summary: CapsStripperTest fails on non-working days

Initial Comment:
Can anyone help to identify this error when building the testsuite project and let me know whether is a known bug and how can be fixed?

I have sucessfully installed QuantLib, and then decided to installed the XLAddIn, which compiles perfectly too but then when asked by the tutorial reference on the web to build the testsuite in order to check the QuantLib project, the compiler throw the error below which relates to cap volatilities.

I built 
I look forward to hearing from you

Thank you

Victor


Testing flat-volatility stripping...
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 3%
volatility=: 0.179926
relativeError=: -0.0412448
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 4%
volatility=: 0.179893
relativeError=: -0.0595946
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 5%
volatility=: 0.17991
relativeError=: -0.0502123
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 6%
volatility=: 0.179941
relativeError=: -0.0327453
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 7%
volatility=: 0.179967
relativeError=: -0.0184223
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 4%
volatility=: 0.180023
relativeError=: 0.0127118
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 5%
volatility=: 0.180021
relativeError=: 0.0114133

On completion:
Tests completed in 17 m 31 s
Test suite "QuantLib test suite" failed with:
  279 assertions out of 287 passed
  8 assertions out of 287 failed
  277 test cases out of 279 passed
  2 test cases out of 279 failed


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

Comment By: Francois du Vignaud (fdv1)
Date: 2007-03-29 07:23

Message:
Logged In: YES 
user_id=1606867
Originator: NO

This test is failing because the CapStripper (being a TermStructure) uses
an adjusted reference date whereas caps don't.
rgds,
François


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

Comment By: Eric Ehlers (ericehlers)
Date: 2007-03-27 21:43

Message:
Logged In: YES 
user_id=1143221
Originator: NO

Hi Victor,

I just ran the testsuite and it passed OK.  Then I set the clock back to
25 March 2007 - the date of your bug report, and a Sunday - and I got the
exact same failure as you.  So it looks like there's a flaw in the logic of
the CapsStripper test which causes it to fail if run on 25 March 2007 - I
imagine it also fails on any other non-working day.  I'll try to arrange
for this to be fixed in the next release.

In the meantime the temporary workaround is for you to stop working on
weekends.  :-)

Regards,
Eric

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

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

Re: [Quantlib-dev] Boostrapping TS in QuantLibXL

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

On Wed, 2007-03-28 at 22:34 +0200, eric ehlers wrote:
> > > That's basically it.  Existing QuantLibXL books work as follows:
> > >
> > > 1. create a dummy term structure (say TS1) ;
> > > 2. create my Euribor object based on TS1 ;
> > > 3. create swap rate helpers based on my Euribor object ;
> > > 4. create a term structure (say TS2) ;
> > > 5. call qlExtrapolatorEnableExtrapolation() on TS2
> > > 6. bootstrap TS2 based on the rate helpers
> > > 7. call qlSetEuriborTermStructure to relink all enumerated Euribor
> > > objects to TS2 ;
> > > 8. we're now ready to price some securities.
> >
> > Is 5 necessary? During bootstrapping, the curve is extended at each new
> > node so that it covers all times needed by the corresponding helper.
> 
> There is one example workbook which sets up a swaption, and in that
> case if you neglect to call qlExtrapolatorEnableExtrapolation() then
> when you ask for the NPV of the swaption it fails with "time (xxx) is
> past max curve time (yyy)". 

I see. You don't need it during bootstrapping then---which was rather
puzzling me---but afterwards, when you try and price a security whose
relevant dates extend past the end of the curve.
In this case 5 is necessary, but it can be done after 7.

Luigi


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

Barker's Proof: 
Proofreading is more effective after publication. 

Re: [Quantlib-dev] Boostrapping TS in QuantLibXL

[eric e. <eri...@gm...>]

Hi Luigi,

On 3/28/07, Luigi Ballabio <lui...@gm...> wrote:
>
> On Mar 28, 2007, at 9:36 PM, eric ehlers wrote:
> > That's basically it.  Existing QuantLibXL books work as follows:
> >
> > 1. create a dummy term structure (say TS1) ;
> > 2. create my Euribor object based on TS1 ;
> > 3. create swap rate helpers based on my Euribor object ;
> > 4. create a term structure (say TS2) ;
> > 5. call qlExtrapolatorEnableExtrapolation() on TS2
> > 6. bootstrap TS2 based on the rate helpers
> > 7. call qlSetEuriborTermStructure to relink all enumerated Euribor
> > objects to TS2 ;
> > 8. we're now ready to price some securities.
>
> Is 5 necessary? During bootstrapping, the curve is extended at each new
> node so that it covers all times needed by the corresponding helper.

There is one example workbook which sets up a swaption, and in that
case if you neglect to call qlExtrapolatorEnableExtrapolation() then
when you ask for the NPV of the swaption it fails with "time (xxx) is
past max curve time (yyy)".  Calling
qlExtrapolatorEnableExtrapolation() fixes the problem so one way or
another that call makes a relevant change to the state of the term
structure, though I don't understand the details.

Regards,
Eric

Re: [Quantlib-dev] Boostrapping TS in QuantLibXL

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

On Mar 28, 2007, at 9:36 PM, eric ehlers wrote:
> That's basically it.  Existing QuantLibXL books work as follows:
>
> 1. create a dummy term structure (say TS1) ;
> 2. create my Euribor object based on TS1 ;
> 3. create swap rate helpers based on my Euribor object ;
> 4. create a term structure (say TS2) ;
> 5. call qlExtrapolatorEnableExtrapolation() on TS2
> 6. bootstrap TS2 based on the rate helpers
> 7. call qlSetEuriborTermStructure to relink all enumerated Euribor
> objects to TS2 ;
> 8. we're now ready to price some securities.

Is 5 necessary? During bootstrapping, the curve is extended at each new 
node so that it covers all times needed by the corresponding helper.

Luigi

Re: [Quantlib-dev] Boostrapping TS in QuantLibXL

[eric e. <eri...@gm...>]

Hi Aurelien,

On 3/28/07, Aurelien Chanudet <aur...@gm...> wrote:
> Hi Eric, hi all,
>
> What's the smartest way to do the following in QuantLibXL 0.4.0 :
> - boostrap a term structure...
> - based on swap instruments...
> - whose floating legs rely on a shared Euribor object...
> - whose associated (forecasting) term structure is the term structure
> I want to bootstrap ?
>
> It used to be fairly straightforward in 0.3.12 but it appears to be
> more complicated in 0.4.0. The only and somewhat circumvented way I
> was able to do that is :
> 1. create a dummy term structure (say TS1) ;
> 2. create my Euribor object based on TS1 ;
> 3. create swap rate helpers based on my Euribor object ;
> 4. create a term structure (say TS2) ;
> 5. call qlSetEuriborTermStructure to link my Euribor object to TS2 ;
> 6. we're now ready to boostrap TS2 and price some securities.

That's basically it.  Existing QuantLibXL books work as follows:

1. create a dummy term structure (say TS1) ;
2. create my Euribor object based on TS1 ;
3. create swap rate helpers based on my Euribor object ;
4. create a term structure (say TS2) ;
5. call qlExtrapolatorEnableExtrapolation() on TS2
6. bootstrap TS2 based on the rate helpers
7. call qlSetEuriborTermStructure to relink all enumerated Euribor
objects to TS2 ;
8. we're now ready to price some securities.

For an example please see Workbooks\OriginalExamples\MarketData.xls

Regards,
Eric

[Quantlib-dev] Boostrapping TS in QuantLibXL

[Aurelien C. <aur...@gm...>]

Hi Eric, hi all,

What's the smartest way to do the following in QuantLibXL 0.4.0 :
- boostrap a term structure...
- based on swap instruments...
- whose floating legs rely on a shared Euribor object...
- whose associated (forecasting) term structure is the term structure
I want to bootstrap ?

It used to be fairly straightforward in 0.3.12 but it appears to be
more complicated in 0.4.0. The only and somewhat circumvented way I
was able to do that is :
1. create a dummy term structure (say TS1) ;
2. create my Euribor object based on TS1 ;
3. create swap rate helpers based on my Euribor object ;
4. create a term structure (say TS2) ;
5. call qlSetEuriborTermStructure to link my Euribor object to TS2 ;
6. we're now ready to boostrap TS2 and price some securities.

Thanks in advance.

Aurelien

[Quantlib-dev] Request for volunteers: known bugs

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

Hi all,
	the QuantLib reference manual contains a list of allegedly known bugs
(see <http://quantlib.org/reference/bug.html>.)  Your mission, should
you accept it, is to verify the bugs (details later) and add them to the
bug tracker so that hopefully they can be fixed for release 1.0.

Anybody wanting to contribute can reply to the mailing list.  Offering
to provide a patch are welcome, but not necessary---my aim at this time
is just to have them filed in the tracker. Karma points will go to those
that file the bugs using their Sourceforge username instead of doing
that anonymously.

As for the bugs:

- some of them were reproduced, e.g., the CompoundForward one; the
corresponding test-suite would fail if run with QL_USE_INDEXED_COUPON
defined (the test cases are currently disabled in that case.) In this
case, the only step needed is to file the bug with a reference to the
test cases.

- some of them generically state that "the results are not reliable".
Each such class should be stress-tested with different input values and
the results should be checked (Greeks can be tested numerically; values
can be tested against known good values.) For each class, a bug should
be failed in the tracker including the input values that yield bad
results (or better yet, the code triggering them.)

- some of them generically state that "the class was not tested enough"
or some such wording. For each such class, please reply to the list if
you used it and found that it gives decent results.

- a couple of them state that the code does not compile with Borland. As
we dropped support for that compiler, those can be neglected.

- the remaining bugs pinpoint a particular failure. Each should be
reproduced and filed in the bug tracker together with the code
triggering the error.

Thanks in advance,
	Luigi


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

The first thing we do, let's kill all the lawyers. 
-- W. Shakespeare, "King Henry VI, Part II" 

[Quantlib-dev] [ quantlib-Bugs-1687805 ] CapsStripperTest fails on non-working days

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

Bugs item #1687805, was opened at 2007-03-25 14:56
Message generated for change (Settings changed) made by ericehlers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1687805&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: goncha (victor_gonzalez)
Assigned to: Eric Ehlers (ericehlers)
>Summary: CapsStripperTest fails on non-working days

Initial Comment:
Can anyone help to identify this error when building the testsuite project and let me know whether is a known bug and how can be fixed?

I have sucessfully installed QuantLib, and then decided to installed the XLAddIn, which compiles perfectly too but then when asked by the tutorial reference on the web to build the testsuite in order to check the QuantLib project, the compiler throw the error below which relates to cap volatilities.

I built 
I look forward to hearing from you

Thank you

Victor


Testing flat-volatility stripping...
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 3%
volatility=: 0.179926
relativeError=: -0.0412448
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 4%
volatility=: 0.179893
relativeError=: -0.0595946
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 5%
volatility=: 0.17991
relativeError=: -0.0502123
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 6%
volatility=: 0.179941
relativeError=: -0.0327453
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 7%
volatility=: 0.179967
relativeError=: -0.0184223
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 4%
volatility=: 0.180023
relativeError=: 0.0127118
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 5%
volatility=: 0.180021
relativeError=: 0.0114133

On completion:
Tests completed in 17 m 31 s
Test suite "QuantLib test suite" failed with:
  279 assertions out of 287 passed
  8 assertions out of 287 failed
  277 test cases out of 279 passed
  2 test cases out of 279 failed


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

Comment By: Eric Ehlers (ericehlers)
Date: 2007-03-27 23:43

Message:
Logged In: YES 
user_id=1143221
Originator: NO

Hi Victor,

I just ran the testsuite and it passed OK.  Then I set the clock back to
25 March 2007 - the date of your bug report, and a Sunday - and I got the
exact same failure as you.  So it looks like there's a flaw in the logic of
the CapsStripper test which causes it to fail if run on 25 March 2007 - I
imagine it also fails on any other non-working day.  I'll try to arrange
for this to be fixed in the next release.

In the meantime the temporary workaround is for you to stop working on
weekends.  :-)

Regards,
Eric

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

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

[Quantlib-dev] [ quantlib-Bugs-1687805 ] Error on the TestSuite project within the QuantLibAll_vc8

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

Bugs item #1687805, was opened at 2007-03-25 14:56
Message generated for change (Settings changed) made by ericehlers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1687805&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: goncha (victor_gonzalez)
>Assigned to: Eric Ehlers (ericehlers)
Summary: Error on the TestSuite project within the QuantLibAll_vc8

Initial Comment:
Can anyone help to identify this error when building the testsuite project and let me know whether is a known bug and how can be fixed?

I have sucessfully installed QuantLib, and then decided to installed the XLAddIn, which compiles perfectly too but then when asked by the tutorial reference on the web to build the testsuite in order to check the QuantLib project, the compiler throw the error below which relates to cap volatilities.

I built 
I look forward to hearing from you

Thank you

Victor


Testing flat-volatility stripping...
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 3%
volatility=: 0.179926
relativeError=: -0.0412448
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 4%
volatility=: 0.179893
relativeError=: -0.0595946
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 5%
volatility=: 0.17991
relativeError=: -0.0502123
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 6%
volatility=: 0.179941
relativeError=: -0.0327453
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 7%
volatility=: 0.179967
relativeError=: -0.0184223
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 4%
volatility=: 0.180023
relativeError=: 0.0127118
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 5%
volatility=: 0.180021
relativeError=: 0.0114133

On completion:
Tests completed in 17 m 31 s
Test suite "QuantLib test suite" failed with:
  279 assertions out of 287 passed
  8 assertions out of 287 failed
  277 test cases out of 279 passed
  2 test cases out of 279 failed


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

Comment By: Eric Ehlers (ericehlers)
Date: 2007-03-27 23:43

Message:
Logged In: YES 
user_id=1143221
Originator: NO

Hi Victor,

I just ran the testsuite and it passed OK.  Then I set the clock back to
25 March 2007 - the date of your bug report, and a Sunday - and I got the
exact same failure as you.  So it looks like there's a flaw in the logic of
the CapsStripper test which causes it to fail if run on 25 March 2007 - I
imagine it also fails on any other non-working day.  I'll try to arrange
for this to be fixed in the next release.

In the meantime the temporary workaround is for you to stop working on
weekends.  :-)

Regards,
Eric

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

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

[Quantlib-dev] [ quantlib-Bugs-1687805 ] Error on the TestSuite project within the QuantLibAll_vc8

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

Bugs item #1687805, was opened at 2007-03-25 14:56
Message generated for change (Comment added) made by ericehlers
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1687805&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: goncha (victor_gonzalez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error on the TestSuite project within the QuantLibAll_vc8

Initial Comment:
Can anyone help to identify this error when building the testsuite project and let me know whether is a known bug and how can be fixed?

I have sucessfully installed QuantLib, and then decided to installed the XLAddIn, which compiles perfectly too but then when asked by the tutorial reference on the web to build the testsuite in order to check the QuantLib project, the compiler throw the error below which relates to cap volatilities.

I built 
I look forward to hearing from you

Thank you

Victor


Testing flat-volatility stripping...
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 3%
volatility=: 0.179926
relativeError=: -0.0412448
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 4%
volatility=: 0.179893
relativeError=: -0.0595946
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 5%
volatility=: 0.17991
relativeError=: -0.0502123
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 6%
volatility=: 0.179941
relativeError=: -0.0327453
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 7%
volatility=: 0.179967
relativeError=: -0.0184223
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 4%
volatility=: 0.180023
relativeError=: 0.0127118
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 5%
volatility=: 0.180021
relativeError=: 0.0114133

On completion:
Tests completed in 17 m 31 s
Test suite "QuantLib test suite" failed with:
  279 assertions out of 287 passed
  8 assertions out of 287 failed
  277 test cases out of 279 passed
  2 test cases out of 279 failed


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

>Comment By: Eric Ehlers (ericehlers)
Date: 2007-03-27 23:43

Message:
Logged In: YES 
user_id=1143221
Originator: NO

Hi Victor,

I just ran the testsuite and it passed OK.  Then I set the clock back to
25 March 2007 - the date of your bug report, and a Sunday - and I got the
exact same failure as you.  So it looks like there's a flaw in the logic of
the CapsStripper test which causes it to fail if run on 25 March 2007 - I
imagine it also fails on any other non-working day.  I'll try to arrange
for this to be fixed in the next release.

In the meantime the temporary workaround is for you to stop working on
weekends.  :-)

Regards,
Eric

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

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

Re: [Quantlib-dev] Gauss Kronrod Implementation

[DU V. DE V. F. G. P. <fra...@ca...>]

=20

Hi Niels,

=20

The version I have implemented uses an increasing number of evaluation =
of the integrand until it reaches the required precision. The key point =
is that it reuses all the values computed (with different weights each =
time). It uses up to 87 points; meaning that it is less robust than your =
adaptative algorithm which can use as many points as required. In =
particular, the integrand should be smooth enough otherwise we have to =
make a change of variable.

Good to see that you keep an eye on what's going on ...

Best regards,

Fran=E7ois=20

=20

=20

-----Original Message-----
From: qua...@li... =
[mailto:qua...@li...] On Behalf Of Niels =
Elken S=F8nderby
Sent: luned=EC 26 marzo 2007 20.23
To: qua...@li...
Subject: Re: [Quantlib-dev] Gauss Kronrod Implementation

=20

Hi Fran=E7ois

I was the one who added the Gauss-Kronrod algorithm to QuantLib years =
ago. But I'm not actively developing on QuantLib now, so I will leave it =
up to the active developers to decide which coding style is better.=20

Was is the advantage of the new algorithm? Is it faster? More precise?

Good to see contributions coming in!

Best regards,
Niels



2007/3/26, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI < =
fra...@ca...>:

Hi all,

=20

Sorry to annoy you again with a some new questions, I hope to make =
myself clear enough this time ;-)=20

As you may have noticed I have coded a new implementation of Gauss =
Kronrod integration algorithm (the true one actually). It is coded in a =
slightly different way than other existing integration methods. First, I =
use boost::function to define the integrand, second, it is coded as a =
free (non member) function.=20

I use boost::function to avoid templatization. This allow me to store =
the function definition in a cpp file and to provide the same =
flexibility in the integrand definition as with other methods. Do you =
agree with this approach ? or do you prefer the current implementation ? =
( if you agree I can refactor the existing code quickly).=20

As for the second point, I have use a free function because I had no =
better idea. In fact I have the impression that current integration =
framework lacks a bit of consistency. I am tempted to provide an =
abstract base class and make all other inherit from it. Any thoughts ?=20

=20

Fran=E7ois

=20

PS: What about using a forum dedicated to this kind of discussions ?=20

=20

=20


-------------------------------------------------------------------------=

Take Surveys. Earn Cash. Influence the Future of IT=20
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev=20

=20

Re: [Quantlib-dev] Gauss Kronrod Implementation

[<ni...@bi...>]

Hi Fran=E7ois

I was the one who added the Gauss-Kronrod algorithm to QuantLib years ago.
But I'm not actively developing on QuantLib now, so I will leave it up to
the active developers to decide which coding style is better.

Was is the advantage of the new algorithm? Is it faster? More precise?

Good to see contributions coming in!

Best regards,
Niels


2007/3/26, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI <
fra...@ca...>:
>
> Hi all,
>
>
>
> Sorry to annoy you again with a some new questions, I hope to make myself
> clear enough this time ;-)
>
> As you may have noticed I have coded a new implementation of Gauss Kronro=
d
> integration algorithm (the true one actually). It is coded in a slightly
> different way than other existing integration methods. First, I use
> boost::function to define the integrand, second, it is coded as a free (n=
on
> member) function.
>
> I use boost::function to avoid templatization. This allow me to store the
> function definition in a cpp file and to provide the same flexibility in =
the
> integrand definition as with other methods. Do you agree with this approa=
ch
> ? or do you prefer the current implementation ? ( if you agree I can
> refactor the existing code quickly).
>
> As for the second point, I have use a free function because I had no
> better idea. In fact I have the impression that current integration
> framework lacks a bit of consistency. I am tempted to provide an abstract
> base class and make all other inherit from it. Any thoughts ?
>
>
>
> Fran=E7ois
>
>
>
> PS: What about using a forum dedicated to this kind of discussions ?
>
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

[Quantlib-dev] Gauss Kronrod Implementation

[DU V. DE V. F. G. P. <fra...@ca...>]

Hi all,

=20

Sorry to annoy you again with a some new questions, I hope to make =
myself clear enough this time ;-)

As you may have noticed I have coded a new implementation of Gauss =
Kronrod integration algorithm (the true one actually). It is coded in a =
slightly different way than other existing integration methods. First, I =
use boost::function to define the integrand, second, it is coded as a =
free (non member) function.

I use boost::function to avoid templatization. This allow me to store =
the function definition in a cpp file and to provide the same =
flexibility in the integrand definition as with other methods. Do you =
agree with this approach ? or do you prefer the current implementation ? =
( if you agree I can refactor the existing code quickly).=20

As for the second point, I have use a free function because I had no =
better idea. In fact I have the impression that current integration =
framework lacks a bit of consistency. I am tempted to provide an =
abstract base class and make all other inherit from it. Any thoughts ?=20

=20

Fran=E7ois

=20

PS: What about using a forum dedicated to this kind of discussions ?=20

=20

=20

[Quantlib-dev] [ quantlib-Bugs-1687805 ] Error on the TestSuite project within the QuantLibAll_vc8

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

Bugs item #1687805, was opened at 2007-03-25 12:56
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=1687805&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: goncha (victor_gonzalez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error on the TestSuite project within the QuantLibAll_vc8

Initial Comment:
Can anyone help to identify this error when building the testsuite project and let me know whether is a known bug and how can be fixed?

I have sucessfully installed QuantLib, and then decided to installed the XLAddIn, which compiles perfectly too but then when asked by the tutorial reference on the web to build the testsuite in order to check the QuantLib project, the compiler throw the error below which relates to cap volatilities.

I built 
I look forward to hearing from you

Thank you

Victor


Testing flat-volatility stripping...
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 3%
volatility=: 0.179926
relativeError=: -0.0412448
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 4%
volatility=: 0.179893
relativeError=: -0.0595946
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 5%
volatility=: 0.17991
relativeError=: -0.0502123
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 6%
volatility=: 0.179941
relativeError=: -0.0327453
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 2Y
strike: 7%
volatility=: 0.179967
relativeError=: -0.0184223
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 4%
volatility=: 0.180023
relativeError=: 0.0127118
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping": tenor: 3Y
strike: 5%
volatility=: 0.180021
relativeError=: 0.0114133

On completion:
Tests completed in 17 m 31 s
Test suite "QuantLib test suite" failed with:
  279 assertions out of 287 passed
  8 assertions out of 287 failed
  277 test cases out of 279 passed
  2 test cases out of 279 failed


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

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