quantlib-dev — Discussion of QuantLib development

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

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

On Tue, 2010-08-10 at 09:49 -0500, Kakhkhor Abdijalilov wrote:
> I compiled QuantLib with ICC for x64 target. Everything went well
> except a glitch with Null class (I reported it in my previous e-mail)
> and some issues in gaussianorthogonalpolynomial.cpp. Current
> implementations of GaussJacobiPolynomial::alpha and
> GaussJacobiPolynomial::beta have several issues.

Kakhkhor,
	may you resend your fix as a patch? It would make it easier for me to
apply it correctly.

Thanks,
	Luigi


-- 

Better to remain silent and be thought a fool than to speak out and 
remove all doubt. 
-- Abraham Lincoln 

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

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

On Fri, 2010-08-13 at 14:40 -0500, Kakhkhor Abdijalilov wrote:
> Btw, without x64 macro auto linking with MS compiler won't work. I am
> for not using separate names for 32 and 64 bit builds.

Noted, but the idea was to allow different builds to coexist in the same
directory, so I'm afraid the different names are staying.

Luigi


-- 

When I was a boy of fourteen, my father was so ignorant I could hardly 
stand to have the old man around. But when I got to be twenty-one, I 
was astonished at how much the old man had learned in seven years. 
-- Mark Twain 

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

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

On Sat, 2010-08-14 at 20:14 -0500, Kakhkhor Abdijalilov wrote:
> Singleton pattern doesn't work with Intel's C++ compiler 11.1 on
> Windows.  I tested it both in 32 and 64 bit modes.
> 
> When optimization is enabled (I used O3), each translation unit ends
> up creating its own instance of Singleton. [...] 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.

Ok, thanks.

Luigi


-- 

Ogden's Law: 
The sooner you fall behind, the more time you have to catch up. 

[Quantlib-dev] [ quantlib-Bugs-3045120 ] Problem in construction of trinomial tree

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

Bugs item #3045120, was opened at 2010-08-14 18:18
Message generated for change (Tracker Item Submitted) made by mandaldi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3045120&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: DILIP MANDAL (mandaldi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem in construction of trinomial tree

Initial Comment:
I am studying this code myself with a hope to get a professional job in this area. I have a PhD in Mechanical Engineering with computational mechanics. 
I was studying Hull-White numerical solution with Ornstein Uhlenbeck Process for valuation of Bermuda swaption. There are few mandatory times where the price of the Bermuda swaption will be calculated. But the time steps in the discretization of trinomial tree could be different. I believe there is a potential bug in the construction of trinomial tree when time step is smaller compare to average time step. In the following picture, time step dt4 is very small. Because dt4 is very small, the variance is also very small and dx4 (at line 44 of trinomialtree.cpp) are also very small. The expectation of the stochastic process between time t3 and t4 are almost same, but the number of branching is getting increased by a lot (temp at line 50 of trinomialtree.cpp). Some of the nodes at time step 4 are floating i.e. (the red dots in the picture will have state price of zero). However, it increases the unnecessary computational time. Furthermore some of the active nodes at time step 4 will have probability of one going from one node at time step 4 to another time step 5. Even though, the results are not wrong, the code could be improved a lot for computational efficiency while using trinomial tree. It seems to me that there is a problem in computation of “temp” at line 50 of trinomialtree.cpp. There is an adjustment needed for the computation of “temp” so that tree does not get many unnecessary branches when time step is small. Any comment is appreciated.
  Please see the attached document.
  Thank you,

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

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

[Quantlib-dev] fix for intel's compiler

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

Singleton pattern doesn't work with Intel's C++ compiler 11.1 on
Windows.  I tested it both in 32 and 64 bit modes.

When optimization is enabled (I used O3), each translation unit ends
up creating its own instance of Singleton. For example, this code
fragment doesn't do what it is supposed to do.

// file1.cpp
Settings::instance().evaluationDate() = date1;

// file2.cpp
Settings::instance().evaluationDate() = date2; // file1.cpp still sees date1

// fie3.cpp
Date date3 = Settings::instance().evaluationDate(); // not equal to date2

Overwriting  evaluation date in file2.cpp doesn't actually overwrite
it. The above code will create 3 instances of Settings class and the
program will eventually crash. 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.

Regards,
Kakhkhor Abdijalilov.

//-----------------------------------------
    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 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);
