quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Pointer Casting

[animesh s. <ani...@gm...>]

  You are right, It compiled once and now it just gave out BAD_ACCESS 
error.
Here's what I am trying to do just to get the simulation work. I added 
the mchimalayanengine.hpp file to my project and changed it, and in my 
main code I change the header file path to #include 
"mchimalayanengine.hpp" (My new file).

In this I just changed....the class

         boost::shared_ptr<Merton76Process> process = 
boost::dynamic_pointer_cast<Merton76Process>(processes_->process(0));
    //     QL_REQUIRE(process, "Black-Scholes process required");

         return boost::shared_ptr<typename 
MCHimalayaEngine<RNG,S>::path_pricer_type>(new 
HimalayaMultiPathPricer(arguments_.payoff,process->riskFreeRate()->discount(arguments_.exercise->lastDate())));

Now if I debug the code executes till after this line even with a 
dynamic cast. I checked that merton76Process has a riskFreeRate method. 
Now after all this it gives out a SIGABRT error. Still trying to 
understand why it is so!


On 8/31/10 7:26 PM, Luigi Ballabio wrote:
> On Tue, 2010-08-31 at 17:47 +0530, animesh saxena wrote:
>> I located the error in the code. I think this is probably due to
>> design.
>> Generally people would like to price options using different
>> processes. For example Himalayan Option is priced using BlackScholes
>> process in the example. When I change it to another process like
>> Merton76Process (which also is Stochastic1D - as per the guidelines),
>> I should be able to price it.
> Yes, in principle. But while the path generation does work with a
> generic process, the McHimalaya path pricer calls a method from the
> BlackScholes interface, namely, riskFreeRate().  The method is not in
> the Stochastic1D interface, so we need to cast.
>
>> The cast is throwing the error.
> It should.
>
>>   If I change it to "STATIC CAST", the error is gone!
>>          boost::shared_ptr<GeneralizedBlackScholesProcess>  process =
>>
>> boost::static_pointer_cast<GeneralizedBlackScholesProcess>(
>>
>> processes_->process(0));
> Honestly, I have no idea why this works. The process you're passing is
> not a GeneralizedBlackScholesProcess, so the cast you're forcing should
> not succeed.  It might just so happen that the bits align right, but
> that's not guaranteed to be portable.
>
> As for a better solution, I'm not sure I have it.  It could be that
> instead of an array of Black-Scholes processes, the Himalaya engine
> takes a generic process and a discount curve (so it doesn't have to
> retrieve the risk-free curve.)
>
> Luigi
>
>

-- 
Regards,
Animesh Saxena

