quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Multicurve discounting

[ED <e06...@gm...>]

ED <e06...@gm...> wrote:

>On Mon, Sep 3, 2012 at 12:19 PM, Ferdinando
>Ametrano<na...@am...>
>wrote:
>> On Mon, Sep 3, 2012 at 5:11 PM, Grześ Andruszkiewicz
>> <gan...@gm...> wrote:
>>> Does QuantLib support multicurve discounting, i.e. when you discount
>>> using one curve (OIS), but use another curve (i.e. 3M LIBOR) for
>>> determining of the cash flows? 
>> yes it does 
>
>Hi Nando,
>
>What if all you have to build your OIS curve is FFvs3M basis swaps?
>In that case you need to jointly calibrate your 3M and OIS curves, as
>they are interdependent.
>Would you have some pointers on how to do that within Quantlib?
>
>Best Regards,
>Ed

I realize the lack of an N-dimensional solver makes things harder.
However, this would probably be feasible with LM, with a modified bootstrapper... is it something someone might have tried?
Any thoughts on the feasibility?

Regards,

Ed

[Quantlib-dev] [ quantlib-Bugs-3588371 ] (with fix) error C2679: no operator .. with stlp_std::string

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

Bugs item #3588371, was opened at 2012-11-18 13:40
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3588371&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: Marcello Pietrobon (marcello-ptr)
Assigned to: Nobody/Anonymous (nobody)
Summary: (with fix) error C2679: no operator .. with stlp_std::string

Initial Comment:
vs2010 with STLPort.5.2.1 and Boost.1_52
XP SP3

error:
error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'stlpd_std::string'


this happens with the files
ql\currency.cpp (26)
ql\errors.cpp : lines 53,56,58
ql\patterns\observable.hpp : line 140

The reason is that stlport doesn't give an implicit conversion from string to c_str() when needed (but I don't know what is the current standard on this specific point).

The fixes is just to provide the c_str() member.
We cannot use a str() member because it's not given with STLPort.


So here the fixes for the different files:
ql\currency.cpp : line 26
            return out << c.code().c_str();

ql\errors.cpp : lines 53,56,58
        std::ostringstream msg;
        #ifdef QL_ERROR_FUNCTIONS
        if (function != "(unknown)")
            msg << function.c_str() << ": ";
        #endif
        #ifdef QL_ERROR_LINES
        msg << "\n  " << file.c_str() << "(" << line << "): \n";
        #endif
        msg << message.c_str();
        return msg.str();


ql\patterns\observable.hpp : line 140
        QL_ENSURE(successful,
                  "could not notify one or more observers: " << errMsg.c_str() );




Here is the full report for one file:
1>D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/patterns/observable.hpp(140): error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'stlpd_std::string' (or there is no acceptable conversion)
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(297): could be 'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<char,stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(304): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(311): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,signed char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(318): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,unsigned char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(325): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<char,stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(332): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(339): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const signed char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(346): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const unsigned char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(78): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ostream<_CharT,_Traits> &(__cdecl *)(stlpd_std::basic_ostream<_CharT,_Traits> &))'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(79): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ostream<_CharT,_Traits>::__ios_base_fn)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(80): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ios<_CharT,_Traits> &(__cdecl *)(stlpd_std::basic_ios<_CharT,_Traits> &))'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(101): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_streambuf<_CharT,_Traits> *)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(104): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned char)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(106): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(short)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(107): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned short)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(108): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(int)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(115): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(size_t)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(117): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(long)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(118): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned long)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(120): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(__int64)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(121): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned __int64)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(123): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(float)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(124): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(double)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(126): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(long double)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(128): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(const void *)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(130): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(bool)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          while trying to match the argument list '(stlpd_std::basic_ostream<_CharT,_Traits>, stlpd_std::string)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]



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

>Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-19 02:12

Message:
Thanks for the report, but I'm a bit confused.  A statement like "out <<
c.code()" isn't expected to trigger a conversion to C string; it just
invokes operator << for std::string, which is defined by the standard.  Do
you have any idea why STLPort doesn't define it?

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

Comment By: Marcello Pietrobon (marcello-ptr)
Date: 2012-11-18 13:44

Message:
I must add that probably this error comes with STLPort only
The fix should be valid also without STLPort
so I wouldn't surround the fixes with the condition:
#ifdef _STLPORT_VERSION
#endif

By doing this the fixes would be like, of course:

ql\currency.cpp : line 26
#ifdef _STLPORT_VERSION
return out << c.code().c_str();
#else
return out << c.code();
#endif



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

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

Re: [Quantlib-dev] CDS last period

[<ja...@fr...>]

Peter, hi, apologies for the long delay, too many hobbies...

The changes you propose on the cds work fine for the bootstrapping of the probabilities but theres a problem when using the cds constructor to instantiate a contract position that way (as opposed to be cds from a helper class): tying a date member at construction time to the (volatile) evaluation date would give problems since the contract characteristics would change on different dates. If we were loading these positions from a database/worksheet that would have undesired results, if the cds were static objects we can only create them on that specific date. 
The helpers are already relative date helpers to achieve that behaviour (by recreating the cds).

I have modified the upfront and accrual rebate payments to be separate cashflows and checked for null pointers to determine if they apply.
Have a look and if you want you could merge the changes with yours in your GitHub repo and see what other people here think.

Also, is there a way the 'includeLastDay' option could be set up in the base DayCounter::Impl  (false by default) and an extra method 'setToIncludeLastDay' in the concrete dayCtrs (called then at the leg creation). Or something along the lines of moving it to a more generic level, to avoid coding it for every dayCounter

Best regards
Pepe


PS1
These are the tests I run against Mrkit data to check things are working (moving the date up and down a 20thIMM is a good idea). If someone has other test (e.g. Bloombrg) it would be nice to see them.
Testing the curve for US CDS in EUR these are the values in QL and Mrkit for the default probabilities. Some tenors are missing in the bootstrapping of the YTS I have been using:

            QL               mkit        QL(no rebate)
6M        0.0013962        0.001391        0.0015124
1Y        0.0024018        0.002396        0.0025179
2Y        0.0066991        0.006683        0.0068754
3Y        0.0128463        0.012795        0.0130785
4Y        0.0227410        0.022554        0.0230541
5Y        0.0357163        0.035221        0.0361139
7Y        0.0610696        0.059787        0.0615613
10Y       0.1036803        0.100268        0.1042708
15Y       0.1578319        0.152918        0.1584299
20Y       0.1948182        0.192336        0.1953589


As expected the rebate inclusion improves the short term figures (I placed myself on October 10th). Theres still a small discrepancy on the long term tenors; I guess it comes from a different treatment of the YTS
This is using mrkit calculator so these are running only converted quotes ('composite') but another test is to use the tick quotes and, since mrkit gives the conventional alongside the upfront quote on those, test the conventional conversion. The agreement here is within 1bp, this is very good and it is (I believe) because this test has less uncertainty on whether I am doing exactly the same thing.
Yet another test I came about is to compare market composite quotes on bonds, there one has the Zspread from the bond price and the one computed from the CDS. Pricing the risky bond and the composite CDS curve with QL will give you those figures. The agreement I get is within 1% difference, I am not too worried about that since this is more complex a test and I might have done things differently to the way mrkit does.

PS2
Another comment to the cds engines I would make is that they are unable to provide a fair spread for a zero coupon CDS, this would need bypassing the coupon methods when NPV-ing the leg. 
Other points for the CDS:
-default lookback not accounted for (the 90 days thing) Important only for risk management, irrelevant for pricing.
-not tied to issuer. Relevant to risk management (no observability mechanism for a jump to default metric).

[Quantlib-dev] [ quantlib-Bugs-3588373 ] (with fix) warning C4244: std::ostream::setw() with STLPort

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