//-----------------------------------------

[Quantlib-dev] Effective posting similar to boost

[Kim K. T. <kue...@vo...>]

Hi all,

this issue might be or is not directly related to quantlib, but i will 
still start this discussion anyway.
Many members in this community have a full time job. So time is very 
rare for everyone here.
If it is possible, when writing a message, please try to save the 
reader's time.

The page from boost 
http://www.boost.org/community/policy.html#discussion-threads gives a 
good introduction on how to effectively post a message.

As a summary:

    * Don't Overquote, Don't Top-Post, and Do Use Inline Replies for
      Readable Quotations
      <http://www.boost.org/community/policy.html#quoting>
    * Keep the Formatting of Quotations Consistent
      <http://www.boost.org/community/policy.html#formatting-quotations>
    * Maintain the Integrity of Discussion Threads  ( *When starting a
      new topic, always send a fresh message*, rather than beginning a
      reply to some other message and replacing the subject and body)
      <http://www.boost.org/community/policy.html#discussion-threads>
    * Keep The Size of Your Posting Manageable
      <http://www.boost.org/community/policy.html#max-size>


- Kim

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

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

QL compiles and works well with Visual C++ 2008 both in 32 and 64 bit
modes. I only tested Intel C++ compiler 11.1 in 64 bit mode with
Windows Vista 64. Everything compiles and links, but the program
crashes with all zero output. Curiously enough, everything works fine
in debug mode. The error comes from within Event::hasOccured method.
Could be either Singleton class or Settings class. I don't know yet.

Btw, without x64 macro auto linking with MS compiler won't work. I am
for not using separate names for 32 and 64 bit builds.

Regards,
K.A.

Re: [Quantlib-dev] unit test

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

On Thu, 2010-08-05 at 22:04 +0200, Kim Kuen Tang wrote:
> Luigi Ballabio schrieb:
> > On Fri, 2010-07-30 at 22:50 +0200, Kim Kuen Tang wrote:
> >   
> > Kim,
> > 	it's been a while since I've looked at the Boost unit-test framework,
> > so I'm not familiar with the most recent stuff.  Would you suggest
> > switching to BOOST_AUTO_TEST_CASE?  
> to be honest, i wont suggest to move to the run-by-name version even the 
> change is straightforward.
> The extra feature that you will gain seems not worth the effort.

Ok, thanks.

Luigi


-- 

Anyone who says he can see through women is missing a lot. 
-- Groucho Marx 

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

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

On Thu, 2010-08-12 at 17:00 -0500, Kakhkhor Abdijalilov wrote:
> >Again u just need to set the correct macro, then the error should disappear.
> And that is the problem. It means more work for the users. The
> implementation from my previous e-mail could free the users from
> dealing with macros. It will not overwrite any other specialization.

The two of you are arguing the same thing, I think.  The users should't
even need to know there's a macro, or any other mechanism.  That used to
be the case, but a macro needs to be maintained across compilers and
means more work for the library writers.  Your solution puts the burden
on the Boost type-traits maintainers, which is fine with me...

As for Kim's worry about non-builtins, I though of that too, because I
remembered that we had Null<Date> and Null<Array> in the code---but I
had forgotten that somewhere along the way we removed the old catch-all
template and added explicit specializations for Null<Date> etc.
So Kakhkhor's template is going to cover integer and floating-point
types, and specializations will take care of the other classes.

