quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Patches-3064571 ] unitofmeasureconversionmanager.hpp change

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

Patches item #3064571, was opened at 2010-09-12 03:38
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3064571&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: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: manas (manasb)
Assigned to: Luigi Ballabio (lballabio)
Summary: unitofmeasureconversionmanager.hpp change

Initial Comment:
removed friend reference to the class from which it is derived ie 

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
        friend class Singleton<UnitOfMeasureConversionManager>;

to

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
    


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

Comment By: Luigi Ballabio (lballabio)
Date: 2010-09-13 11:29

Message:
No, the friend declaration is correct.  The error was having the
UnitOfMeasureConversionManager constructor public; it should be private (to
prevent client code to instantiate it; only the Singleton machinery should)
at which point the base Singleton class must be a friend.  Thanks for the
heads-up anyway; the issue will be fixed in next release.

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

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

[Quantlib-dev] [ quantlib-Patches-3064571 ] unitofmeasureconversionmanager.hpp change

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

Patches item #3064571, was opened at 2010-09-12 03:38
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3064571&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: Rejected
Priority: 5
Private: No
Submitted By: manas (manasb)
>Assigned to: Luigi Ballabio (lballabio)
Summary: unitofmeasureconversionmanager.hpp change

Initial Comment:
removed friend reference to the class from which it is derived ie 

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
        friend class Singleton<UnitOfMeasureConversionManager>;

to

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
    


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

>Comment By: Luigi Ballabio (lballabio)
Date: 2010-09-13 11:29

Message:
No, the friend declaration is correct.  The error was having the
UnitOfMeasureConversionManager constructor public; it should be private (to
prevent client code to instantiate it; only the Singleton machinery should)
at which point the base Singleton class must be a friend.  Thanks for the
heads-up anyway; the issue will be fixed in next release.

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

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

[Quantlib-dev] [ quantlib-Patches-3064571 ] unitofmeasureconversionmanager.hpp change

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

Patches item #3064571, was opened at 2010-09-12 09:38
Message generated for change (Tracker Item Submitted) made by manasb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3064571&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: manas (manasb)
Assigned to: Nobody/Anonymous (nobody)
Summary: unitofmeasureconversionmanager.hpp change

Initial Comment:
removed friend reference to the class from which it is derived ie 

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
        friend class Singleton<UnitOfMeasureConversionManager>;

to

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
    


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

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

Re: [Quantlib-dev] Contribute to Quantlib - Commodities

[manas b. <ma...@ho...>]

Hi Luigi,  thanks for the suggestion. I will work on that. Also, i would like to improve the way the code is written especially how the commodity curve and it's associated classes (cashflows, unitofmeasure, etc) are defined. Hope, that's ok with you.regards,Manas

> Subject: Re: [Quantlib-dev] Contribute to Quantlib - Commodities
> From: lui...@gm...
> To: ma...@ho...
> CC: qua...@li...
> Date: Fri, 10 Sep 2010 17:05:08 +0200
> 
> On Thu, 2010-09-02 at 22:56 +0800, manas bhatt wrote:
> >   I would like to contribute to quantlib. My experience is in
> > commodities. I have already checked out the source code and have built
> > the quantlib library. I saw that commodity is inside experimental
> > folder.  I would like to know how to move the Commodity module from
> > experimental folder to the main quantlib library.
> 
> 
> Hi Manas,
> 	apologies for the delay.  To begin with, it would be of great help if
> you might look at the code in the experimental/commodity folder and
> check that it does work as advertised.  Writing a few test cases would
> be great, too.
> 
> Later,
> 	Luigi
> 
> 
> -- 
> 
> Quote me as saying I was misquoted. 
> -- Groucho Marx 
> 
> 
 		 	   		  

[Quantlib-dev] [ quantlib-Patches-3064373 ] unitofmeasureconversionmanager.hpp change

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

Patches item #3064373, was opened at 2010-09-12 01:28
Message generated for change (Tracker Item Submitted) made by manasb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3064373&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: manas (manasb)
Assigned to: Nobody/Anonymous (nobody)
Summary: unitofmeasureconversionmanager.hpp change

Initial Comment:
removed friend reference to the class from which it is derived ie 

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
        friend class Singleton<UnitOfMeasureConversionManager>;

to