Bugs item #3588373, was opened at 2012-11-18 13:55
Message generated for change (Tracker Item Submitted) made by marcello-ptr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3588373&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: Marcello Pietrobon (marcello-ptr)
Assigned to: Nobody/Anonymous (nobody)
Summary: (with fix) warning C4244: std::ostream::setw() with STLPort

Initial Comment:
vs2010 with STLPort.5.2.1 and Boost.1_52
XP SP3

error:
ql/math/array.hpp(634): warning C4244: 'argument' : conversion from 'stlpd_std::streamsize' to 'int', possible loss of data
ql/math/array.hpp(635): warning C4244: 'argument' : conversion from 'stlpd_std::streamsize' to 'int', possible loss of data 
ql/math/matrix.hpp(584): warning C4244: 'argument' : conversion from 'stlpd_std::streamsize' to 'int', possible loss of data

The fix consists in providing a cast to int because required by STLPort  std::ostream::setw() when compiling with vs2010 (and quite probably all others of versions of Microsoft compilers)

So the fixes are:

ql\math\array.hpp : lines 634, 635
#ifdef _STLPORT_VERSION
            for (Size n=0; n<a.size()-1; ++n)
                out << std::setw((int)width) << a[n] << "; ";
            out << std::setw((int)width) << a.back();
#else
            for (Size n=0; n<a.size()-1; ++n)
                out << std::setw(width) << a[n] << "; ";
            out << std::setw(width) << a.back();
#endif



ql\math\matrix.hpp : lines 584
#ifdef _STLPORT_VERSION
            for (Size j=0; j<m.columns(); j++)
                out << std::setw((int)width) << m[i][j] << " ";
#else
            for (Size j=0; j<m.columns(); j++)
                out << std::setw(width) << m[i][j] << " ";
#endif



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

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

[Quantlib-dev] [ quantlib-Bugs-3588371 ] (with fix) error C2679: no operator .. with stlp_std::string

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

Bugs item #3588371, was opened at 2012-11-18 13:40
Message generated for change (Comment added) made by marcello-ptr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3588371&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: Marcello Pietrobon (marcello-ptr)
Assigned to: Nobody/Anonymous (nobody)
Summary: (with fix) error C2679: no operator .. with stlp_std::string

Initial Comment:
vs2010 with STLPort.5.2.1 and Boost.1_52
XP SP3

error:
error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'stlpd_std::string'


this happens with the files
ql\currency.cpp (26)
ql\errors.cpp : lines 53,56,58
ql\patterns\observable.hpp : line 140

The reason is that stlport doesn't give an implicit conversion from string to c_str() when needed (but I don't know what is the current standard on this specific point).

The fixes is just to provide the c_str() member.
We cannot use a str() member because it's not given with STLPort.


So here the fixes for the different files:
ql\currency.cpp : line 26
            return out << c.code().c_str();

ql\errors.cpp : lines 53,56,58
        std::ostringstream msg;
        #ifdef QL_ERROR_FUNCTIONS
        if (function != "(unknown)")
            msg << function.c_str() << ": ";
        #endif
        #ifdef QL_ERROR_LINES
        msg << "\n  " << file.c_str() << "(" << line << "): \n";
        #endif
        msg << message.c_str();
        return msg.str();


ql\patterns\observable.hpp : line 140
        QL_ENSURE(successful,
                  "could not notify one or more observers: " << errMsg.c_str() );




Here is the full report for one file:
1>D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/patterns/observable.hpp(140): error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'stlpd_std::string' (or there is no acceptable conversion)
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(297): could be 'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<char,stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(304): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(311): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,signed char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(318): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,unsigned char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(325): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<char,stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(332): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(339): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const signed char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(346): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const unsigned char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(78): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ostream<_CharT,_Traits> &(__cdecl *)(stlpd_std::basic_ostream<_CharT,_Traits> &))'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(79): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ostream<_CharT,_Traits>::__ios_base_fn)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(80): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ios<_CharT,_Traits> &(__cdecl *)(stlpd_std::basic_ios<_CharT,_Traits> &))'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(101): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_streambuf<_CharT,_Traits> *)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(104): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned char)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(106): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(short)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(107): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned short)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(108): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(int)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(115): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(size_t)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(117): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(long)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(118): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned long)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(120): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(__int64)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(121): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned __int64)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(123): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(float)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(124): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(double)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(126): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(long double)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(128): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(const void *)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(130): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(bool)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          while trying to match the argument list '(stlpd_std::basic_ostream<_CharT,_Traits>, stlpd_std::string)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]



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

>Comment By: Marcello Pietrobon (marcello-ptr)
Date: 2012-11-18 13:44

Message:
I must add that probably this error comes with STLPort only
The fix should be valid also without STLPort
so I wouldn't surround the fixes with the condition:
#ifdef _STLPORT_VERSION
#endif

By doing this the fixes would be like, of course:

ql\currency.cpp : line 26
#ifdef _STLPORT_VERSION
return out << c.code().c_str();
#else
return out << c.code();
#endif



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

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

[Quantlib-dev] [ quantlib-Bugs-3588371 ] (with fix) error C2679: no operator .. with stlp_std::string

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

Bugs item #3588371, was opened at 2012-11-18 13:40
Message generated for change (Tracker Item Submitted) made by marcello-ptr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3588371&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: Marcello Pietrobon (marcello-ptr)
Assigned to: Nobody/Anonymous (nobody)
Summary: (with fix) error C2679: no operator .. with stlp_std::string

Initial Comment:
vs2010 with STLPort.5.2.1 and Boost.1_52
XP SP3

error:
error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'stlpd_std::string'


this happens with the files
ql\currency.cpp (26)
ql\errors.cpp : lines 53,56,58
ql\patterns\observable.hpp : line 140

The reason is that stlport doesn't give an implicit conversion from string to c_str() when needed (but I don't know what is the current standard on this specific point).

The fixes is just to provide the c_str() member.
We cannot use a str() member because it's not given with STLPort.


So here the fixes for the different files:
ql\currency.cpp : line 26
            return out << c.code().c_str();

ql\errors.cpp : lines 53,56,58
        std::ostringstream msg;
        #ifdef QL_ERROR_FUNCTIONS
        if (function != "(unknown)")
            msg << function.c_str() << ": ";
        #endif
        #ifdef QL_ERROR_LINES
        msg << "\n  " << file.c_str() << "(" << line << "): \n";
        #endif
        msg << message.c_str();
        return msg.str();


ql\patterns\observable.hpp : line 140
        QL_ENSURE(successful,
                  "could not notify one or more observers: " << errMsg.c_str() );




Here is the full report for one file:
1>D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/patterns/observable.hpp(140): error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'stlpd_std::string' (or there is no acceptable conversion)
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(297): could be 'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<char,stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(304): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(311): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,signed char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(318): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,unsigned char)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(325): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<char,stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(332): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(339): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const signed char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(346): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::operator <<<stlpd_std::char_traits<char>>(stlpd_std::basic_ostream<_CharT,_Traits> &,const unsigned char *)' [found using argument-dependent lookup]
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(78): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ostream<_CharT,_Traits> &(__cdecl *)(stlpd_std::basic_ostream<_CharT,_Traits> &))'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(79): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ostream<_CharT,_Traits>::__ios_base_fn)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(80): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_ios<_CharT,_Traits> &(__cdecl *)(stlpd_std::basic_ios<_CharT,_Traits> &))'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(101): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(stlpd_std::basic_streambuf<_CharT,_Traits> *)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(104): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned char)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(106): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(short)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(107): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned short)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(108): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(int)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(115): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(size_t)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(117): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(long)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(118): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned long)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(120): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(__int64)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(121): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(unsigned __int64)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(123): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(float)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(124): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(double)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(126): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(long double)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(128): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(const void *)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_ostream.h(130): or       'stlpd_std::basic_ostream<_CharT,_Traits> &stlpd_std::basic_ostream<_CharT,_Traits>::operator <<(bool)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]
1>          while trying to match the argument list '(stlpd_std::basic_ostream<_CharT,_Traits>, stlpd_std::string)'
1>          with
1>          [
1>              _CharT=char,
1>              _Traits=stlpd_std::char_traits<char>
1>          ]



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

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