I guess I'll go and check that the proposed implementation works on my
compilers, now.  Kakhkhor, a question: you report that your file doesn't
work with the Intel 11.1 compiler.  But the current version (the one in
the official QuantLib) doesn't work either, right?

Luigi


-- 

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

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

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

>Sorry, cant agree with this point. For a 32-bit msvc compiler size_t is just unsigned int.
That was my point as well. On 32bit targets Null<Size> and
Null<unsigned int> are the same thing. You need a macro to fix it.
There is also Null<unsigned long long> which conflicts with Null<Size>
on x64.

>Again u just need to set the correct macro, then the error should disappear.
And that is the problem. It means more work for the users. The
implementation from my previous e-mail could free the users from
dealing with macros. It will not overwrite any other specialization.

K.A.

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

[Kim K. T. <kue...@vo...>]

Kakhkhor Abdijalilov schrieb:
> Null class is rather confusing. We have Null<int>, Null<long>,
> Null<long long>, Null<unsigned long>, Null<unsigned int>, Null<float>,
> Null<double>, Null<long double> etc. Null<Size> is bound to conflict
> with some of those Nulls on 32 bit platforms, that is why a macro
> switch was needed.
Sorry, cant agree with this point. For a 32-bit msvc compiler size_t is 
just unsigned int. ( The actual implementation depends on the 
compiler.)  Since a specialization for the class Null already exists , 
you can write Null<Size>.
A macro switch is needed because for a 64bit msvc compiler size_t is 
defined by
typedef unsigned __int64    size_t; (see crtdefs.h, line 488).
And since the class Null is not specialised for this type, u need 
explicitly to define one.

>  But the same macro brakes Null on 64 bit platforms.
>   
Again u just need to set the correct macro, then the error should disappear.
> Boost::optional is much better and already used in QuantLib. We should
> use it instead of Null whenever possible. But working Null is still
> needed for backward compatibility.
>
> Only POD types need Null. 
There exist also specializations for Non-POD objects like Array and  
IntervalPrice.

Kim
> Null<std::vector<double> > isn't a
> minefield. We can't accidentally do something like this
>
> POD_type x = Null<std::vector<double> >.
>
> It won't compile.
>
>
> Below is the null.hpp I am using with QuantLib. I doesn't depend on
> x64 macro and works on both 32 and 64 bit platforms
> //---------------------------------------------------------------------------------------------
> #ifndef quantlib_null_hpp
> #define quantlib_null_hpp
>
> #include <ql/types.hpp>
> #include <limits>
> #include <boost/type_traits.hpp>
>
> namespace QuantLib {
>
>     template <bool>
>     struct FloatingPointNull;
>
>     // null for floating poit types
>     template <>
>     struct FloatingPointNull<true> {
>         static float nullValue() {
>             return std::numeric_limits<float>::max();
>         }
>     };
>
>     // null for integer types
>     template <>
>     struct FloatingPointNull<false> {
>         static int nullValue() {
>             return std::numeric_limits<int>::max();
>         }
>     };
>
>     template <typename T>
>     class Null {
>     public:
>         Null() {}
>         operator T() const {
>             return
> T(FloatingPointNull<boost::is_floating_point<T>::value>::nullValue());
>         }
>     };
>
> }
>
> #endif
> //---------------------------------------------------------------------------------------------
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>   

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

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

They are hardwired into Longstaff-Schwartz pricing engine. I am coding
my own LS method and using QL for sanity check.

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, but also doesn't agree
with Longstaff and Schwartz recipe. The proper way to do LS is to use
all path both for calibration and pricing. EquityOption.cpp example
uses only 4096 paths for calibration and tries to price with
tolerance=0.02. I think 4096 samples are not adequate to achieve such
a small tolerance. Any thoughts?

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

[Dima <dim...@go...>]

We had this discussion before. I think the agreement was to move to 
boost optional and discourage
the usage of the Null class without removing it. One could use 
boost::optional it in the following way