(http://quantanalysis.wordpress.com)
Ph: (+91)9920098221

Re: [Quantlib-dev] Pointer Casting

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

On Tue, 2010-08-31 at 17:47 +0530, animesh saxena wrote:
> I located the error in the code. I think this is probably due to
> design.
> Generally people would like to price options using different
> processes. For example Himalayan Option is priced using BlackScholes
> process in the example. When I change it to another process like
> Merton76Process (which also is Stochastic1D - as per the guidelines),
> I should be able to price it.

Yes, in principle. But while the path generation does work with a
generic process, the McHimalaya path pricer calls a method from the 
BlackScholes interface, namely, riskFreeRate().  The method is not in
the Stochastic1D interface, so we need to cast.

> The cast is throwing the error.

It should.

>  If I change it to "STATIC CAST", the error is gone!
>         boost::shared_ptr<GeneralizedBlackScholesProcess> process =
> 
> boost::static_pointer_cast<GeneralizedBlackScholesProcess>(
> 
> processes_->process(0));

Honestly, I have no idea why this works. The process you're passing is
not a GeneralizedBlackScholesProcess, so the cast you're forcing should
not succeed.  It might just so happen that the bits align right, but
that's not guaranteed to be portable.

As for a better solution, I'm not sure I have it.  It could be that
instead of an array of Black-Scholes processes, the Himalaya engine
takes a generic process and a discount curve (so it doesn't have to
retrieve the risk-free curve.)

Luigi


-- 

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

Re: [Quantlib-dev] Info about generalized HW model with no constant parameters

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

On Mon, 2010-08-30 at 12:02 +0200, tar...@li... wrote:
> Hello 
> I saw this post about Generalized HW model
> 
> http://old.nabble.com/Generalized-Hull-White-model-with-non-constant-
> parameters-td26287370.html#a26635940
> 
> I would like to know if it is embedded into the quantlib 1.0.1 version ? From 
> a first sight it seems it is not!

No, it's not. It will be in next release. In the meantime, you can get
it from the Subversion repository if you want to try it out. See
<http://quantlib.org/svn.shtml> for instructions.

Luigi


-- 

The nice thing about standards is that there are so many of them to 
choose from. 
-- Andrew S. Tanenbaum 

[Quantlib-dev] Pointer Casting

[animesh s. <ani...@gm...>]

  I located the error in the code. I think this is probably due to design.
Generally people would like to price options using different processes. 
For example Himalayan Option is priced using BlackScholes process in the 
example. When I change it to another process like Merton76Process (which 
also is Stochastic1D - as per the guidelines), I should be able to price 
it. The error is when it delegates to casting to generalized Black 
Scholes process, the following code in file mchimalayaengine.hpp.

     template <class RNG, class S>
     inline
     boost::shared_ptr<typename MCHimalayaEngine<RNG,S>::path_pricer_type>
     MCHimalayaEngine<RNG,S>::pathPricer() const {

*        boost::shared_ptr<GeneralizedBlackScholesProcess> process =*
*            boost::dynamic_pointer_cast<GeneralizedBlackScholesProcess>(*
*                                                      
processes_->process(0));*
         QL_REQUIRE(process, "Black-Scholes process required");

         return boost::shared_ptr<
                          typename 
MCHimalayaEngine<RNG,S>::path_pricer_type>(
             new HimalayaMultiPathPricer(arguments_.payoff,
                                         process->riskFreeRate()->discount(
                                            
arguments_.exercise->lastDate())));
     }

The cast is throwing the error. If I change it to *"STATIC CAST", the 
error is gone!
         boost::shared_ptr<GeneralizedBlackScholesProcess> process =*
*            boost::static_pointer_cast<GeneralizedBlackScholesProcess>(*
*                                                      
processes_->process(0));*

The developer's might have better suggestions. Any views on this?? Is 
this a design problem?
Thanks in advance.


On 8/31/10 1:57 AM, animesh saxena wrote:
>  Below is the sample code for Himalayan Option valuation. It works for 
> BlackScholes process but if I change it to slightly fancier 
> Merton76Process (Jumps), it throws out an ugly SIG ABORT exception. 
> Can anyone help me in figuring out the mistake. "Just copy paste the 
> code below to test it out".
> Thanks in advance!
>
> Date today = Settings::instance().evaluationDate();
>
>     DayCounter dc = Actual360();
>     std::vector<Date> fixingDates;
>     for (Size i=0; i<5; ++i)
>         fixingDates.push_back(today+i*90);
>
>     Real strike = 100.0;
>     HimalayaOption option(fixingDates, strike);
>
>     Handle<YieldTermStructure> riskFreeRate(flatRate(today, 0.05, dc));
>
>     std::vector<boost::shared_ptr<StochasticProcess1D> > processes(4);
>
>     boost::shared_ptr<SimpleQuote> spot(new SimpleQuote(100));
>     boost::shared_ptr<SimpleQuote> qRate(new SimpleQuote(0.01));
>     boost::shared_ptr<YieldTermStructure> qTS = flatRate(today, qRate, 
> dc);
>     boost::shared_ptr<SimpleQuote> rRate(new SimpleQuote(0.05));
>     boost::shared_ptr<YieldTermStructure> rTS = flatRate(today, rRate, 
> dc);
>     boost::shared_ptr<SimpleQuote> vol(new SimpleQuote(0.20));
>     boost::shared_ptr<BlackVolTermStructure> volTS = flatVol(today, 
> vol, dc);
>
>
>     boost::shared_ptr<SimpleQuote> jumpIntensity(new SimpleQuote(1));
>     boost::shared_ptr<SimpleQuote> meanLogJump(new SimpleQuote(0.2));
>     boost::shared_ptr<SimpleQuote> jumpVol(new SimpleQuote(0.2));
>
>    processes[0]= boost::shared_ptr<StochasticProcess1D>(new 
> Merton76Process(Handle<Quote>(spot),Handle<YieldTermStructure>(qTS),Handle<YieldTermStructure>(rTS),Handle<BlackVolTermStructure>(volTS),Handle<Quote>(jumpIntensity),Handle<Quote>(meanLogJump),Handle<Quote>(jumpVol))); 
>
>     processes[1]= boost::shared_ptr<StochasticProcess1D>(new 
> Merton76Process(Handle<Quote>(spot),Handle<YieldTermStructure>(qTS),Handle<YieldTermStructure>(rTS),Handle<BlackVolTermStructure>(volTS),Handle<Quote>(jumpIntensity),Handle<Quote>(meanLogJump),Handle<Quote>(jumpVol))); 
>
>     processes[2]= boost::shared_ptr<StochasticProcess1D>(new 
> Merton76Process(Handle<Quote>(spot),Handle<YieldTermStructure>(qTS),Handle<YieldTermStructure>(rTS),Handle<BlackVolTermStructure>(volTS),Handle<Quote>(jumpIntensity),Handle<Quote>(meanLogJump),Handle<Quote>(jumpVol))); 
>
>     processes[3]= boost::shared_ptr<StochasticProcess1D>(new 
> Merton76Process(Handle<Quote>(spot),Handle<YieldTermStructure>(qTS),Handle<YieldTermStructure>(rTS),Handle<BlackVolTermStructure>(volTS),Handle<Quote>(jumpIntensity),Handle<Quote>(meanLogJump),Handle<Quote>(jumpVol))); 
>
>
>
>
>     Matrix correlation(4,4);
>     correlation[0][1] = 0.29;
>     correlation[0][2] = 0.29;
>     correlation[0][3] = 0.39;
>     correlation[1][0] = 0.49;
>     correlation[1][2] = 0.59;
>     correlation[1][3] = 0.69;
>
>     correlation[2][2] = 0.19;
>     correlation[2][3] = 0.29;
>
>     correlation[3][0] = correlation[0][3];
>     correlation[3][1] = correlation[1][3];
>     correlation[3][2] = correlation[2][3];
>     correlation[2][0] = correlation[0][2];
>     correlation[2][1] = correlation[1][2];
>     correlation[1][1] = 1.00;
>
>     correlation[0][0] = 1.00;
>     correlation[3][3] = 1.00;
>
>
>     BigNatural seed = 42;
>     int i_samples;
>     i_samples = 4999;
>     Size fixedSamples;
>     boost::shared_ptr<StochasticProcessArray> process(new 
> StochasticProcessArray(processes, correlation));
>     Real value;
>     
> option.setPricingEngine(MakeMCHimalayaEngine<PseudoRandom>(process).withSamples(fixedSamples).withSeed(seed));
>     value = option.NPV();
>
>
>

-- 
Regards,
Animesh Saxena

(http://quantanalysis.wordpress.com)
Ph: (+91)9920098221

[Quantlib-dev] Info about generalized HW model with no constant parameters

[<tar...@li...>]

Hello 
I saw this post about Generalized HW model

http://old.nabble.com/Generalized-Hull-White-model-with-non-constant-
parameters-td26287370.html#a26635940

I would like to know if it is embedded into the quantlib 1.0.1 version ? From 
a first sight it seems it is not!

Thanks 

Paolo

[Quantlib-dev] Variance Swap Implementation

[animesh s. <ani...@gm...>]

  I have been trying to price Variance Swap using Monte carlo 
simulation. After trying various codes including the one in test-suite I 
wasn't able to get the correct price. There is a huge different in fair 
price. For example fair strike of variance swap for 20% volatility 
generally is implied vol of 90 Strike put. Roughly this is around 30% - 
33%.
*Quantlib gives out 20%.
*Initially I thought I was doing something wrong in my code. I then 
checked the various classes "McSimulation.hpp, 
mcvarianceswapengine.hpp". I traced down the "Strategy" pattern being 
used and the code

             
McSimulation<SingleVariate,RNG,S>::calculate(requiredTolerance_,
                                                          requiredSamples_,
                                                          maxSamples_);

*Again this uses the MonteCarlo model and the path generator to generate 
the random walk. Problem is it's using the variance and mean of the 
random walk!!!
For variance swap
1. Generate the random walk,
2. Calculate Log returns (Missing Step)
3. Calculate variance of Log returns
4. Annualize it (x 252), take square root. = Fair strike of variance swap.

I think the Variance swap replication implementation is correct, but 
generally I don't trust it coz of mathematical anomaly I described in my 
blog.
(Just read the last paragraph)

http://quantanalysis.wordpress.com/2010/08/21/variance-swaps-%E2%80%93-simple-mistakes/
*

-- 
Regards,
Animesh Saxena

(http://quantanalysis.wordpress.com)
Ph: (+91)9920098221

[Quantlib-dev] VarSwap Implementation

[animesh s. <ani...@gm...>]

  I was trying out the Variance Swap (test-suite) implementation and 
came across some pricing issues.
Let me state this ->
1. The simplest way to price a variance swap is to simulate the stock 
using a random walk.
2. Calculate Log(Si/Si-1) at each step
3. Calculate total variance and annualize it
4. For several simulations repeat the above steps and calculate average 
variance
5. Square root of average variance is price of Variance Swap

Attaching a simple implementation based on above steps.

Next I proceeded with quantlib and used the method testMCVarianceSwap
t = Expiry time, I changed it to 1 instead of 0.24675

I was confused with parameters t1 and v1.
I assumed t1 can be either 1. Time from expiry, so setting t1 = 0 would 
have been good to go, but it resulted in error
                                           2. Time remaining before 
expiry so setting t1 = 0.99 would have been good to go, but again it 
resulted in error.
Anyway I tried it for t1 = 0.01 and t1 = 0.99 and it worked( Although I 
still dont understand why t1 can't be 0 or 1)

Same confusion with v1 and v. Couldn't find anything in documentation, 
so a bit confused.
For 20% vol the price came out to be very close to 20%.

 From my excel sheet the price is close to 31%.

Also I don't see any point in having a varstrike parameter, if we are 
calculating fair strike for a variance swap.
Can someone guide me in how it is implemented in Quantlib?






-- 
Regards,
Animesh Saxena

(http://quantanalysis.wordpress.com)
Ph: (+91)9920098221

[Quantlib-dev] Shocking the Zero Curve

[Robert P. <rob...@sy...>]

/* -*- mode: c++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */

/*
 Copyright (C) 2006 Roland Lichters
 Copyright (C) 2006, 2008 StatPro Italia srl

 This file is part of QuantLib, a free-software/open-source library
 for financial quantitative analysts and developers - http://quantlib.org/

 QuantLib is free software: you can redistribute it and/or modify it
 under the terms of the QuantLib license.  You should have received a
 copy of the license along with this program; if not, please email
 <qua...@li...>. The license is also available online at
 <http://quantlib.org/license.shtml>.

 This program is distributed in the hope that it will be useful, but WITHOUT
 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
 FOR A PARTICULAR PURPOSE.  See the license for more details.
*/

/*! \file piecewisezerospreadedtermstructure.hpp
    \brief Piecewise-zero-spreaded term structure
*/

#ifndef quantlib_piecewise_zero_spreaded_term_structure_hpp
#define quantlib_piecewise_zero_spreaded_term_structure_hpp

#include <ql/termstructures/yield/zeroyieldstructure.hpp>
#include <ql/quote.hpp>
#include <vector>

namespace QuantLib {

  //! Term structure with an added vector of spreads on the zero-yield rate
  /*! The zero-yield spread at any given date is linearly interpolated
      between the input data.

      \note This term structure will remain linked to the original
            structure, i.e., any changes in the latter will be
            reflected in this structure as well.

      \ingroup yieldtermstructures
  */
  class PiecewiseZeroSpreadedTermStructure : public ZeroYieldStructure {
    public:
      PiecewiseZeroSpreadedTermStructure(
                                   const Handle<YieldTermStructure>&,
                                   const std::vector<Handle<Quote> >& spreads,
                                   const std::vector<Date>& dates,
								   // added (RP, 2010.08.23)
                                   Compounding comp = Continuous,
                                   Frequency freq = NoFrequency,
                                   const DayCounter& dc = DayCounter());
      //! \name YieldTermStructure interface
      //@{
      DayCounter dayCounter() const;
      Natural settlementDays() const;
      Calendar calendar() const;
      const Date& referenceDate() const;
      Date maxDate() const;
      //@}
    protected:
      //! returns the spreaded zero yield rate
      Rate zeroYieldImpl(Time) const;
	  // added (RP, 20100823)
      //! returns the spreaded forward rate
      Rate forwardImpl(Time) const;
      void update();
    private:
      void updateTimes();
	  const double calcSpread( Time t ) const;
      Handle<YieldTermStructure> originalCurve_;
      std::vector<Handle<Quote> > spreads_;
      std::vector<Date> dates_;
      std::vector<Time> times_;
	  // added (RP, 2010.08.23)
      Compounding comp_;
      Frequency freq_;
      DayCounter dc_;
  };


    // inline definitions

    inline
    PiecewiseZeroSpreadedTermStructure::PiecewiseZeroSpreadedTermStructure(
                                   const Handle<YieldTermStructure>& h,
                                   const std::vector<Handle<Quote> >& spreads,
                                   const std::vector<Date>& dates,
								   // added (RP, 2010.08.23)
                                   Compounding comp,
                                   Frequency freq,
                                   const DayCounter& dc)
    : originalCurve_(h), spreads_(spreads), dates_(dates),
      times_(dates_.size()),
	  // added (RP, 2010.08.23)
	  comp_(comp), freq_(freq), dc_(dc) {
        QL_REQUIRE(!spreads_.empty(), "no spreads given");
        QL_REQUIRE(spreads_.size() == dates_.size(),
                   "spread and date vector have different sizes");
        registerWith(originalCurve_);
        for (Size i = 0; i < spreads_.size(); i++)
            registerWith(spreads_[i]);
        updateTimes();
    }

    inline DayCounter PiecewiseZeroSpreadedTermStructure::dayCounter() const {
        return originalCurve_->dayCounter();
    }

    inline Calendar PiecewiseZeroSpreadedTermStructure::calendar() const {
        return originalCurve_->calendar();
    }

    inline Natural PiecewiseZeroSpreadedTermStructure::settlementDays() const {
        return originalCurve_->settlementDays();
    }

    inline const Date&
    PiecewiseZeroSpreadedTermStructure::referenceDate() const {
        return originalCurve_->referenceDate();
    }

    inline Date PiecewiseZeroSpreadedTermStructure::maxDate() const {
        return std::min(originalCurve_->maxDate(), dates_.back());
    }

    inline Rate
    PiecewiseZeroSpreadedTermStructure::zeroYieldImpl(Time t) const {
        //Rate z = originalCurve_->zeroRate(t, Continuous, NoFrequency, true);
        //if (t <= times_.front()) {
        //    return z + spreads_.front()->value();
        //} else if (t >= times_.back()) {
        //    return z + spreads_.back()->value();
        //} else {
        //    Size i;
        //    for (i = 0; i < times_.size(); i++)
        //        if (times_[i] > t) break;
        //    Time dt = times_[i] - times_[i-1];
        //    return z + spreads_[i]->value() * (t - times_[i-1]) / dt
        //        + spreads_[i-1]->value() * (times_[i] - t) / dt;
        //}

		// added (RP, 20100823)
		double spread = calcSpread( t );
        InterestRate zeroRate = originalCurve_->zeroRate(t, comp_, freq_, true);
        InterestRate spreadedRate(zeroRate + spread,
                                  zeroRate.dayCounter(),
                                  zeroRate.compounding(),
                                  zeroRate.frequency());
        return spreadedRate.equivalentRate(Continuous, NoFrequency, t);
    }

	inline const double 
	PiecewiseZeroSpreadedTermStructure::calcSpread( Time t ) const {
		double spread = 0.0;
        if (t <= times_.front()) {
            spread = spreads_.front()->value();
        } else if (t >= times_.back()) {
            spread = spreads_.back()->value();
        } else {
            Size i;
            for (i = 0; i < times_.size(); i++)
                if (times_[i] > t) break;
            Time dt = times_[i] - times_[i-1];
            spread = spreads_[i]->value() * (t - times_[i-1]) / dt
                + spreads_[i-1]->value() * (times_[i] - t) / dt;
        }

		return spread;
	}

	inline void PiecewiseZeroSpreadedTermStructure::update() {
        updateTimes();
        ZeroYieldStructure::update();
    }

    inline void PiecewiseZeroSpreadedTermStructure::updateTimes() {
        for (Size i = 0; i < dates_.size(); i++)
            times_[i] = timeFromReference(dates_[i]);
    }

}


#endif

Re: [Quantlib-dev] [Quantlib-users] LazyObject quick question

[Kakhkhor A. <kab...@gm...>]

I see. Thanks for clarification.

Re: [Quantlib-dev] Null class bug on x64 targets

[Kakhkhor A. <kab...@gm...>]

On Windows ICC defines both _MSC_VER and __INTEL_COMPILER.

Re: [Quantlib-dev] Generalized Hull-White model problems

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

On Thu, 2010-07-29 at 22:49 -0700, Javit Hafizoglu wrote:
> I updated the generalized Hull White model and performed tests with
> QL-1.0.1. Tests are successful. For some reason calibration takes longer
> now. In the BermudanSwaption.cpp, I changed the optimization end criteria
> down to 40 and 10 from 400 and 100 for the max iteration and stationary
> iterations. This way, it takes shorter to calibrate.
> 
> I attached the files. The changes:
> 
> -- For some reason, parameter.hpp in QL-1.0.1 is not the same as trunk
> version 17224.

That's because 1.0.1 is a bug-fix release, and wasn't supposed to
contain any new stuff.  Your contribution and the related parameter
changes went on the trunk so that it will be in 1.1 (whenever that comes
out.)  In fact, it would be nice if you could base your files on the
trunk version so that it will be easier to merge in your changes.  Do
you think you might find some time to do this?

Thanks,
	Luigi


-- 

Discontent is the first necessity of progress. 
-- Thomas A. Edison 

Re: [Quantlib-dev] Null class bug on x64 targets

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

On Tue, 2010-08-17 at 20:01 -0500, Kakhkhor Abdijalilov wrote:
> Some more ICC for Windows related issues showed up
> 
> 1) BOOST_MSVC is not defined on IA-32, which prevents auto linking.
> Including auto_link.hpp directly works.

Does ICC define any macro that can be used to identify it?

Luigi


-- 

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

Re: [Quantlib-dev] Implementing an optionlet stripper

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

On Thu, 2010-08-19 at 19:41 +0200, tar...@li... wrote:
> all input data look ok but when I go to use the capletStripperAdapt pointer my 
> system crash and debugging it the problem is in the file sp_counter_base_w32.
> hpp line 100 (boost lib) with the following exception:
> 
> Unhandled exception at 0x05673360, access violation writing location 
> 0xffff6234

That's a bit too deep into the implementation.
What is the call stack? (I mean, the function F that called the one
crashing in sp_counter_base_w32, and the function G that called F, and
the function that called G etc.)

Luigi


-- 

There is no likelihood man can ever tap the power of the atom. 
-- Robert Millikan, Nobel Prize in Physics, 1923 

[Quantlib-dev] Implementing an optionlet stripper

[<tar...@li...>]

Hello,

I am implementing an optionlet stripper as described below

//  START CODE

boost::shared_ptr<CapFloorTermVolSurface> capfloorVolSurf;
capfloorVolSurf = boost::shared_ptr<CapFloorTermVolSurface>(new 
CapFloorTermVolSurface(0, iCal, iRollConv, iOptionTenors, iStrikes, iSigmas, 
iDayCount));

// Underlying Libor index (Euribor 6-Months)
boost::shared_ptr<IborIndex> iborIndex(new Euribor6M(yieldTermStructure));

boost::shared_ptr<OptionletStripper> capletStripper1(new OptionletStripper1
(capfloorVolSurf,iborIndex,Null<Rate>(),0.00000001));
boost::shared_ptr<StrippedOptionletAdapter> capletStrippedAdapt = boost::
shared_ptr<StrippedOptionletAdapter>(new StrippedOptionletAdapter
(capletStripper1));
Date maximdate=capletStrippedAdapt->maxDate();

// END CODE

all input data look ok but when I go to use the capletStripperAdapt pointer my 
system crash and debugging it the problem is in the file sp_counter_base_w32.
hpp line 100 (boost lib) with the following exception:

Unhandled exception at 0x05673360, access violation writing location 
0xffff6234

Any clue?
Thanks in advance,
Paolo

[Quantlib-dev] [ quantlib-Patches-3047353 ] Fix for Intel C++ Compiler

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

Patches item #3047353, was opened at 2010-08-17 19:16
Message generated for change (Comment added) made by renorm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3047353&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: renorm (renorm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for Intel C++ Compiler

Initial Comment:
Singleton pattern doesn't work with Intel's C++ compiler. The cause is the static variable which can't be properly accessed from different translation units. The attached file shows a possible solution. It uses static const pointer to the map of instances.

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

>Comment By: renorm (renorm)
Date: 2010-08-18 09:15

Message:
Fixed Singleton for Intel C++ compiler

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

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

Re: [Quantlib-dev] fix for intel's compiler

[Kakhkhor A. <kab...@gm...>]

> may you upload the whole modified file
It is done.
Regards,
K.A.

[Quantlib-dev] [ quantlib-Patches-3047358 ] fixed gaussian orthogonal polynomial

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

Patches item #3047358, was opened at 2010-08-17 19:25
Message generated for change (Comment added) made by renorm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3047358&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: renorm (renorm)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixed gaussian orthogonal polynomial

Initial Comment:
double with zero comparison  issue

Only fixed function are included

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

>Comment By: renorm (renorm)
Date: 2010-08-18 09:08

Message:
the whole file with fixes

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

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

Re: [Quantlib-dev] fix for intel's compiler

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

On Tue, 2010-08-17 at 18:17 -0500, Kakhkhor Abdijalilov wrote:
> I uploaded C++ code into the path system.

Kakhkhor,
	sorry, but may you upload the whole modified file instead of only the
modified functions?  With the whole file, I can easily use the diff tool
to merge your patch (and be sure that it doesn't conflict with other
changes, if any is made between now and when I do the merge); with only
part of the file, it becomes more difficult.

Thanks,
	Luigi

-- 

Academic: a term of opprobrium applied to those that do their job well 
by those who cannot. 
-- Sir Ernest Gowers 

Re: [Quantlib-dev] fix for intel's compiler

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

On Tue, 2010-08-17 at 18:17 -0500, Kakhkhor Abdijalilov wrote:
> I uploaded C++ code into the path system.

Ok, thanks.

Luigi

-- 

The nice thing about standards is that there are so many of them to 
choose from. 
-- Andrew S. Tanenbaum 

Re: [Quantlib-dev] Null class bug on x64 targets

[Kakhkhor A. <kab...@gm...>]

Some more ICC for Windows related issues showed up

1) BOOST_MSVC is not defined on IA-32, which prevents auto linking.
Including auto_link.hpp directly works.

2) The second issue is not caused directly by QuantLib, but it is good
to know about it.
Bjam compiles boost with _SECULRE_SCL=0 when ICC is used. But Visual
Studio's STL uses _SECULRE_SCL=1 by default and ICC relies  on Visual
Studio's implementation. QuantLib itself doesn't use any compiled
boost libraries, but the test suite links to boost unit test
framework, which is a compiled library. Inconsistent _SECULRE_SCL
values violate one definition rule and cause the test suite to fail or
even crash. To fix this issue one needs to recompile all libraries
using the same _SECULRE_SCL value.

Regards,
K.A.

Re: [Quantlib-dev] gaussianorthogonalpolynomial.cpp : double to bool conversion and possible problem on x64 targets

[Kakhkhor A. <kab...@gm...>]

>may you resend your fix as a patch?
Done.

>A standard approach to get  of the foresight bias is to use simple discard all paths used for
>calibration

That makes sense. Thanks for explanation.

[Quantlib-dev] [ quantlib-Patches-3047358 ] fixed gaussian orthogonal polynomial

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

Patches item #3047358, was opened at 2010-08-17 19:25
Message generated for change (Tracker Item Submitted) made by renorm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3047358&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: renorm (renorm)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixed gaussian orthogonal polynomial

Initial Comment:
double with zero comparison  issue

Only fixed function are included

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

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

Re: [Quantlib-dev] fix for intel's compiler

[Kakhkhor A. <kab...@gm...>]

I uploaded C++ code into the path system.

[Quantlib-dev] [ quantlib-Patches-3047353 ] Fix for Intel C++ Compiler

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

Patches item #3047353, was opened at 2010-08-17 19:16
Message generated for change (Tracker Item Submitted) made by renorm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3047353&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: renorm (renorm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for Intel C++ Compiler

Initial Comment:
Singleton pattern doesn't work with Intel's C++ compiler. The cause is the static variable which can't be properly accessed from different translation units. The attached file shows a possible solution. It uses static const pointer to the map of instances.

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

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

Re: [Quantlib-dev] gaussianorthogonalpolynomial.cpp : double to bool conversion and possible problem on x64 targets

[Klaus S. <kl...@sp...>]

Hi

On Thursday 12 August 2010 10:33:16 Kakhkhor Abdijalilov wrote:
> Btw, can anyone explain why LS path pricer does calibration and
> pricing separately? Current implementation simply discards all paths
> used for calibration. It is not only wasteful...

If you are using the same paths for both calibration and valuation the 
resulting estimator includes a "foresight bias". A standard approach to get 
rid of the foresight bias is to use simple discard all paths used for 
calibration. Please find more details and other algorithms to remove the 
foresight bias here

http://www.christian-fries.de/finmath/foresightbias/

> EquityOption.cpp example
> uses only 4096 paths for calibration and tries to price with
> tolerance=0.02

Values are taken (more or less) from Glasserman, Monte-Carlo-Methods in 
Financial Engineering. Within the Monte-Carlo error (0.02)  the Longstaff 
Schwartz price (4.481675) is consistent with the other american pricer 
(especially with the finite different pricer, 4.486118). Increasing the 
number of calibration paths towards e.g. 65535 does not change the price 
significantly (4.464887). IMO 4096 calibration paths are enough for this 
example.

best regards
 Klaus