Re: [Quantlib-dev] Why doesn't there exist a QuantLib Leg Hierachy?

[Sebastian P. <Seb...@gm...>]

Hi Jan,

you are right that deriving from a STL container may be a bad idea. This
problem can be circumvented by redefining the Leg (Class) via composition. 

What I'm trying to do is (somehow) making a snapshot of a QuantLib
environment, e.g. a swap, including legs, pricing engines, market data
objects,... . This snapshot should contain enough information to reopen it
in an Excel session. In the current QL Leg design the leg type informations
are lost after passing (casting) it into a swap instrument. 
For example if you want to "export" a simple QL swap including an iborLeg
and a FixedRateLeg into Excel a nice result would be a call to three QLXL
functions (either just in single cells or including some fancy parameter
boxes): qlswap, qlIborLeg, qlFixedRateLeg. But because the swap has lost the
information of the underlying leg types this is difficult to achieve. 

I imagine that leg type information could also be helpful in other
algorithmic tasks.    

Regards,
Sebastian
-- 
View this message in context: http://old.nabble.com/Why-doesn%27t-there-exist-a-QuantLib-Leg-Hierachy--tp34689442p34694954.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] [ quantlib-Bugs-3588369 ] (with fix) vs2010 warning C4005: 'M_PI' : macro redefinition

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

Bugs item #3588369, was opened at 2012-11-18 13:11
Message generated for change (Tracker Item Submitted) made by marcello-ptr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3588369&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: Marcello Pietrobon (marcello-ptr)
Assigned to: Nobody/Anonymous (nobody)
Summary: (with fix) vs2010 warning C4005: 'M_PI' : macro redefinition

Initial Comment:
vs2010 with STLPort.5.2.1 and Boost.1_52
XP SP3

I get the annoying warnings:
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/math.h(632): warning C4005: 'M_PI' : macro redefinition
1>          D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/mathconstants.hpp(54) : see previous definition of 'M_PI'
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/math.h(639): warning C4005: 'M_SQRT1_2' : macro redefinition
1>          D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/mathconstants.hpp(102) : see previous definition of 'M_SQRT1_2'

while compiling ql/utilities/dataparser.cpp
I didn't go to find out if the problem appears without STLPort too,

In syntesis this is what appears as output build with the option 'show includes':
1>  Note: including file: D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/utilities/dataparsers.hpp
1>  Note: including file:  D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/time/date.hpp
1>  Note: including file:   D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/time/period.hpp
1>  Note: including file:    D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/time/frequency.hpp
1>  Note: including file:     D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/qldefines.hpp
1>  Note: including file:      D:\Projs\Libraries\Bsd\Boost\Boost-Active\boost/config.hpp
1>  Note: including file:       D:\Projs\Libraries\Bsd\Boost\Boost-Active\boost/config/select_stdlib_config.hpp
1>  Note: including file:        d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\cstddef
1>  Note: including file:         d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_prolog.h
1>  Note: including file:          d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/debug/_debug.h
1>  Note: including file:           d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_threads.h
1>  Note: including file:            d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_cstdlib.h
1>  Note: including file:             d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_cmath.h
1>  Note: including file:              C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/cmath
1>  Note: including file:               d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\math.h
1>  Note: including file:                C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/math.h
	// ** defined here **
1>  Note: including file: D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/utilities/null.hpp
1>  Note: including file: D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/time/period.hpp
1>  Note: including file: D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/errors.hpp
1>  Note: including file: D:\Projs\Libraries\Bsd\Boost\Boost-Active\boost/lexical_cast.hpp
...
1>  Note: including file:  D:\Projs\Libraries\Bsd\Boost\Boost-Active\boost/math/special_functions/sign.hpp
...
1>  Note: including file:   D:\Projs\Libraries\Bsd\Boost\Boost-Active\boost/math/special_functions/math_fwd.hpp
...
1>  Note: including file:    D:\Projs\Libraries\Bsd\Boost\Boost-Active\boost/math/policies/policy.hpp
...
1>  Note: including file:     d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\math.h
1>  Note: including file:      d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/_cprolog.h
1>  Note: including file:       d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/config/_prolog.h
1>  Note: including file:        d:\Projs\Libraries\BSD\STLPort\STLport-Active\stlport\stl/config/_warnings_off.h
1>  Note: including file:      C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/math.h
1>C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/math.h(643): warning C4005: 'M_SQRT1_2' : macro redefinition
1>          D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql/mathconstants.hpp(103) : see previous definition of 'M_SQRT1_2'


Analysis:
	C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/math.h
	is included twice, but the first time M_PI doesnt get defined
	then D:\Projs\Libraries\Public\QuantLib\QuantLib-Active\ql\mathconstants.hpp is included
	and then again (the 2nd time)
	C:\Program Files\Microsoft Visual Studio 10.0\VC\include\../include/math.h
	but this time with the macro _USE_MATH_DEFINES defined (see note in math.h)
	and here we get the warning message.

Solution:
	In ql\utilities\dataparsers.cpp
	before 
	#include <ql/utilities/dataparsers.hpp>
	add the following lines:
#ifdef _MSC_VER // MP-
#  define _USE_MATH_DEFINES
//#  include <math.h> // not necessary
#endif // MP-

To #include <math.h> is not necessary because dataparsers.hpp indirectly already includes it
	before ql\mathconstants.hpp gets included.





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

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

Re: [Quantlib-dev] Why doesn't there exist a QuantLib Leg Hierachy?

[Jan L. D. <du...@ou...>]

I can't speak for the devs, but one issue with your suggestion as written is that it is generally considered a Bad Idea to derive from STL containers (no virtual destructors, e.g.). More to the point, a Leg should properly be a collection of (possibly heterogeneous) cash flows; the "kind" or "type" of leg you are dealing with is determined by properties of the cash flows that it contains. Any other properties you might like a Leg to have depend on its context, i.e., to the instrument (swap in your case) to which it belongs. So really, the design decision was to split the work between the CashFlow hierarchy and the Instrument hierarchy. There is no need to make the Leg class "smarter".

In QuantLibXL, can create new (possibly complicated) constructors (qlIborLeg and qlFixedRateLeg, say) which stores the type of leg you want in the object repository. You can then plug these Leg objects into the IborLeg and FixedRateLeg slots of your swap constructor.

JLD


> Date: Fri, 16 Nov 2012 09:27:37 -0800
> From: Seb...@gm...
> To: qua...@li...
> Subject: [Quantlib-dev]  Why doesn't there exist a QuantLib Leg Hierachy?
>
>
> Hello,
>
> I've tried to "reconstruct" a QuantLib swap object in another environment
> (QuantLib Excel). The idea was to use the swap properties (including private
> ones if necessary) to construct adequate ObjectHandler::ValueObjects, which
> can be used to "design" the objects in an excel workbook.
>
> After some coding I've recognized that this seems to be impossible (or at
> least harder than expected) in the current QuantLib environment. The reason
> is that there is no QuantLib Leg Hierachy in the library. Each Leg is just a
> vector of cashflow pointers and it is hard to differentiate if a leg was
> intended to be an iborleg, a fixedrateleg etc.
> For example you use the "helper class" fixedrateleg to (temporarely) create
> a fixedrateleg. As soon, as you pass it to a swap this fixedrateleg is just
> casted to a vector of cashflowpointers, loosing the information what it was
> intended to be. I'm wondering why this "design" was choosen.
> I suppose that a structure similar to that:
>
> typedef std::vector<boost::shared_ptr<CashFlow>> Leg;
>
> // concrete FixedRateLeg class
> class FixedRateLeg : public Leg {
> ....
> }
>
> //! helper class building a FixedRateLeg
> class MakeFixedRateLeg {
>       // similar to current FixedRateLeg helper class
>       // cast operator on new FixedRateLeg Class instead of Leg:
>       // operator FixedRateLeg() const;
> }
>
> would be in some circumstances superior to the current structure. This is
> (for example) the way the swap class (with its child vanillaswap) is
> organized. Is there a special reason that this "thing" Leg did not get an
> objecthierachy in QuantLib?
>
> Regards
> Sebastian
>
>
>
> --
> View this message in context: http://old.nabble.com/Why-doesn%27t-there-exist-a-QuantLib-Leg-Hierachy--tp34689442p34689442.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev 		 	   		  