void testOptional(boost::optional<double> x=boost::optional<double>());

void testOptional(boost::optional<double> x){

    if(!x){
        std::cout << "x empty" << std::endl;
    }
    else{
        std::cout << x << std::endl;
    }
}

and call it with

        testOptional();
        testOptional(1.2);






Kakhkhor Abdijalilov schrieb:
> Null class is rather confusing. We have Null<int>, Null<long>,
> Null<long long>, Null<unsigned long>, Null<unsigned int>, Null<float>,
> Null<double>, Null<long double> etc. Null<Size> is bound to conflict
> with some of those Nulls on 32 bit platforms, that is why a macro
> switch was needed. But the same macro brakes Null on 64 bit platforms.
> Boost::optional is much better and already used in QuantLib. We should
> use it instead of Null whenever possible. But working Null is still
> needed for backward compatibility.
>
> Only POD types need Null. Null<std::vector<double> > isn't a
> minefield. We can't accidentally do something like this
>
> POD_type x = Null<std::vector<double> >.
>
> It won't compile.
>
>
> Below is the null.hpp I am using with QuantLib. I doesn't depend on
> x64 macro and works on both 32 and 64 bit platforms.
>
> //---------------------------------------------------------------------------------------------
> #ifndef quantlib_null_hpp
> #define quantlib_null_hpp
>
> #include <ql/types.hpp>
> #include <limits>
> #include <boost/type_traits.hpp>
>
> namespace QuantLib {
>
>     template <bool>
>     struct FloatingPointNull;
>
>     // null for floating poit types
>     template <>
>     struct FloatingPointNull<true> {
>         static float nullValue() {
>             return std::numeric_limits<float>::max();
>         }
>     };
>
>     // null for integer types
>     template <>
>     struct FloatingPointNull<false> {
>         static int nullValue() {
>             return std::numeric_limits<int>::max();
>         }
>     };
>
>     template <typename T>
>     class Null {
>     public:
>         Null() {}
>         operator T() const {
>             return
> T(FloatingPointNull<boost::is_floating_point<T>::value>::nullValue());
>         }
>     };
>
> }
>
> #endif
> //---------------------------------------------------------------------------------------------
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>   

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

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

Null class is rather confusing. We have Null<int>, Null<long>,
Null<long long>, Null<unsigned long>, Null<unsigned int>, Null<float>,
Null<double>, Null<long double> etc. Null<Size> is bound to conflict
with some of those Nulls on 32 bit platforms, that is why a macro
switch was needed. But the same macro brakes Null on 64 bit platforms.
Boost::optional is much better and already used in QuantLib. We should
use it instead of Null whenever possible. But working Null is still
needed for backward compatibility.

Only POD types need Null. Null<std::vector<double> > isn't a
minefield. We can't accidentally do something like this

POD_type x = Null<std::vector<double> >.

It won't compile.


Below is the null.hpp I am using with QuantLib. I doesn't depend on
x64 macro and works on both 32 and 64 bit platforms.

//---------------------------------------------------------------------------------------------
#ifndef quantlib_null_hpp
#define quantlib_null_hpp

#include <ql/types.hpp>
#include <limits>
#include <boost/type_traits.hpp>

namespace QuantLib {

    template <bool>
    struct FloatingPointNull;

    // null for floating poit types
    template <>
    struct FloatingPointNull<true> {
        static float nullValue() {
            return std::numeric_limits<float>::max();
        }
    };

    // null for integer types
    template <>
    struct FloatingPointNull<false> {
        static int nullValue() {
            return std::numeric_limits<int>::max();
        }
    };

    template <typename T>
    class Null {
    public:
        Null() {}
        operator T() const {
            return
T(FloatingPointNull<boost::is_floating_point<T>::value>::nullValue());
        }
    };

}

#endif
//---------------------------------------------------------------------------------------------