class UnitOfMeasureConversionManager
        : public Singleton<UnitOfMeasureConversionManager> {
    


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

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

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

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

Thanks a lot. That is encouraging.

What if the instance() method is synchronized with mutex, could it
solve static singleton problem?

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

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

On Thu, 2010-09-02 at 02:49 -0500, Kakhkhor Abdijalilov wrote:
> I could run several examples but the test suite crashes instantly with
> memory access violation error. Can someone try the test suite with the
> singleton attached below?

Tried it on an Ubuntu system with gcc 4.4.3.  Worked fine...

Luigi


-- 

The shortest way to do many things is to do only one thing at once. 
-- Samuel Smiles 

Re: [Quantlib-dev] Open Discussion

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

On Thu, 2010-09-02 at 17:39 +0530, animesh saxena wrote:
> Thanks a lot. Just one minor thing I noticed in
> blackscholesprocess.hpp
> 
>             dS(t, S) = (r(t) - q(t) - \frac{\sigma(t, S)^2}{2}) dt
>                      + \sigma dW_t.
> 
> The above process is not possible, coz you can't have sigma(t,S).

Except you do.  If sigma is not constant, you might not derive all the
usual equations.  But you can define the process above just the same.

Luigi


-- 

Any software problem can be solved by adding another layer of
indirection. 
-- David J. Wheeler 

Re: [Quantlib-dev] Contribute to Quantlib - Commodities

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

On Thu, 2010-09-02 at 22:56 +0800, manas bhatt wrote:
>   I would like to contribute to quantlib. My experience is in
> commodities. I have already checked out the source code and have built
> the quantlib library. I saw that commodity is inside experimental
> folder.  I would like to know how to move the Commodity module from
> experimental folder to the main quantlib library.


Hi Manas,
	apologies for the delay.  To begin with, it would be of great help if
you might look at the code in the experimental/commodity folder and
check that it does work as advertised.  Writing a few test cases would
be great, too.

Later,
	Luigi


-- 

Quote me as saying I was misquoted. 
-- Groucho Marx 

Re: [Quantlib-dev] Longstaff-Schwartz method, SVD and OLS

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

My message didn't show up in Nabble forum.  I am resending it just in
case it didn't go through.


On Wed, Sep 8, 2010 at 8:42 AM, Kakhkhor Abdijalilov
<kab...@gm...> wrote:
> It seems that LongstaffSchwartzPathPricer implementation may not deal
> with basis collinearity properly.
>
> SVD can deal with collinearity, but the cutoff threshold for small
> singular values in LinearLeastSquaresRegression is n*QL_EPSILON (n is
> matrix size).
>
> Btw, the cutoff should be applied to the ratio of singular values, not
> to the singular values directly. That is something we need to fix as
> well.
>
> The above cutoff  threshold  is OK for OLS purposes, but not for MC
> (at least how it is implemented in QL). For OLS purposes we compute
> coefficients by performing SVD of the design matrix and then use those
> coefficients with the same design matrix to compute the projection of
> the dependent variable. This way all singular values cancel out as
> long as the cutoff was applied.
>
> But LongstaffSchwartzPathPricer does compute projection (option
> continuation values) from a new sample. It is like using the old
> coefficients with a new design matrix. There is chance that singular
> values of this new design matrix won't cancels out inverse singular
> values of the old design matrix. Both design matrices have the same
> statistical properties, so that singular values should be more or less
> comparable, except very small ones. With typical sample sizes, SVD
> cutoff threshold can be as small as 1.0E-012, which is much smaller
> than statistical uncertainty of MC (inverse square root of sample
> size). Small singular values will show up whenever there is a
> collinearity in the basis system.
>
> Fortunately, the problem is fixed if SVD cutoff (n*QL_EPSILON) is
> replaced  with something commensurable with MC tolerance. I want to
> code and submit new LongstaffSchwartzPathPricer and
> LinearLeastSquaresRegression classes, but would like to know others
> think.
>
> With best regards,
> Kakhkhor Abdijalilov.

[Quantlib-dev] Longstaff-Schwartz method, SVD and OLS

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

It seems that LongstaffSchwartzPathPricer implementation may not deal
with basis collinearity properly.

SVD can deal with collinearity, but the cutoff threshold for small
singular values in LinearLeastSquaresRegression is n*QL_EPSILON (n is
matrix size).

Btw, the cutoff should be applied to the ratio of singular values, not
to the singular values directly. That is something we need to fix as
well.

The above cutoff  threshold  is OK for OLS purposes, but not for MC
(at least how it is implemented in QL). For OLS purposes we compute
coefficients by performing SVD of the design matrix and then use those
coefficients with the same design matrix to compute the projection of
the dependent variable. This way all singular values cancel out as
long as the cutoff was applied.

But LongstaffSchwartzPathPricer does compute projection (option
continuation values) from a new sample. It is like using the old
coefficients with a new design matrix. There is chance that singular
values of this new design matrix won't cancels out inverse singular
values of the old design matrix. Both design matrices have the same
statistical properties, so that singular values should be more or less
comparable, except very small ones. With typical sample sizes, SVD
cutoff threshold can be as small as 1.0E-012, which is much smaller
than statistical uncertainty of MC (inverse square root of sample
size). Small singular values will show up whenever there is a
collinearity in the basis system.

Fortunately, the problem is fixed if SVD cutoff (n*QL_EPSILON) is
replaced  with something commensurable with MC tolerance. I want to
code and submit new LongstaffSchwartzPathPricer and
LinearLeastSquaresRegression classes, but would like to know others
think.

With best regards,
Kakhkhor Abdijalilov.

Re: [Quantlib-dev] Shocking the Zero Curve

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

On Mon, 2010-08-23 at 13:00 -0400, Robert Philipp wrote:
> The PiecewiseZeroSpreadedTermStructure class does not shock correctly
> when the compounding is different from continuous.

Yes, the curve assumed that the spread was applied to the continuous
rates. Thanks for the generalization; it will make it into next release.

> I believe that the way forward rates are shocked is incorrect. In the
> code, the spread (shock) is simply added to the forward curve of the
> base. The forward curve should be based on the shocked zero curve
> instead. Has anyone fixed that? If not, I'll try to fix that as well.

You're talking of the ForwardSpreadedTermStructure class now, right? I'm
not sure what the behavior should be in this case. The name of the class
seems to imply that we want to add a spread to the forwards, though.

> Not sure how best to contribute the code. Is there a staging area for
> checking in the code?

Posting here is ok.  Next time, you might consider providing a patch
instead of the modified file (i.e., the output of running the diff
program between the original file and your file.)  But it's no big deal.

Just one question on your code: you added a declaration for 
  Rate forwardImpl(Time) const;
to the header, but no definition afterwards. Is there a method body you
didn't post, or should I just remove the declaration?

Thanks,
	Luigi

P.S. Make that two questions: to whom should I assign the copyright of
the modified code? (Robert Philipp, Synapsefe, both?)



-- 

Green's Law of Debate: 
Anything is possible if you don't know what you're talking about. 

[Quantlib-dev] Contribute to Quantlib - Commodities

[manas b. <ma...@ho...>]

Hi,  I would like to contribute to quantlib. My experience is in commodities. I have already checked out the source code and have built  the quantlib library. I saw that commodity is inside experimental folder.  I would like to know how to move the Commodity module from experimental folder to the main quantlib library.thanksManas 		 	   		  

Re: [Quantlib-dev] Open Discussion

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

  Thanks a lot. Just one minor thing I noticed in blackscholesprocess.hpp

             dS(t, S) = (r(t) - q(t) - \frac{\sigma(t, S)^2}{2}) dt
                      + \sigma dW_t.

The above process is not possible, coz you can't have sigma(t,S). The 
above equation is derived only because sigma is constant. It's a bit 
misleading, Can I make the change to the correct version

             dS(t, S) = (r(t) - q(t) - \frac{\sigma^2}{2}) dt
                      + \sigma dW_t

It's a one line change, In the last few lines of my blog I have given 
the proof.

http://quantanalysis.wordpress.com/2010/08/21/

Just read the ending portion. /

/


On 9/2/10 4:37 PM, Kakhkhor Abdijalilov wrote:
> Forwarding...
>
>>   Thanks for your inputs.
>> I observed a pattern in some exotic options. Correct me if I am wrong.
>> Similar to himalayan option, in variance swap engine also we have the
>> following code
>> MCVarianceSwapEngine(
>>              const boost::shared_ptr<GeneralizedBlackScholesProcess>&  process
>>
>> Since most of the engines are specifically using
>> GeneralizedBlackScholesProcess it's impossible to value the option using any
>> other process. Practically a person would like to value the instrument using
>> any possible process. After struggling with Merton76Process for valuing
>> Himalayan option I tried to get my head around with HestonProcess. It wasn't
>> even remotely possible. Yes I could do the same in excel, but again excel
>> can't do 9Million simulations which Quantlib can do in seconds :). That's
>> why I am trying to replace my excel side of modeling with C++ QuantLib!
>>
>> So what I want to try is "make the above dependency more generic". It should
>> be possible in some way. Any inputs from you guys will help a lot.
>>
>> Thanks again,
>> Animesh Saxena
>>
>> (http://quantanalysis.wordpress.com)
>> Ph: (+91)9920098221
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

-- 
Regards,
Animesh Saxena

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

Re: [Quantlib-dev] Open Discussion

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

Forwarding...

>  Thanks for your inputs.
> I observed a pattern in some exotic options. Correct me if I am wrong.
> Similar to himalayan option, in variance swap engine also we have the
> following code
> MCVarianceSwapEngine(
>             const boost::shared_ptr<GeneralizedBlackScholesProcess>& process
>
> Since most of the engines are specifically using
> GeneralizedBlackScholesProcess it's impossible to value the option using any
> other process. Practically a person would like to value the instrument using
> any possible process. After struggling with Merton76Process for valuing
> Himalayan option I tried to get my head around with HestonProcess. It wasn't
> even remotely possible. Yes I could do the same in excel, but again excel
> can't do 9Million simulations which Quantlib can do in seconds :). That's
> why I am trying to replace my excel side of modeling with C++ QuantLib!
>
> So what I want to try is "make the above dependency more generic". It should
> be possible in some way. Any inputs from you guys will help a lot.
>
> Thanks again,
> Animesh Saxena
>
> (http://quantanalysis.wordpress.com)
> Ph: (+91)9920098221

[Quantlib-dev] Open Discussion

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

  Thanks for your inputs.
I observed a pattern in some exotic options. Correct me if I am wrong.
Similar to himalayan option, in variance swap engine also we have the 
following code
MCVarianceSwapEngine(
              const boost::shared_ptr<GeneralizedBlackScholesProcess>& 
process

Since most of the engines are specifically using 
GeneralizedBlackScholesProcess it's impossible to value the option using 
any other process. Practically a person would like to value the 
instrument using any possible process. After struggling with 
Merton76Process for valuing Himalayan option I tried to get my head 
around with HestonProcess. It wasn't even remotely possible. Yes I could 
do the same in excel, but again excel can't do 9Million simulations 
which Quantlib can do in seconds :). That's why I am trying to replace 
my excel side of modeling with C++ QuantLib!

So what I want to try is "make the above dependency more generic". It 
should be possible in some way. Any inputs from you guys will help a lot.

Thanks again,
Animesh Saxena

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




On 9/1/10 5:09 PM, Kakhkhor Abdijalilov wrote:
> static_pointer_cast on smart pointer will perform static_cast on the
> contained pointer. static_cast will never fail at compiler time
> (unless you try to cast away qualifiers such as const or volatile).
> But if the conversion is illegal, the code will fail at runtime.
> dynamic_cast will check at compile time if the pointer is being
> downcast. If target is not inherited from the source, dynamic_cast
> will refuse to compile.
>
> static_cast cast is faster then dynamic_cast, but inherently unsafe.
> In the above example it is used not in performance critical place.
>
> Hope it help.
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

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

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

I could run several examples but the test suite crashes instantly with
memory access violation error. Can someone try the test suite with the
singleton attached below?

////////////////////////////////////////////////////////////////////
#ifndef quantlib_singleton_hpp
#define quantlib_singleton_hpp

#include <ql/types.hpp>
#include <boost/noncopyable.hpp>
#include <boost/shared_ptr.hpp>
#include <map>

namespace QuantLib {

    #if defined(QL_ENABLE_SESSIONS)
    Integer sessionId();
    #endif

    template <class T>
    class Singleton : private boost::noncopyable {
    public:
        static T& instance() {
            #if defined(QL_ENABLE_SESSIONS)
            Integer id = sessionId();
            #else
            Integer id = 0;
            #endif
            boost::shared_ptr<T>& p = instances_[id];
            if (!p)
                p.reset(new T);
            return *p;
        }

    protected:
        Singleton() {}
    private:
        typedef std::map<Integer, boost::shared_ptr<T> > map_type;
        static map_type instances_;
    };

    template <typename T>
    typename Singleton<T>::map_type Singleton<T>::instances_;

}

#endif

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

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

private:
 static map_type instances_;


It works. No need to for scoped_ptr. I tested it with Intel compiler.

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

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

On Wed, 2010-09-01 at 05:24 -0500, Kakhkhor Abdijalilov wrote:
> I think it is broken just like the design using scoped_ptr or the
> original design.

Ok. One way or the other, Singletons are all broken.  But trying to
avoid breaking interfaces for the time being, and in "normal" usage
(i.e., no Singletons initialized before main() starts): was it needed to
put the map into a scoped_ptr, as in:

private:
  static const boost::scoped_ptr<map_type> instances_;

or would the following work, too?

private:
  static map_type instances_;


Luigi


-- 

Though this be madness, yet there is method in't. 
-- Hamlet, Act II, scene II 

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

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

Patches item #3047358, was opened at 2010-08-18 01:25
Message generated for change (Comment added) made by lballabio
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: Luigi Ballabio (lballabio)
Date: 2010-09-01 16:07

Message:
With your patch, two cases in the test suite fail.  May you investigate?

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

Comment By: renorm (renorm)
Date: 2010-08-18 15: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

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

I think it is broken just like the design using scoped_ptr or the
original design. Consider what happens when Singleton's instance is
used in two implementation files.

// file1.cpp
namespace {
    SingletonObject* const ptr = &SingletonObject::instance();
}

// file2.cpp
namespace {
    SingletonObject* const ptr = &SingletonObject::instance();
}

Who get's to build the singleton?

The only way to avoid this problem is to make the instance itself a
static local and forget about session ID. Each session would have to
reset the singleton, if needed.

A half-solution is to make sure that no instance is crated before
main() is launched. That means no static objects using singleton.

Which way we go?

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

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

On Sat, 2010-08-14 at 20:14 -0500, Kakhkhor Abdijalilov wrote:
> Somehow static non-const local variables and templates don't mix on
> ICC. I modified the original implementation to uses const static
> variable and everything worked well. The new implementation is
> attached.

Kakhkhor,
	do you also need the scoped_ptr below? Would a simple static const
map_type work?

Luigi


> //-----------------------------------------
>     template <class T>
>     class Singleton : private boost::noncopyable {
>     ...
>     private:
>         typedef std::map<Integer, boost::shared_ptr<T> > map_type;
>         static const boost::scoped_ptr<map_type> instances_;
>     };
> 
>     template <typename T>
>     const boost::scoped_ptr<Singleton<T>::map_type>
>         Singleton<T>::instances_(new Singleton<T>::map_type);



-- 

The First Rule of Optimization: Don't do it. 
The Second Rule of Optimization (For experts only): Don't do it yet. 
-- Michael Jackson 

Re: [Quantlib-dev] Pointer Casting

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

On Wed, 2010-09-01 at 09:06 +0200, Luigi Ballabio wrote:
> On Wed, 2010-09-01 at 01:44 +0530, animesh saxena wrote:
> > Also another thing I will point out. Maybe you can understand this
> > better. 
> > There is no evolve() method in merton76process.hpp. 
> 
> It inherits the generic implementation in StochasticProcess1D.

However, it lacks the methods such as drift() etc which are required by
evolve(). You're right, it's currently not usable as a process; it's
just a container for the curves and the other data.

Luigi


-- 

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

Re: [Quantlib-dev] Pointer Casting

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

On Wed, 2010-09-01 at 01:44 +0530, animesh saxena wrote:
> Also another thing I will point out. Maybe you can understand this
> better. 
> There is no evolve() method in merton76process.hpp. 

It inherits the generic implementation in StochasticProcess1D.

Luigi


-- 

Vin: It's like this fellow I knew in El Paso. One day, he just took 
all his clothes off and jumped in a mess of cactus. I asked him that 
same question, "Why?" 
Calvera: And? 
Vin: He said, "It seemed like a good idea at the time." 
-- The Magnificent Seven 

Re: [Quantlib-dev] Pointer Casting

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

  Also another thing I will point out. Maybe you can understand this 
better.
There is no evolve() method in *merton76process.hpp.
**So I think even when casting works perfectly as per the below 
mentioned changes, it can't price as it's trying to build up the path. 
Not sure why evolve method is not there. Without evolve the 
merton76process should not work at all for other things too. Am I 
missing something here?*
*



*

On 9/1/10 1:10 AM, animesh saxena wrote:
>  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