[Quantlib-dev] Why doesn't there exist a QuantLib Leg Hierachy?

[Sebastian P. <Seb...@gm...>]

Hello,

I've tried to "reconstruct" a QuantLib swap object in another environment
(QuantLib Excel). The idea was to use the swap properties (including private
ones if necessary) to construct adequate ObjectHandler::ValueObjects, which
can be used to "design" the objects in an excel workbook.  

After some coding I've recognized that this seems to be impossible (or at
least harder than expected) in the current QuantLib environment. The reason
is that there is no QuantLib Leg Hierachy in the library. Each Leg is just a
vector of cashflow pointers and it is hard to differentiate if a leg was
intended to be an iborleg, a fixedrateleg etc. 
For example you use the "helper class" fixedrateleg to (temporarely) create
a fixedrateleg. As soon, as you pass it to a swap this fixedrateleg is just
casted to a vector of cashflowpointers, loosing the information what it was
intended to be. I'm wondering why this "design" was choosen. 
I suppose that a structure similar to that:

typedef std::vector<boost::shared_ptr<CashFlow> > Leg;

// concrete FixedRateLeg class
class FixedRateLeg : public Leg {
....
}

//! helper class building a FixedRateLeg
class MakeFixedRateLeg {
	// similar to current FixedRateLeg helper class
	// cast operator on new FixedRateLeg Class instead of Leg:
	// operator FixedRateLeg() const;
}

would be in some circumstances superior to the current structure. This is
(for example) the way the swap class (with its child vanillaswap) is
organized. Is there a special reason that this "thing" Leg did not get an
objecthierachy in QuantLib?

Regards
Sebastian
   


-- 
View this message in context: http://old.nabble.com/Why-doesn%27t-there-exist-a-QuantLib-Leg-Hierachy--tp34689442p34689442.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] Clarification: AsianOption in the middle of its path

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

Hi Eric,
    I've had a look at the code and it seems ok.  You're using the
runningAccumulator and pastFixings as required.  The fixing dates
would work either way (just the remaining ones or all of them) since
the engine discards past fixing dates during calculation.  If the
option defined an inspector for the fixing dates, we could have a
philosophical argument until the cows come home about what we should
want it to show.  But there's no such inspector right now, so we can
save some time :)

Regards,
    Luigi


On Fri, Nov 9, 2012 at 8:05 PM, Eric Butter <em...@er...> wrote:
> Hi everyone,
>
> I have been calculating NPV and Greeks at intermediate points along the path
> of an asian option; I want to throw my technique into RQuantLib -- but first
> I want some validation that what I am doing is kosher.  :)
>
> Right now I am using DiscreteAveragingAsianOption and
> AnalyticDiscreteGeometric...Engine, pre-setting the runningAccumulator to
> the product of the previous prices, pastFixings to the number of previous
> time points, fixingDates to only the **remaining** time points.
>
> I have been getting answers that look good to me, but does 1. hacking the
> fixtures arguments this way and 2. only using the remaining fixing dates get
> an a.okay from the guys who designed this in the first place?  Is there a
> better way to do this?
>
> Thanks for all the time you have put into this useful software,
>
> Eric
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] QuantLib-dev Digest, Vol 78, Issue 3

[Theo B. <tb...@ao...>]

Hi,


I want to price an European Option on a forward contract, so I can create a forward contract using forward in Instrument ie forward.hpp/forward.cpp and then use black formula to price.


What does forwardengine.hpp do as from snippet below, the forwardprocess is constructed using spot,dividendYield and risk free rate, but my forward process is driftless?


Basically what I am getting at is I want to price an option on a commodity forward contract.


        boost::shared_ptr<GeneralizedBlackScholesProcess> fwdProcess(
                       new GeneralizedBlackScholesProcess(spot, dividendYield,
                                                          riskFreeRate,
                                                          blackVolatility));


Also I dont see the use of blackformula in the unit test.


There is a forwardoption in the unit test ie.



  struct ForwardOptionData {
        Option::Type type;
        Real moneyness;
        Real s;          // spot
        Rate q;          // dividend
        Rate r;          // risk-free rate
        Time start;      // time to reset
        Time t;          // time to maturity
        Volatility v;    // volatility
        Real result;     // expected result
        Real tol;        // tolerance
    };





which uses which is using s,q, and r to form forward price and then use blacksholes merton process to price option on forwards, its not using,forward.hpp/forward.cpp and black formula. 


Regards


Theo


-----Original Message-----
From: quantlib-dev-request <qua...@li...>
To: quantlib-dev <qua...@li...>
Sent: Wed, 14 Nov 2012 9:50
Subject: QuantLib-dev Digest, Vol 78, Issue 3


Send QuantLib-dev mailing list submissions to
	qua...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/quantlib-dev
or, via email, send a message with subject or body 'help' to
	qua...@li...

You can reach the person managing the list at
	qua...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of QuantLib-dev digest..."


Today's Topics:

   1. Black Vega (Peter Caspers)
   2. [ quantlib-Patches-3582579 ] Differential Evolution
      improvement (SourceForge.net)
   3. Re: Garch11 in Quantlib (Luigi Ballabio) (Luigi Ballabio)
   4. Re: Multicurve discounting (ED)
   5. [ quantlib-Patches-3102452 ] GARCH calibration (SourceForge.net)


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

Message: 1
Date: Mon, 12 Nov 2012 11:49:05 +0100
From: Peter Caspers <pca...@gm...>
Subject: [Quantlib-dev] Black Vega
To: qua...@li...
Message-ID:
	<CAC...@ma...>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

in blackformula.cpp , blackFormulaStdDevDerivative(...) the limit case
stdDev == 0.0 seems to be treated false, lines 307ff

if (stdDev==0.0) {
            if (forward>strike)
                return discount * forward;
            else
                return 0.0;
        }

should be

if (stdDev==0.0) return 0.0;

because \phi(x) -> 0 whenever |x| -> \infty, right ?

Thanks
Peter
-------------- next part --------------
An HTML attachment was scrubbed...

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

Message: 2
Date: Mon, 12 Nov 2012 07:24:08 -0800
From: SourceForge.net <no...@so...>
Subject: [Quantlib-dev] [ quantlib-Patches-3582579 ] Differential
	Evolution	improvement
To: SourceForge.net <no...@so...>
Message-ID:
	<mai...@li...>