Regards,
Kakhkhor Abdijalilov.

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

[Kim K. T. <kue...@vo...>]

Hi Kakhkhor,

Kakhkhor Abdijalilov schrieb:
> I compiled QuantLib with ICC for x64 target. Everything went well
> except a glitch with Null class (I reported it in my previous e-mail)
> and some issues in gaussianorthogonalpolynomial.cpp. 
many polynomials functions are already implemented in boost math 
toolkit. Can you try using these functions?

Kim

> Current
> implementations of GaussJacobiPolynomial::alpha and
> GaussJacobiPolynomial::beta have several issues.
>
> 1) On x64 targets Size is 64bit and conversion to double may generate
> a warning. For some strange reason ICC refuses to compile this line
> Real denom = (2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_+2);
> ICC bails out with an internal error. I don't know why it happens (ICC
> bug?), but casting i from Size into int fixes the problem.
> 2) Current implementation checks if num and denom variables are zero
> and then tries to use l'Hospital rule. But denom==0 can be true only
> if alpha_=0 and beta_=0 and/or i=0. In that case num=0 and l'Hospital
> rule is never used. In anyway, direct conversion of floating point
> numbers into bool is a fishy business at best. We should consider
> using fuzzy comparison instead of direct comparison, something like
> this:
>
> //-----------------------------------------------------------------------------------
>     Real GaussJacobiPolynomial::alpha(Size iIn) const {
>         int i = static_cast<int>(iIn);
>         Real num = beta_*beta_ - alpha_*alpha_;
>         Real denom = (2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_+2);
>
>         if (std::fabs(denom)<QL_EPSILON) {
>             if (std::fabs(num)<QL_EPSILON) {
>                 QL_FAIL("can't compute a_k for jacobi integration\n");
>             }
>             else {
>                 // l'Hospital
>                 num  = 2*beta_;
>                 denom= 2*(2.0*i+alpha_+beta_+1);
>                 QL_ASSERT(std::fabs(num)>QL_EPSILON, "can't compute
> a_k for jacobi integration\n");
>             }
>         }
>
>         return num / denom;
>     }
>
>     Real GaussJacobiPolynomial::beta(Size iIn) const {
>         int i = static_cast<int>(iIn);
>         Real num = 4.0*i*(i+alpha_)*(i+beta_)*(i+alpha_+beta_);
>         Real denom = (2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_)
>                    * ((2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_)-1);
>
>         if (std::fabs(denom)<QL_EPSILON) {
>             if (std::fabs(num)<QL_EPSILON) {
>                 QL_FAIL("can't compute b_k for jacobi integration\n");
>             } else {
>                 // l'Hospital
>                 num  = 4.0*i*(i+beta_)* (2.0*i+2*alpha_+beta_);
>                 denom= 2.0*(2.0*i+alpha_+beta_);
>                 denom*=denom-1;
>                 QL_ASSERT(std::fabs(num)>QL_EPSILON, "can't compute
> b_k for jacobi integration\n");
>             }
>         }
>         return num / denom;
>     }
> //-----------------------------------------------------------------------------------
>
> QL_EPSILON can be replaced with something more suitable, but at least
> it should be OK in most of the cases.
>
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>   

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

[Kim K. T. <kue...@vo...>]

Hi Kakhkhor,

Kakhkhor Abdijalilov schrieb:
> Null<Size> may not properly compile on x64 targets because. This
> happened to me  with Intel C++ compiler. 
i tested the original code in quanlib and i 've got the error that no 
constructor is provided. But this is due to the fact that the macro x64 
is not recognised by the compiler.
In fact there is no such symbol defined by the C++ standard. It depends 
on the compiler.
 See the following code snippet:

#ifdef x64
    //! template class providing a null value for a given type.
    template <>
    class Null<Size> {
      public:
        Null() {}
        operator Size() const { return Size(QL_NULL_INTEGER); }
    };
#endif

If the macro is properly set then the compile error should disappear. In 
case of visual stuio it is _M_X64. Perhaps boost has implemented an 
universal one.
> Proposal to change the Null
> class with something like this.
>   
If you really want to change the class, you should open a ticker and 
supply a patch.
But i see the problem that ur code doesnt prevent the user from writing 
code like Null<std::vector<double> >().

Kim

> //---------------------------------------------------------------------------
> #include <ql/types.hpp>
> #include <limits>
> #include <boost/type_traits.hpp>
>
> typedef double Real;
>
> template <bool>
> struct IntegerNull {
>     static int value() {
>         return std::numeric_limits<int>::max();
>     }
> };
>
> template <>
> struct IntegerNull<false> {
>     static Real value() {
>         return std::numeric_limits<Real>::max();
>     }
> };
>
> template <typename T>
> class Null {
> public:
>     Null() {}
>     operator T() const {
>         return T(IntegerNull<boost::is_floating_point<T>::value>::value());
>     }
> };
> //---------------------------------------------------------------------------
>
> Even better solution would be replace it with boost::optional but I
> guess Null is needed for backward compatibility.
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>   

Re: [Quantlib-dev] Start point for Newbie

[Tawanda G. <tg...@gm...>]

Dear Dev Null

The very first thing you can do to actually understand QuantLib enough to be
able to use and contribute is to have a purpose. I'd advise you to take your
favorite financial calculation and try to implement it in QuantLib.

Also look at the examples (including the test suite) and the code.

I am working (slowly) on a documentation for beginners. Perhaps it might
help some. It's at http://sites.google.com/site/tgwena/ It still has a long
way to go.

The second most important document to look at (first is the code) is the
documentation by Luigi at http://sites.google.com/site/luigiballabio/qlbook

(I do hope your name does not reflect on you)

On Tue, Aug 10, 2010 at 3:50 PM, Dev Null <dev...@gm...> wrote:

> Hello All,
>
> I am new to Quanlib. I would like to contribute something to QuantLib.
>
> Could you please guide me where is the start point for QuantLib?
>
> Thanks,
> Dev Null
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>


-- 
http://tgwena.blogspot.com

[Quantlib-dev] Start point for Newbie

[Dev N. <dev...@gm...>]

Hello All,

I am new to Quanlib. I would like to contribute something to QuantLib.

Could you please guide me where is the start point for QuantLib?

Thanks,
Dev Null

[Quantlib-dev] [ quantlib-Bugs-3042627 ] Bug in CMS

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

Bugs item #3042627, was opened at 2010-08-10 09:56
Message generated for change (Tracker Item Submitted) made by mandaldi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3042627&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: DILIP MANDAL (mandaldi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in CMS

Initial Comment:
I am learning myself out of curiosity and want to become a quant developer. While I was studying constant maturity swap, I found a problem while changing nominal value. The sum of caplet and floorlet price is not equal to swaplet price at a strike rate. The bug is in the calculation of swaplet. It does not account for nominal value while calculating swaplet value. It should be “Real swapletPrice = swaplet.price(vars.termStructure) +                                  nominal * swaplet.accrualPeriod() * strike * discount;” at line 452 of test-suite/cms.cpp file.
Thank you,
Dilip


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

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

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

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

I compiled QuantLib with ICC for x64 target. Everything went well
except a glitch with Null class (I reported it in my previous e-mail)
and some issues in gaussianorthogonalpolynomial.cpp. Current
implementations of GaussJacobiPolynomial::alpha and
GaussJacobiPolynomial::beta have several issues.

1) On x64 targets Size is 64bit and conversion to double may generate
a warning. For some strange reason ICC refuses to compile this line
Real denom = (2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_+2);
ICC bails out with an internal error. I don't know why it happens (ICC
bug?), but casting i from Size into int fixes the problem.
2) Current implementation checks if num and denom variables are zero
and then tries to use l'Hospital rule. But denom==0 can be true only
if alpha_=0 and beta_=0 and/or i=0. In that case num=0 and l'Hospital
rule is never used. In anyway, direct conversion of floating point
numbers into bool is a fishy business at best. We should consider
using fuzzy comparison instead of direct comparison, something like
this:

//-----------------------------------------------------------------------------------
    Real GaussJacobiPolynomial::alpha(Size iIn) const {
        int i = static_cast<int>(iIn);
        Real num = beta_*beta_ - alpha_*alpha_;
        Real denom = (2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_+2);

        if (std::fabs(denom)<QL_EPSILON) {
            if (std::fabs(num)<QL_EPSILON) {
                QL_FAIL("can't compute a_k for jacobi integration\n");
            }
            else {
                // l'Hospital
                num  = 2*beta_;
                denom= 2*(2.0*i+alpha_+beta_+1);
                QL_ASSERT(std::fabs(num)>QL_EPSILON, "can't compute
a_k for jacobi integration\n");
            }
        }

        return num / denom;
    }

    Real GaussJacobiPolynomial::beta(Size iIn) const {
        int i = static_cast<int>(iIn);
        Real num = 4.0*i*(i+alpha_)*(i+beta_)*(i+alpha_+beta_);
        Real denom = (2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_)
                   * ((2.0*i+alpha_+beta_)*(2.0*i+alpha_+beta_)-1);

        if (std::fabs(denom)<QL_EPSILON) {
            if (std::fabs(num)<QL_EPSILON) {
                QL_FAIL("can't compute b_k for jacobi integration\n");
            } else {
                // l'Hospital
                num  = 4.0*i*(i+beta_)* (2.0*i+2*alpha_+beta_);
                denom= 2.0*(2.0*i+alpha_+beta_);
                denom*=denom-1;
                QL_ASSERT(std::fabs(num)>QL_EPSILON, "can't compute
b_k for jacobi integration\n");
            }
        }
        return num / denom;
    }
//-----------------------------------------------------------------------------------

QL_EPSILON can be replaced with something more suitable, but at least
it should be OK in most of the cases.


Regards,
Kakhkhor Abdijalilov.

[Quantlib-dev] [ quantlib-Patches-3017462 ] Ziggurat Algorithm (repost)

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

Patches item #3017462, was opened at 2010-06-17 03:06
Message generated for change (Comment added) made by renorm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3017462&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: Ziggurat Algorithm (repost)

Initial Comment:
New zip file is attached. The old one had typo.

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

>Comment By: renorm (renorm)
Date: 2010-08-10 06:46

Message:
code is the same. updated comments only


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

Comment By: renorm (renorm)
Date: 2010-08-03 13:56

Message:
Added specializations of  RandomSequenceGenerator, InverseCumulativeRsg and
InverseCumulativeRng to use ZigguratGenerator. New trait
PseudoRandomZiggurat can be used with MC pricing engines.  Example program
included.

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

Comment By: renorm (renorm)
Date: 2010-06-25 07:12

Message:
I converted normal variates back into uniform 32 bit unsigned integers and
run diehard test on them. All p-values look good. No extreme values suck as
0.9999 or 0.0001. Because of large number of computed p-values  (~200), 
0.01 (or 0.99) isn't extreme.

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

Comment By: renorm (renorm)
Date: 2010-06-25 03:52

Message:
I found another bug, which didn't show up in statistical tests. The
unloaded file contains GSL implementation and Matlab file used to generate
look up tables. For some strange reason GSL implementation uses different
value for the right-most step. My implementation uses the same value as
reported in Marsaglia and Tsang (2000). If you use GSL value in the matlab
file, it fails the diagnostics step.

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

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

[Quantlib-dev] Null class bug on x64 targets

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

Null<Size> may not properly compile on x64 targets because. This
happened to me  with Intel C++ compiler. Proposal to change the Null
class with something like this.

//---------------------------------------------------------------------------
#include <ql/types.hpp>
#include <limits>
#include <boost/type_traits.hpp>

typedef double Real;

template <bool>
struct IntegerNull {
    static int value() {
        return std::numeric_limits<int>::max();
    }
};

template <>
struct IntegerNull<false> {
    static Real value() {
        return std::numeric_limits<Real>::max();
    }
};

template <typename T>
class Null {
public:
    Null() {}
    operator T() const {
        return T(IntegerNull<boost::is_floating_point<T>::value>::value());
    }
};
//---------------------------------------------------------------------------

Even better solution would be replace it with boost::optional but I
guess Null is needed for backward compatibility.

Regards,
Kakhkhor Abdijalilov.

Re: [Quantlib-dev] unit test

[Kim K. T. <kue...@vo...>]

Hi Luigi,

Luigi Ballabio schrieb:
> On Fri, 2010-07-30 at 22:50 +0200, Kim Kuen Tang wrote:
>   
> Kim,
> 	it's been a while since I've looked at the Boost unit-test framework,
> so I'm not familiar with the most recent stuff.  Would you suggest
> switching to BOOST_AUTO_TEST_CASE?  
to be honest, i wont suggest to move to the run-by-name version even the 
change is straightforward.
The extra feature that you will gain seems not worth the effort.
Or i didnt need this feature in the past. That is why i am not motivated.

What is your opinion?

Kim
> If so, would you consider writing a
> patch to do that?
>
> Luigi
>
>
>   

Re: [Quantlib-dev] unit test

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

On Fri, 2010-07-30 at 22:50 +0200, Kim Kuen Tang wrote:
> test cases in quantlib are registered using free functions instead of 
> arguments. So i am afraid that this is not possible.
> Take a look at test-suite\utilities.hpp on line 63. It uses 
> BOOST_TEST_CASE instead of BOOST_AUTO_TEST_CASE. A workaround would be u 
> just comment the tests out in file quantlibtestsuite.hpp that you dont 
> want to run.

Kim,
	it's been a while since I've looked at the Boost unit-test framework,
so I'm not familiar with the most recent stuff.  Would you suggest
switching to BOOST_AUTO_TEST_CASE?  If so, would you consider writing a
patch to do that?

Luigi


-- 

I have yet to see any problem, however complicated, which, when you 
looked at it in the right way, did not become still more complicated. 
-- Poul Anderson 

[Quantlib-dev] [ quantlib-Patches-3017462 ] Ziggurat Algorithm (repost)

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

Patches item #3017462, was opened at 2010-06-17 03:06
Message generated for change (Comment added) made by renorm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3017462&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: Ziggurat Algorithm (repost)

Initial Comment:
New zip file is attached. The old one had typo.

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

>Comment By: renorm (renorm)
Date: 2010-08-03 13:56

Message:
Added specializations of  RandomSequenceGenerator, InverseCumulativeRsg and
InverseCumulativeRng to use ZigguratGenerator. New trait
PseudoRandomZiggurat can be used with MC pricing engines.  Example program
included.

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

Comment By: renorm (renorm)
Date: 2010-06-25 07:12

Message:
I converted normal variates back into uniform 32 bit unsigned integers and
run diehard test on them. All p-values look good. No extreme values suck as
0.9999 or 0.0001. Because of large number of computed p-values  (~200), 
0.01 (or 0.99) isn't extreme.

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

Comment By: renorm (renorm)
Date: 2010-06-25 03:52

Message:
I found another bug, which didn't show up in statistical tests. The
unloaded file contains GSL implementation and Matlab file used to generate
look up tables. For some strange reason GSL implementation uses different
value for the right-most step. My implementation uses the same value as
reported in Marsaglia and Tsang (2000). If you use GSL value in the matlab
file, it fails the diagnostics step.

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

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