Content-Type: text/plain; charset=UTF-8

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that 
appeared in QuantLib HEAD source code recently. I decided to improve it 
slightly. I took performance very seriously as the DE implementation should be 
light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that 
defines the behavior of the algorithm. The reason is that it makes the 
implementation more flexible. There are dozens of DE variants... I tried to be 
in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I 
mentioned, the number of variations of the DE algorithm is huge. This approach 
makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself 
- this is why additional upperBound and lowerBound functions were added to 
Constraint object. NonhomogeneousBoundaryConstraint to define box constraints 
was added too. The other aspect is if the bounds are going to be valid for 
emerging populations - practical advise is that it should as for certain 
parameters, new populations seem to diverge. On the other hand, it adds some 
additional overhead. General observation is that it is always possible to 
improve performance for a given objective function. One needs to find 
appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential 
(the name for the first crossover type comes from the fact that assuming 
binomial crossover, the number of mutants taken into account in a given 
population converges in distribution to normal variable for growing problem 
size)
4) There are 6 methods available in this implementation. However, it is possible 
to go further and implement various base element types, differences of a given 
size, various weights distributions for the differences etc. Implemented 
approaches are the most common used in practice as the more complicated 
recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for 
which the objective function value is 8.86549 which is significantly lower than 
12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 
0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 
0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; 
-0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; 
-0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in 
several local minimas - most of them in [10;15] range. Further investigation is 
needed.
6) I have problem with Griewangk function too. I am not able to find fully 
successful method although the objective function value oscillated around 0.1 
which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only 
reason I set it as default method to be used. Hope it helps. I am happy to 
answer your questions. In case my patch does not work properly, please use 
changed files directly. 

Kind regards,
Mateusz Kapturski 

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-12 07:24

Message:
Hi Mateusz,

good that the adaptive method seems to add some value to your implemetation
;-)

When I run the test cases, 4 out of 5 pass now. However, for the
ModFourthDeJong objective function, I get 12.0945 instead of your 10.964.
Maybe this is due to the fact that I'm using a different boost version
(1.47.0) and that boost's MT impementation has changed, but I don't know if
it's worth investgating on this issue or rather exclude the ModFourthDeJong
test case for now (because both values are valid).


Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-11 13:35

Message:
Hi Ralph, Luigi

you were right - self adapting method is quite successful. I have already
added it to my implementation. All tests are passed now. I would be
grateful if you double check my results. I think this is a stable version
that can go to QL trunk. QL users have much more options now.

Recent changes/remarks:
1) Crossover self-adaptation is a separate option - it was very easy to
implement it that way. 
2) User  can decide if DE should use fixed seed or not (as discussed
earlier)
3) Adaptation is performed on the population member basis as stated in the
paper.
4) Additional rotation was added to the self-adaptive method to improve its
performance.
5) Extracted some logic into separate private methods.
6) Original Griewangk function is usually defined on [-600, 600]^n box and
my DE implementation is successful on this search domain. 

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-08 00:23

Message:
Hi Mateusz,

thank you for your reply. The adaptive method can be found here (section
V):

Brest, J. et al., 2006,
"Self-Adapting Control Parameters in Differential Evolution: A Comparative
Study on Numerical  Benchmark Problems."
( A link which worked for me is
http://150.214.190.154/docencia/sf1/Brest06.pdf)

And yes, the adaptive method always found the minimum of the Griewanck
function when I played around with it.


Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-07 14:44

Message:
Hi Ralph,

thank you for your remarks.

1) Fixing the seed for reproducibility is a great idea. I simply forgot to
do it. I tested my implementation against current time as seed to be
perfectly sure that results are reliable. I added an optional config param.
One may want "increase randomness" using the useFixedSeed_=false parameter.
Therefore, both options are available now.
2) This is a philosophical aspect. I used Boost as it was just easier for
me and I find it a reliable tool. It does not add external dependency as QL
already uses Boost libraries. The question is if there is value added if we
change it. In my view - not significant. If you would like to change it,
just go for it.
3) I see your point now with respect to ModFourthDeJong. My random results
were connected with your first observation - after fixing the seed, I
obtained stable minimum equal to 10.409792. I have already amended the test
case.
4) The adaptive method is not implemented yet but it can be easily added.
Could you provide more details on the method as I could not find it in the
literature. The most important aspects are: how many differences are taken
into account and how are weights applied to it? Was crossover important
aspect for this method? And last practical question: Was the adaptive
strategy successful for every chosen seed in your implementation? Griewangk
objective function is probably the last major issue to resolve now.

Thanks
Mateusz

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-07 00:42

Message:
Hi Mateusz,

I have some remarks/questions concerning your DE implementation:

1. You are using time(0) for the seed in the generation of the initial
population (differentialevolution.cpp, line 27). Wouldn't a fix seed be
better for reproducability, in the sense that the same data yield the same
result?
2. As a part of QuantLib, shouldn't one choose QuantLib's random number
generator instead of boost's?
3. For the ModFourthDeJong you mention that you find a lower minimum than
the previous implementation. But that's not the point. If you take a look
at the function, you see the uniform random part, i.e. the functional
minimum is f(0) <= 30*Expectation(uniform) = 15. Therefore you'll get
different realizations for different random numbers, which is ok as long as
the minimum found is below 15.
4. For the Griewangk function, the adaptive method in the current DE
implementation succeeds to find the minimum f(0) = 0. Is the adaptive
method implemented (or implementable) in your code as well?


Thanks,
Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-06 16:15

Message:
Hi Luigi, 

I have a habit of constant auto forrmatting when coding in Eclipse...
Unfortunately, the autoformat profile cannot be adjusted to QL style
easily. I removed unnecessary changes in order to make the patch more
readable. 

Mateusz

BTW. Is it possible to use other external tool (e.g. vim or emacs) to
format source code file in line with QL style? First line in each QL file
specifies autoformat options, doesn't it?

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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



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

Message: 3
Date: Tue, 13 Nov 2012 13:25:29 +0100
From: Luigi Ballabio <lui...@gm...>
Subject: Re: [Quantlib-dev] Garch11 in Quantlib (Luigi Ballabio)
To: Slava Mazur <sm...@li...>
Cc: "qua...@li..."
	<qua...@li...>
Message-ID:
	<CAJ...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

Done.  Apologies for the delay.

Luigi

On Tue, May 15, 2012 at 3:12 PM, Slava Mazur <sm...@li...> wrote:
> Check it out:
>
> http://sourceforge.net/tracker/?func=detail&aid=3102452&group_id=12740&atid=312740
>
> Submitted there on Nov 2010.
>
> Cheers,
>
> Slava Mazur
>
>
> Message: 5
> Date: Mon, 14 May 2012 13:25:47 -0400
> From: Yue Zhao <yzh...@gm...>
> Subject: [Quantlib-dev] Garch11 in Quantlib
> To: QuantLib Dev <Qua...@li...>
> Message-ID:
>         <CAA...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> My question might be silly. I am using the Garch11 class in QL, but I didn't 
see how to calibrate this model. Does anyone know how do calibration?
>
> Best
>
> Yue
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 6
> Date: Tue, 15 May 2012 09:35:10 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Garch11 in Quantlib
> To: Yue Zhao <yzh...@gm...>
> Cc: QuantLib Dev <Qua...@li...>
> Message-ID:
>         <CAJ...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>     at this time there's no code for calibration in the library (the
> Garch11 class declares a calibrate method, but it's empty). If anyone wants to 
contribute it, I'll be glad to add it to the repository.
>
> Luigi
>
> On Mon, May 14, 2012 at 7:25 PM, Yue Zhao <yzh...@gm...> wrote:
>> My question might be silly. I am using the Garch11 class in QL, but I
>> didn't see how to calibrate this model. Does anyone know how do calibration?
>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat 
landscape has changed and how IT managers can respond. Discussions will include 
endpoint security, mobile security and the latest in malware threats. 
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> ------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> End of QuantLib-dev Digest, Vol 72, Issue 5
> *******************************************
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev



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

Message: 4
Date: Tue, 13 Nov 2012 20:33:07 -0500
From: ED <e06...@gm...>
Subject: Re: [Quantlib-dev] Multicurve discounting
To: qua...@li..., na...@am...
Message-ID: <50A...@gm...>
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 3, 2012 at 12:19 PM, Ferdinando Ametrano<na...@am...>
wrote:
> On Mon, Sep 3, 2012 at 5:11 PM, Grze? Andruszkiewicz
> <gan...@gm...> wrote:
>> Does QuantLib support multicurve discounting, i.e. when you discount
>> using one curve (OIS), but use another curve (i.e. 3M LIBOR) for
>> determining of the cash flows? 
> yes it does 

Hi Nando,

What if all you have to build your OIS curve is FFvs3M basis swaps?
In that case you need to jointly calibrate your 3M and OIS curves, as
they are interdependent.
Would you have some pointers on how to do that within Quantlib?

Best Regards,
Ed



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

Message: 5
Date: Tue, 13 Nov 2012 04:21:56 -0800
From: SourceForge.net <no...@so...>
Subject: [Quantlib-dev] [ quantlib-Patches-3102452 ] GARCH calibration
To: SourceForge.net <no...@so...>
Message-ID:
	<mai...@li...>
Content-Type: text/plain; charset=UTF-8

Patches item #3102452, was opened at 2010-11-03 13:16
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3102452&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: Accepted
Priority: 5
Private: No
Submitted By: Slava Mazur (shlagbaum)
>Assigned to: Luigi Ballabio (lballabio)
Summary: GARCH calibration

Initial Comment:
Re-designed GARCH volatility model with calibration proposed. Calibration is 
based on two types of initial approximation and employs simplex optimization 
method as a default. An ability to provide a user defined optimization method, 
end criteria and initial guess are also included. More details and examples of 
use can be found in the attached QuantLib test suite unit.

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-13 04:21

Message:
The patch was applied (with some modifications) to the code repository.
It will be included in next release.
Thank you.


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

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



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

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

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

_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev


End of QuantLib-dev Digest, Vol 78, Issue 3
*******************************************

 

Re: [Quantlib-dev] Multicurve discounting

[ED <e06...@gm...>]

On Mon, Sep 3, 2012 at 12:19 PM, Ferdinando Ametrano<na...@am...>
wrote:
> On Mon, Sep 3, 2012 at 5:11 PM, Grześ Andruszkiewicz
> <gan...@gm...> wrote:
>> Does QuantLib support multicurve discounting, i.e. when you discount
>> using one curve (OIS), but use another curve (i.e. 3M LIBOR) for
>> determining of the cash flows? 
> yes it does 

Hi Nando,

What if all you have to build your OIS curve is FFvs3M basis swaps?
In that case you need to jointly calibrate your 3M and OIS curves, as
they are interdependent.
Would you have some pointers on how to do that within Quantlib?

Best Regards,
Ed

Re: [Quantlib-dev] Garch11 in Quantlib (Luigi Ballabio)

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

Done.  Apologies for the delay.

Luigi

On Tue, May 15, 2012 at 3:12 PM, Slava Mazur <sm...@li...> wrote:
> Check it out:
>
> http://sourceforge.net/tracker/?func=detail&aid=3102452&group_id=12740&atid=312740
>
> Submitted there on Nov 2010.
>
> Cheers,
>
> Slava Mazur
>
>
> Message: 5
> Date: Mon, 14 May 2012 13:25:47 -0400
> From: Yue Zhao <yzh...@gm...>
> Subject: [Quantlib-dev] Garch11 in Quantlib
> To: QuantLib Dev <Qua...@li...>
> Message-ID:
>         <CAA...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> My question might be silly. I am using the Garch11 class in QL, but I didn't see how to calibrate this model. Does anyone know how do calibration?
>
> Best
>
> Yue
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 6
> Date: Tue, 15 May 2012 09:35:10 +0200
> From: Luigi Ballabio <lui...@gm...>
> Subject: Re: [Quantlib-dev] Garch11 in Quantlib
> To: Yue Zhao <yzh...@gm...>
> Cc: QuantLib Dev <Qua...@li...>
> Message-ID:
>         <CAJ...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>     at this time there's no code for calibration in the library (the
> Garch11 class declares a calibrate method, but it's empty). If anyone wants to contribute it, I'll be glad to add it to the repository.
>
> Luigi
>
> On Mon, May 14, 2012 at 7:25 PM, Yue Zhao <yzh...@gm...> wrote:
>> My question might be silly. I am using the Garch11 class in QL, but I
>> didn't see how to calibrate this model. Does anyone know how do calibration?
>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> ------------------------------
>
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> End of QuantLib-dev Digest, Vol 72, Issue 5
> *******************************************
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] [ quantlib-Patches-3102452 ] GARCH calibration

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

Patches item #3102452, was opened at 2010-11-03 13:16
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3102452&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: Accepted
Priority: 5
Private: No
Submitted By: Slava Mazur (shlagbaum)
>Assigned to: Luigi Ballabio (lballabio)
Summary: GARCH calibration

Initial Comment:
Re-designed GARCH volatility model with calibration proposed. Calibration is based on two types of initial approximation and employs simplex optimization method as a default. An ability to provide a user defined optimization method, end criteria and initial guess are also included. More details and examples of use can be found in the attached QuantLib test suite unit.

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-13 04:21

Message:
The patch was applied (with some modifications) to the code repository.
It will be included in next release.
Thank you.


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

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

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-12 07:24

Message:
Hi Mateusz,

good that the adaptive method seems to add some value to your implemetation
;-)

When I run the test cases, 4 out of 5 pass now. However, for the
ModFourthDeJong objective function, I get 12.0945 instead of your 10.964.
Maybe this is due to the fact that I'm using a different boost version
(1.47.0) and that boost's MT impementation has changed, but I don't know if
it's worth investgating on this issue or rather exclude the ModFourthDeJong
test case for now (because both values are valid).


Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-11 13:35

Message:
Hi Ralph, Luigi

you were right - self adapting method is quite successful. I have already
added it to my implementation. All tests are passed now. I would be
grateful if you double check my results. I think this is a stable version
that can go to QL trunk. QL users have much more options now.

Recent changes/remarks:
1) Crossover self-adaptation is a separate option - it was very easy to
implement it that way. 
2) User  can decide if DE should use fixed seed or not (as discussed
earlier)
3) Adaptation is performed on the population member basis as stated in the
paper.
4) Additional rotation was added to the self-adaptive method to improve its
performance.
5) Extracted some logic into separate private methods.
6) Original Griewangk function is usually defined on [-600, 600]^n box and
my DE implementation is successful on this search domain. 

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-08 00:23

Message:
Hi Mateusz,

thank you for your reply. The adaptive method can be found here (section
V):

Brest, J. et al., 2006,
"Self-Adapting Control Parameters in Differential Evolution: A Comparative
Study on Numerical  Benchmark Problems."
( A link which worked for me is
http://150.214.190.154/docencia/sf1/Brest06.pdf)

And yes, the adaptive method always found the minimum of the Griewanck
function when I played around with it.


Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-07 14:44

Message:
Hi Ralph,

thank you for your remarks.

1) Fixing the seed for reproducibility is a great idea. I simply forgot to
do it. I tested my implementation against current time as seed to be
perfectly sure that results are reliable. I added an optional config param.
One may want "increase randomness" using the useFixedSeed_=false parameter.
Therefore, both options are available now.
2) This is a philosophical aspect. I used Boost as it was just easier for
me and I find it a reliable tool. It does not add external dependency as QL
already uses Boost libraries. The question is if there is value added if we
change it. In my view - not significant. If you would like to change it,
just go for it.
3) I see your point now with respect to ModFourthDeJong. My random results
were connected with your first observation - after fixing the seed, I
obtained stable minimum equal to 10.409792. I have already amended the test
case.
4) The adaptive method is not implemented yet but it can be easily added.
Could you provide more details on the method as I could not find it in the
literature. The most important aspects are: how many differences are taken
into account and how are weights applied to it? Was crossover important
aspect for this method? And last practical question: Was the adaptive
strategy successful for every chosen seed in your implementation? Griewangk
objective function is probably the last major issue to resolve now.

Thanks
Mateusz

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-07 00:42

Message:
Hi Mateusz,

I have some remarks/questions concerning your DE implementation:

1. You are using time(0) for the seed in the generation of the initial
population (differentialevolution.cpp, line 27). Wouldn't a fix seed be
better for reproducability, in the sense that the same data yield the same
result?
2. As a part of QuantLib, shouldn't one choose QuantLib's random number
generator instead of boost's?
3. For the ModFourthDeJong you mention that you find a lower minimum than
the previous implementation. But that's not the point. If you take a look
at the function, you see the uniform random part, i.e. the functional
minimum is f(0) <= 30*Expectation(uniform) = 15. Therefore you'll get
different realizations for different random numbers, which is ok as long as
the minimum found is below 15.
4. For the Griewangk function, the adaptive method in the current DE
implementation succeeds to find the minimum f(0) = 0. Is the adaptive
method implemented (or implementable) in your code as well?


Thanks,
Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-06 16:15

Message:
Hi Luigi, 

I have a habit of constant auto forrmatting when coding in Eclipse...
Unfortunately, the autoformat profile cannot be adjusted to QL style
easily. I removed unnecessary changes in order to make the patch more
readable. 

Mateusz

BTW. Is it possible to use other external tool (e.g. vim or emacs) to
format source code file in line with QL style? First line in each QL file
specifies autoformat options, doesn't it?

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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

[Quantlib-dev] Black Vega

[Peter C. <pca...@gm...>]

Hi,

in blackformula.cpp , blackFormulaStdDevDerivative(...) the limit case
stdDev == 0.0 seems to be treated false, lines 307ff

if (stdDev==0.0) {
            if (forward>strike)
                return discount * forward;
            else
                return 0.0;
        }

should be

if (stdDev==0.0) return 0.0;

because \phi(x) -> 0 whenever |x| -> \infty, right ?

Thanks
Peter

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by fenixcitizen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

>Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-11 13:35

Message:
Hi Ralph, Luigi

you were right - self adapting method is quite successful. I have already
added it to my implementation. All tests are passed now. I would be
grateful if you double check my results. I think this is a stable version
that can go to QL trunk. QL users have much more options now.

Recent changes/remarks:
1) Crossover self-adaptation is a separate option - it was very easy to
implement it that way. 
2) User  can decide if DE should use fixed seed or not (as discussed
earlier)
3) Adaptation is performed on the population member basis as stated in the
paper.
4) Additional rotation was added to the self-adaptive method to improve its
performance.
5) Extracted some logic into separate private methods.
6) Original Griewangk function is usually defined on [-600, 600]^n box and
my DE implementation is successful on this search domain. 

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-08 00:23

Message:
Hi Mateusz,

thank you for your reply. The adaptive method can be found here (section
V):

Brest, J. et al., 2006,
"Self-Adapting Control Parameters in Differential Evolution: A Comparative
Study on Numerical  Benchmark Problems."
( A link which worked for me is
http://150.214.190.154/docencia/sf1/Brest06.pdf)

And yes, the adaptive method always found the minimum of the Griewanck
function when I played around with it.


Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-07 14:44

Message:
Hi Ralph,

thank you for your remarks.

1) Fixing the seed for reproducibility is a great idea. I simply forgot to
do it. I tested my implementation against current time as seed to be
perfectly sure that results are reliable. I added an optional config param.
One may want "increase randomness" using the useFixedSeed_=false parameter.
Therefore, both options are available now.
2) This is a philosophical aspect. I used Boost as it was just easier for
me and I find it a reliable tool. It does not add external dependency as QL
already uses Boost libraries. The question is if there is value added if we
change it. In my view - not significant. If you would like to change it,
just go for it.
3) I see your point now with respect to ModFourthDeJong. My random results
were connected with your first observation - after fixing the seed, I
obtained stable minimum equal to 10.409792. I have already amended the test
case.
4) The adaptive method is not implemented yet but it can be easily added.
Could you provide more details on the method as I could not find it in the
literature. The most important aspects are: how many differences are taken
into account and how are weights applied to it? Was crossover important
aspect for this method? And last practical question: Was the adaptive
strategy successful for every chosen seed in your implementation? Griewangk
objective function is probably the last major issue to resolve now.

Thanks
Mateusz

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-07 00:42

Message:
Hi Mateusz,

I have some remarks/questions concerning your DE implementation:

1. You are using time(0) for the seed in the generation of the initial
population (differentialevolution.cpp, line 27). Wouldn't a fix seed be
better for reproducability, in the sense that the same data yield the same
result?
2. As a part of QuantLib, shouldn't one choose QuantLib's random number
generator instead of boost's?
3. For the ModFourthDeJong you mention that you find a lower minimum than
the previous implementation. But that's not the point. If you take a look
at the function, you see the uniform random part, i.e. the functional
minimum is f(0) <= 30*Expectation(uniform) = 15. Therefore you'll get
different realizations for different random numbers, which is ok as long as
the minimum found is below 15.
4. For the Griewangk function, the adaptive method in the current DE
implementation succeeds to find the minimum f(0) = 0. Is the adaptive
method implemented (or implementable) in your code as well?


Thanks,
Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-06 16:15

Message:
Hi Luigi, 

I have a habit of constant auto forrmatting when coding in Eclipse...
Unfortunately, the autoformat profile cannot be adjusted to QL style
easily. I removed unnecessary changes in order to make the patch more
readable. 

Mateusz

BTW. Is it possible to use other external tool (e.g. vim or emacs) to
format source code file in line with QL style? First line in each QL file
specifies autoformat options, doesn't it?

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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

[Quantlib-dev] Clarification: AsianOption in the middle of its path

[Eric B. <em...@er...>]

Hi everyone,

I have been calculating NPV and Greeks at intermediate points along the
path of an asian option; I want to throw my technique into RQuantLib -- but
first I want some validation that what I am doing is kosher.  :)

Right now I am using DiscreteAveragingAsianOption and
AnalyticDiscreteGeometric...Engine, pre-setting the runningAccumulator to
the product of the previous prices, pastFixings to the number of previous
time points, fixingDates to only the **remaining** time points.

I have been getting answers that look good to me, but does 1. hacking the
fixtures arguments this way and 2. only using the remaining fixing dates
get an a.okay from the guys who designed this in the first place?  Is there
a better way to do this?

Thanks for all the time you have put into this useful software,

Eric

[Quantlib-dev] Clarification: AsianOption in the middle of its path

[Eric B. <em...@er...>]

Hi everyone,

I have been calculating NPV and Greeks at intermediate points along the
path of an asian option; I want to throw my technique into RQuantLib -- but
first I want some validation that what I am doing is kosher.  :)

Right now I am using DiscreteAveragingAsianOption and
AnalyticDiscreteGeometric...Engine, pre-setting the runningAccumulator to
the product of the previous prices, pastFixings to the number of previous
time points, fixingDates to only the **remaining** time points.

I have been getting answers that look good to me, but does 1. hacking the
fixtures arguments this way and 2. only using the remaining fixing dates
get an a.okay from the guys who designed this in the first place?  Is there
a better way to do this?

Thanks for all the time you have put into this useful software,

Eric

Re: [Quantlib-dev] In arrears adjustment

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

Hi Peter,
    yes, your changes look correct to me.  Can anyone else validate
them?  Ferdinando?

Luigi

On Sat, Nov 3, 2012 at 7:09 PM, Peter Caspers <pca...@gm...> wrote:
> Hi,
>
> I think the in arrears adjustment in couponpricer.cpp is computed
> slightly wrong. Shouldn't it be like in the adjusted code below?
>
> Thanks, Peter
>
> ql/cashflows/couponpricer.cpp
>
>               // see Hull, 4th ed., page 550
>               QL_REQUIRE(!capletVolatility().empty(),
>                          "missing optionlet volatility");
>               Date d1 = coupon_->fixingDate(),
> +                 d2 = coupon_->index()->valueDate(d1),
>                    referenceDate = capletVolatility()->referenceDate();
>               if (d1 <= referenceDate) {
>                   adjustement = 0.0;
>               } else {
> -                Date d2 = coupon_->index()->maturityDate(d1);
> -                Time tau =
> coupon_->index()->dayCounter().yearFraction(d1, d2);
> +                Date d3 = coupon_->index()->maturityDate(d2);
> +                Time tau =
> coupon_->index()->dayCounter().yearFraction(d2, d3);
>                   Real variance = capletVolatility()->blackVariance(d1,
> fixing);
>                   adjustement = fixing*fixing*variance*tau/(1.0+fixing*tau);
>               }
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-08 00:23

Message:
Hi Mateusz,

thank you for your reply. The adaptive method can be found here (section
V):

Brest, J. et al., 2006,
"Self-Adapting Control Parameters in Differential Evolution: A Comparative
Study on Numerical  Benchmark Problems."
( A link which worked for me is
http://150.214.190.154/docencia/sf1/Brest06.pdf)

And yes, the adaptive method always found the minimum of the Griewanck
function when I played around with it.


Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-07 14:44

Message:
Hi Ralph,

thank you for your remarks.

1) Fixing the seed for reproducibility is a great idea. I simply forgot to
do it. I tested my implementation against current time as seed to be
perfectly sure that results are reliable. I added an optional config param.
One may want "increase randomness" using the useFixedSeed_=false parameter.
Therefore, both options are available now.
2) This is a philosophical aspect. I used Boost as it was just easier for
me and I find it a reliable tool. It does not add external dependency as QL
already uses Boost libraries. The question is if there is value added if we
change it. In my view - not significant. If you would like to change it,
just go for it.
3) I see your point now with respect to ModFourthDeJong. My random results
were connected with your first observation - after fixing the seed, I
obtained stable minimum equal to 10.409792. I have already amended the test
case.
4) The adaptive method is not implemented yet but it can be easily added.
Could you provide more details on the method as I could not find it in the
literature. The most important aspects are: how many differences are taken
into account and how are weights applied to it? Was crossover important
aspect for this method? And last practical question: Was the adaptive
strategy successful for every chosen seed in your implementation? Griewangk
objective function is probably the last major issue to resolve now.

Thanks
Mateusz

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-07 00:42

Message:
Hi Mateusz,

I have some remarks/questions concerning your DE implementation:

1. You are using time(0) for the seed in the generation of the initial
population (differentialevolution.cpp, line 27). Wouldn't a fix seed be
better for reproducability, in the sense that the same data yield the same
result?
2. As a part of QuantLib, shouldn't one choose QuantLib's random number
generator instead of boost's?
3. For the ModFourthDeJong you mention that you find a lower minimum than
the previous implementation. But that's not the point. If you take a look
at the function, you see the uniform random part, i.e. the functional
minimum is f(0) <= 30*Expectation(uniform) = 15. Therefore you'll get
different realizations for different random numbers, which is ok as long as
the minimum found is below 15.
4. For the Griewangk function, the adaptive method in the current DE
implementation succeeds to find the minimum f(0) = 0. Is the adaptive
method implemented (or implementable) in your code as well?


Thanks,
Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-06 16:15

Message:
Hi Luigi, 

I have a habit of constant auto forrmatting when coding in Eclipse...
Unfortunately, the autoformat profile cannot be adjusted to QL style
easily. I removed unnecessary changes in order to make the patch more
readable. 

Mateusz

BTW. Is it possible to use other external tool (e.g. vim or emacs) to
format source code file in line with QL style? First line in each QL file
specifies autoformat options, doesn't it?

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by fenixcitizen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

>Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-07 14:44

Message:
Hi Ralph,

thank you for your remarks.

1) Fixing the seed for reproducibility is a great idea. I simply forgot to
do it. I tested my implementation against current time as seed to be
perfectly sure that results are reliable. I added an optional config param.
One may want "increase randomness" using the useFixedSeed_=false parameter.
Therefore, both options are available now.
2) This is a philosophical aspect. I used Boost as it was just easier for
me and I find it a reliable tool. It does not add external dependency as QL
already uses Boost libraries. The question is if there is value added if we
change it. In my view - not significant. If you would like to change it,
just go for it.
3) I see your point now with respect to ModFourthDeJong. My random results
were connected with your first observation - after fixing the seed, I
obtained stable minimum equal to 10.409792. I have already amended the test
case.
4) The adaptive method is not implemented yet but it can be easily added.
Could you provide more details on the method as I could not find it in the
literature. The most important aspects are: how many differences are taken
into account and how are weights applied to it? Was crossover important
aspect for this method? And last practical question: Was the adaptive
strategy successful for every chosen seed in your implementation? Griewangk
objective function is probably the last major issue to resolve now.

Thanks
Mateusz

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-07 00:42

Message:
Hi Mateusz,

I have some remarks/questions concerning your DE implementation:

1. You are using time(0) for the seed in the generation of the initial
population (differentialevolution.cpp, line 27). Wouldn't a fix seed be
better for reproducability, in the sense that the same data yield the same
result?
2. As a part of QuantLib, shouldn't one choose QuantLib's random number
generator instead of boost's?
3. For the ModFourthDeJong you mention that you find a lower minimum than
the previous implementation. But that's not the point. If you take a look
at the function, you see the uniform random part, i.e. the functional
minimum is f(0) <= 30*Expectation(uniform) = 15. Therefore you'll get
different realizations for different random numbers, which is ok as long as
the minimum found is below 15.
4. For the Griewangk function, the adaptive method in the current DE
implementation succeeds to find the minimum f(0) = 0. Is the adaptive
method implemented (or implementable) in your code as well?


Thanks,
Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-06 16:15

Message:
Hi Luigi, 

I have a habit of constant auto forrmatting when coding in Eclipse...
Unfortunately, the autoformat profile cannot be adjusted to QL style
easily. I removed unnecessary changes in order to make the patch more
readable. 

Mateusz

BTW. Is it possible to use other external tool (e.g. vim or emacs) to
format source code file in line with QL style? First line in each QL file
specifies autoformat options, doesn't it?

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

Comment By: https://www.google.com/accounts ()
Date: 2012-11-07 00:42

Message:
Hi Mateusz,

I have some remarks/questions concerning your DE implementation:

1. You are using time(0) for the seed in the generation of the initial
population (differentialevolution.cpp, line 27). Wouldn't a fix seed be
better for reproducability, in the sense that the same data yield the same
result?
2. As a part of QuantLib, shouldn't one choose QuantLib's random number
generator instead of boost's?
3. For the ModFourthDeJong you mention that you find a lower minimum than
the previous implementation. But that's not the point. If you take a look
at the function, you see the uniform random part, i.e. the functional
minimum is f(0) <= 30*Expectation(uniform) = 15. Therefore you'll get
different realizations for different random numbers, which is ok as long as
the minimum found is below 15.
4. For the Griewangk function, the adaptive method in the current DE
implementation succeeds to find the minimum f(0) = 0. Is the adaptive
method implemented (or implementable) in your code as well?


Thanks,
Ralph

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

Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-06 16:15

Message:
Hi Luigi, 

I have a habit of constant auto forrmatting when coding in Eclipse...
Unfortunately, the autoformat profile cannot be adjusted to QL style
easily. I removed unnecessary changes in order to make the patch more
readable. 

Mateusz

BTW. Is it possible to use other external tool (e.g. vim or emacs) to
format source code file in line with QL style? First line in each QL file
specifies autoformat options, doesn't it?

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by fenixcitizen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

>Comment By: Mateusz Kapturski (fenixcitizen)
Date: 2012-11-06 16:15

Message:
Hi Luigi, 

I have a habit of constant auto forrmatting when coding in Eclipse...
Unfortunately, the autoformat profile cannot be adjusted to QL style
easily. I removed unnecessary changes in order to make the patch more
readable. 

Mateusz

BTW. Is it possible to use other external tool (e.g. vim or emacs) to
format source code file in line with QL style? First line in each QL file
specifies autoformat options, doesn't it?

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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