quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] writing SWIG file for forward/FRA

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

I've added the interface file and the example to the repository.

Thanks,
    Luigi


On Sun, Oct 7, 2012 at 11:19 AM, Francis Duffy <fdf...@gm...> wrote:
> Hi Tawanda,
>
> I amended your interface file a little as shown below to export the class
> ForwardRateAgreement. I do not export the class Forward because I do not
> think that you need to. I think that your main issue is the use of
> boost::shared_ptr<IborIndex>& in the argument list of the constructor. I
> think that this should be IborIndexPtr& like it is in the constructor of
> VanillaSwap in the file swap.i.
>
> I have attached a short java example that I used to check that the
> constructor works. I am not sure what language you are targeting though so
> this may not be helpful.
>
> Regards,
> Francis.
>
> forwardrateagreement.i
>
> -------------------------------
>
> #ifndef quantlib_forwardrateagreement_i
> #define quantlib_forwardrateagreement_i
>
> %include instruments.i
> %include termstructures.i
> %include interestrate.i
>
>
>
> %{
> using QuantLib::Position;
> using QuantLib::ForwardRateAgreement;
>
>
> typedef boost::shared_ptr<Instrument> ForwardRateAgreementPtr;
> %}
>
> struct Position {
>     enum Type {Long, Short};
> };
>
>
>
> %rename(ForwardRateAgreement) ForwardRateAgreementPtr;
> class ForwardRateAgreementPtr : public boost::shared_ptr<Instrument> {
>    public:
>      %extend {
>          ForwardRateAgreementPtr(const Date& valueDate,
>
>
>                  const Date& maturityDate,
>                  Position::Type type,
>                  Rate strikeForwardRate,
>                  Real notionalAmount,
>                  const IborIndexPtr& index,
>
>                  const Handle<YieldTermStructure>& discountCurve =
> Handle<YieldTermStructure>()) {
>
>              boost::shared_ptr<IborIndex> libor =
>                  boost::dynamic_pointer_cast<IborIndex>(index);
>
>
>
>              return new ForwardRateAgreementPtr(
>                      new ForwardRateAgreement(valueDate,
>                          maturityDate,
>                          type,
>                          strikeForwardRate,
>                          notionalAmount,
>                          libor,
>
>                          discountCurve));
>          }
>
>          Real spotIncome(const Handle<YieldTermStructure>&
> incomeDiscountCurve) const {
>              return boost::dynamic_pointer_cast<ForwardRateAgreement>(*self)
>                  ->spotIncome(incomeDiscountCurve);
>          }
>
>
>
>          Real spotValue() const {
>
>
>              return boost::dynamic_pointer_cast<ForwardRateAgreement>(*self)
>                  ->spotValue();
>          }
>
>
>
>          InterestRate forwardRate() const {
>
>
>              return boost::dynamic_pointer_cast<ForwardRateAgreement>(*self)
>                  ->forwardRate();
>          }
>      }
> };
>
>
>
> #endif
>
>
>
> On Sat, Oct 6, 2012 at 4:35 PM, Tawanda Gwena <tg...@gm...> wrote:
>>
>> I am trying to expose the FRA instrument. I have managed to write the swig
>> file and it compiles. However, I cannot create the object. It consistently
>> produces the error:
>>
>>
>> Wrong arguments for overloaded function 'new_ForwardRateAgreement'
>>  Possible C/C++ prototypes are:
>>    ForwardRateAgreementPtr::ForwardRateAgreementPtr(Date const &,Date
>> const &,Position::Type,Rate,Real,boost::shared_ptr< IborIndex > const
>> &,QuantLib::Handle< YieldTermStructure > const &)
>>    ForwardRateAgreementPtr::ForwardRateAgreementPtr(Date const &,Date
>> const &,Position::Type,Rate,Real,boost::shared_ptr< IborIndex > const &)
>>
>> What am I doing wrong? Below are the contents of the swig file:
>>
>>
>>
>> #ifndef quantlib_forwards_i
>> #define quantlib_forwards_i
>>
>> %include instruments.i
>> %include termstructures.i
>> %include cashflows.i
>> %include grid.i
>> %include stl.i
>> %{
>> using QuantLib::Position;
>> using QuantLib::Forward;
>> using QuantLib::ForwardRateAgreement;
>> using QuantLib::Seasonality;
>> typedef boost::shared_ptr<Instrument> ForwardPtr;
>> typedef boost::shared_ptr<Instrument> ForwardRateAgreementPtr;
>> %}
>>
>> struct Position {
>>     enum Type { Long, Short};
>> };
>>
>> %rename(Forward) ForwardPtr;
>> class ForwardPtr : public boost::shared_ptr<Instrument> {
>>   public:
>>     %extend {
>>
>>         Date settlementDate() {
>>             return
>> boost::dynamic_pointer_cast<Forward>(*self)->settlementDate();
>>         }
>>         BusinessDayConvention businessDayConvention() {
>>             return
>> boost::dynamic_pointer_cast<Forward>(*self)->businessDayConvention();
>>         }
>>         Rate spotValue() {
>>             return
>> boost::dynamic_pointer_cast<Forward>(*self)->spotValue();
>>         }
>>         Rate forwardValue() {
>>             return
>> boost::dynamic_pointer_cast<Forward>(*self)->forwardValue();
>>         }
>>         InterestRate impliedYield(Real underlyingSpotValue,
>>                                   Real forwardValue,
>>                                   Date settlementDate,
>>                                   Compounding compoundingConvention,
>>                                   DayCounter dayCounter) {
>>            return
>> boost::dynamic_pointer_cast<Forward>(*self)->impliedYield(
>>                                   underlyingSpotValue,
>>                                   forwardValue,
>>                                   settlementDate,
>>                                   compoundingConvention,
>>                                   dayCounter);
>>         }
>>         }
>>   protected: /* added this later, but did not help*/
>>         Forward(const DayCounter& dayCounter,
>>                 const Calendar& calendar,
>>                 BusinessDayConvention businessDayConvention,
>>                 Natural settlementDays,
>>                 const boost::shared_ptr<Payoff>& payoff,
>>                 const Date& valueDate,
>>                 const Date& maturityDate,
>>                 const Handle<YieldTermStructure>& discountCurve =
>>
>> Handle<YieldTermStructure>()) {
>>                 return new ForwardPtr(new Forward(dayCounter,
>>                         calendar,
>>                         businessDayConvention,
>>                         settlementDays,
>>                         payoff,
>>                         valueDate,
>>                         maturityDate,
>>                         discountCurve));
>>         }
>>
>> };
>>
>> %rename(ForwardRateAgreement) ForwardRateAgreementPtr;
>> class ForwardRateAgreementPtr : public ForwardPtr {
>>   public:
>>     %extend {
>>         ForwardRateAgreementPtr(
>>                 const Date& valueDate,
>>                 const Date& maturityDate,
>>                 Position::Type type,
>>                 Rate strikeForwardRate,
>>                 Real notionalAmount,
>>                 const boost::shared_ptr<IborIndex>& index,
>>                 const Handle<YieldTermStructure>& discountCurve =
>>
>> Handle<YieldTermStructure>()) {
>>                             return new ForwardRateAgreementPtr(
>>                                          new
>> ForwardRateAgreement(valueDate,
>>
>> maturityDate,
>>                                                                   type,
>>
>> strikeForwardRate,
>>
>> notionalAmount,
>>                                                                   index,
>>
>> discountCurve));
>>             }
>>
>>
>>        Real spotIncome(const Handle<YieldTermStructure>&
>> incomeDiscountCurve) const {
>>           return
>> boost::dynamic_pointer_cast<ForwardRateAgreement>(*self)-> spotIncome(
>>                             incomeDiscountCurve);
>>            }
>>       /*Real spotValue() {
>>         return
>> boost::dynamic_pointer_cast<ForwardRateAgreement>(*self)->spotValue();
>>       }*/
>>     }
>> };
>>
>>
>> #endif
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

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

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

Many thanks


Regards


Theo




-----Original Message-----
From: Luigi Ballabio <lui...@gm...>
To: Theo Boafo <tb...@ao...>
CC: quantlib-dev <qua...@li...>
Sent: Wed, 28 Nov 2012 16:39
Subject: Re: [Quantlib-dev] QuantLib-dev Digest, Vol 78, Issue 12


Yes, you can do that.

Luigi


On Wed, Nov 28, 2012 at 5:36 PM, Theo Boafo <tb...@ao...> wrote:
> Hi,
>
> So I can have a new class FloatFloatSwap inheriting from Swap class and
> build the two legs as you suggested?
>
> Regards
>
> Theo
>
>
>
> -----Original Message-----
> From: Luigi Ballabio <lui...@gm...>
> To: Theo Boafo <tb...@ao...>
> CC: quantlib-dev <qua...@li...>
> Sent: Wed, 28 Nov 2012 16:32
> Subject: Re: [Quantlib-dev] QuantLib-dev Digest, Vol 78, Issue 12
>
> You'll have to build the two legs yourself and use the Swap class instead.
>
> Luigi
>
>
> On Wed, Nov 28, 2012 at 5:22 PM, Theo Boafo <tb...@ao...> wrote:
>> Hi,
>>
>> Looking at the vanillaswap it values swaps with  fixed for floating
>> schedules or legs.  I cant see anything doing float for float or am I
>> missing something.
>>
>> Regards
>>
>> Theo
>>
>>
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>

 

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

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

Yes, you can do that.

Luigi


On Wed, Nov 28, 2012 at 5:36 PM, Theo Boafo <tb...@ao...> wrote:
> Hi,
>
> So I can have a new class FloatFloatSwap inheriting from Swap class and
> build the two legs as you suggested?
>
> Regards
>
> Theo
>
>
>
> -----Original Message-----
> From: Luigi Ballabio <lui...@gm...>
> To: Theo Boafo <tb...@ao...>
> CC: quantlib-dev <qua...@li...>
> Sent: Wed, 28 Nov 2012 16:32
> Subject: Re: [Quantlib-dev] QuantLib-dev Digest, Vol 78, Issue 12
>
> You'll have to build the two legs yourself and use the Swap class instead.
>
> Luigi
>
>
> On Wed, Nov 28, 2012 at 5:22 PM, Theo Boafo <tb...@ao...> wrote:
>> Hi,
>>
>> Looking at the vanillaswap it values swaps with  fixed for floating
>> schedules or legs.  I cant see anything doing float for float or am I
>> missing something.
>>
>> Regards
>>
>> Theo
>>
>>
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>

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

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

Hi,


So I can have a new class FloatFloatSwap inheriting from Swap class and build the two legs as you suggested?


Regards


Theo



-----Original Message-----
From: Luigi Ballabio <lui...@gm...>
To: Theo Boafo <tb...@ao...>
CC: quantlib-dev <qua...@li...>
Sent: Wed, 28 Nov 2012 16:32
Subject: Re: [Quantlib-dev] QuantLib-dev Digest, Vol 78, Issue 12


You'll have to build the two legs yourself and use the Swap class instead.

Luigi


On Wed, Nov 28, 2012 at 5:22 PM, Theo Boafo <tb...@ao...> wrote:
> Hi,
>
> Looking at the vanillaswap it values swaps with  fixed for floating
> schedules or legs.  I cant see anything doing float for float or am I
> missing something.
>
> Regards
>
> Theo
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

 

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

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

You'll have to build the two legs yourself and use the Swap class instead.

Luigi


On Wed, Nov 28, 2012 at 5:22 PM, Theo Boafo <tb...@ao...> wrote:
> Hi,
>
> Looking at the vanillaswap it values swaps with  fixed for floating
> schedules or legs.  I cant see anything doing float for float or am I
> missing something.
>
> Regards
>
> Theo
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

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

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

Hi,




Looking at the vanillaswap it values swaps with  fixed for floating schedules or legs.  I cant see anything doing float for float or am I missing something.


Regards


Theo
 

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

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

Hi,


Looking at the vanillaswap it values swaps with  fixed for floating schedules or legs.  I cant see anything doing float for float or am I missing something.


Regards


Theo



-----Original Message-----
From: quantlib-dev-request <qua...@li...>
To: quantlib-dev <qua...@li...>
Sent: Tue, 27 Nov 2012 9:27
Subject: QuantLib-dev Digest, Vol 78, Issue 12


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. Re: Black Vega (Luigi Ballabio)
   2. Re: Black Vega (Luigi Ballabio)
   3. Re: thread safe session handling via TSS (Riccardo Ghetta)
   4. [ quantlib-Patches-3582579 ] Differential Evolution
      improvement (SourceForge.net)


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

Message: 1
Date: Mon, 26 Nov 2012 16:39:44 +0100
From: Luigi Ballabio <lui...@gm...>
Subject: Re: [Quantlib-dev] Black Vega
To: Peter Caspers <pca...@gm...>
Cc: "qua...@li..."
	<qua...@li...>
Message-ID:
	<CAJ...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

Yes, you're correct.  I'll fix it.

Luigi


On Mon, Nov 12, 2012 at 11:49 AM, Peter Caspers <pca...@gm...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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
>



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

Message: 2
Date: Mon, 26 Nov 2012 17:59:06 +0100
From: Luigi Ballabio <lui...@gm...>
Subject: Re: [Quantlib-dev] Black Vega
To: Peter Caspers <pca...@gm...>
Cc: "qua...@li..."
	<qua...@li...>
Message-ID:
	<CAJ...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

Fixed, thanks.

Luigi

On Mon, Nov 26, 2012 at 4:39 PM, Luigi Ballabio
<lui...@gm...> wrote:
> Yes, you're correct.  I'll fix it.
>
> Luigi
>
>
> On Mon, Nov 12, 2012 at 11:49 AM, Peter Caspers <pca...@gm...> 
wrote:
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>



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

Message: 3
Date: Mon, 26 Nov 2012 18:07:13 +0100
From: Riccardo Ghetta <rg...@la...>
Subject: Re: [Quantlib-dev] thread safe session handling via TSS
To: Luigi Ballabio <lui...@gm...>
Cc: Ferdinando Ametrano <na...@am...>,
	"qua...@li..."
	<qua...@li...>
Message-ID: <50B...@la...>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


Well, Singleton returns an instance ... perhaps we could mix the two 
solutions at this level ...
What about changing a little the default ?
Instead of defaulting to a single session per application, default to a 
single session per thread (via TSS).
When the user registers a sessionId function (via setSessionIdFunc), 
switch to lock+map.
If you want, I'll try to concoct an implementation along these lines.

I am a bit uncomfortable, however, with a sessionId-based solution.
IMO is inherently fragile: one must ensure than no one will modify the 
same session from different threads.
So the application must be single-threaded, or use some other method to 
avoid trashing the singletons.
This even when Singleton is using locks, as in Mortoray implementation. 
A lock in this case protects only the mapping id-singleton, not the 
singleton data.
Consider this example, with a default sessionId(), i.e. one returning 
always 0:

thread 1  calls
         Settings::instance().evaluationDate()= Date(1, Jan, 2012);
meanwhile thread 2 calls
         Settings::instance().evaluationDate()= Date(15, Jan, 2012);

Settings::instance() can be accessed by one thread at time, but 
afterward both threads have a reference to the same instance, so no one 
knows really what value will have the evaluation date.
To avoid this race you have to lock the entire sequence, or associate a 
session to a single thread, perhaps via thread storage :).

Riccardo

-------- Original Message --------
Subject: Re: [Quantlib-dev] thread safe session handling via TSS
From: Luigi Ballabio <lui...@gm...>
To: Riccardo Ghetta <rg...@la...>
CC: "qua...@li..." 
<qua...@li...>, Ferdinando Ametrano 
<na...@am...>
Date: Monday, November 26, 2012 16:21:14
> It might be reasonable. But as mortoray argued, one might want to
> switch between the two possibilities without recompiling; especially
> those that don't compile the library and get it packaged from a Linux
> distribution.  If we provide such a switch, linking libboost_thread
> would be required anyway.  What do you think?
>
> A future possibility would be to rework mortoray's patch so that the
> pluggable function returns the instance directly instead of an integer
> id; in such an implementation, your technique would just provide a
> particular function.  However, that's not backward compatible...
>
> Luigi
>
>
> On Tue, Oct 23, 2012 at 3:43 PM, Riccardo Ghetta <rg...@la...> wrote:
>> Not directly, no.
>> I've looked at mortoray patch. Unfortunately that scheme is not compatible
>> with thread storage;  having a per-thread instance makes all the
>> sessionId/sessionIdFunc machinery useless.  In a way, is implicitly handled.
>> Likewise for the instances_ map.
>>
>> On the other hand, perhaps I can rework the tss patch to avoid including
>> boost thread headers in singleton.hpp, if we don't want to force quantlib
>> users to compile with boost:thread.
>> That should preserve the main qualities of the above patch, i.e. being
>> thread-safe and not requiring libboost_thread, plus the added safety,
>> simplicity and performance of tss.
>>
>> it might be a reasonable solution ?
>> Ciao,
>>
>> R
>>
>>
>> -------- Original Message --------
>> Subject: Re: [Quantlib-dev] thread safe session handling via TSS
>> From: Luigi Ballabio <lui...@gm...>
>> To: Riccardo Ghetta <rg...@la...>
>> CC: qua...@li..., Ferdinando Ametrano
>> <na...@am...>
>> Date: Tuesday, October 23, 2012 12:10:59
>>> Riccardo,
>>>
>>>      I just had a look at your patch.  Is there any chance that it can
>>> be made to work together with the pending patch at
>>>
>>> <https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>?
>>>    (Yes, we have stuff all over the place and it's not easy to find it.
>>> Our bad.)
>>>
>>> About the contributor agreement: in the past we used something like
>>> the document I'm attaching.  You can scan the signed document and send
>>> it to me and Ferdinando (whose address is in cc).
>>>
>>> Thanks,
>>>       Luigi
>>>
>>>
>>> On Fri, Oct 19, 2012 at 3:22 PM, Riccardo Ghetta <rg...@la...> wrote:
>>>> Hi,
>>>> I've just posted a patch to enable thread safe session handling.  It
>>>> should also solve bug 3441748.
>>>> The company I work for, Thema Consulting SA (www.themaconsulting.ch),
>>>> uses QuantLib in its MasterFinance product and has other patches we like
>>>> to contribute back (as soon they're cleared by management/legal).
>>>>
>>>> BTW, is the contributor agreement needed ? Where should be sent ?
>>>> I searched the mailing list, but without luck.
>>>>
>>>> Ciao,
>>>> Riccardo Ghetta
>>>> Thema Consulting SA
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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_sfd2d_oct
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>




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

Message: 4
Date: Mon, 26 Nov 2012 14:13:54 -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 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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mateusz Kapturski (fenixcitizen)
Assigned to: Luigi Ballabio (lballabio)
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-26 14:13

Message:
Hi Luigi, 

thank you for your amendments. The logic has not changed and it works for
me. All tests passed. 

However, I had to change Makefile.am file in ql/math/optimisation directory
and put -std=c++0x flag as you used Initializer list (feature from c++11).
I compile QL using gcc. I wonder, if other users may experience similar
problems. Is there a simple way to use this flag in the whole project? I
tried to compile it using VS2010 and VS2012 but both failed (initializer
lists are still missing in VS).

Regards,
Mateusz

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-21 01:26

Message:
Mateusz,
    I've added your code to the repository.  I've made a few refactorings
to make it more in line with the style we've been using in the library, so
you might want to check that everything still works.  In particular:

- I've replaced the use of boost::random with our mersenne-twister
generator;
- I've turned the configuration class into an inner class;
- I've removed setters, which don't play well with observability;
- I've removed pointer data members;
- plus some minor cleanup.

Thanks,
    Luigi


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

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



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

------------------------------------------------------------------------------
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 12
********************************************

 

[Quantlib-dev] [ quantlib-Bugs-3575440 ] a small one - gammadistribution.cpp

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

Bugs item #3575440, was opened at 2012-10-08 03:20
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3575440&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: Fixed
Priority: 5
Private: No
Submitted By: ian.qsong (qsong)
>Assigned to: Luigi Ballabio (lballabio)
Summary: a small one - gammadistribution.cpp

Initial Comment:
LN #56 in gammadistribution.cpp reads as

     return h*std::exp(-x + a_*std::log(x) - gln), which should be

     return 1.0 - h*std::exp(-x + a_*std::log(x) - gln).

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-27 07:44

Message:
The patch was applied to the Subversion repository.
Thank you for the report and the fix.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3575440&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 lballabio
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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mateusz Kapturski (fenixcitizen)
Assigned to: Luigi Ballabio (lballabio)
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: Luigi Ballabio (lballabio)
Date: 2012-11-26 23:57

Message:
That's strange.  It's not an initializer list---well, now it is, but it's
been allowed for a long time for struct initialization.  I compiled it
correctly with gcc 4.7 without the c++0x flag.
Oh well. I'll try writing it differently.


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

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

Message:
Hi Luigi, 

thank you for your amendments. The logic has not changed and it works for
me. All tests passed. 

However, I had to change Makefile.am file in ql/math/optimisation directory
and put -std=c++0x flag as you used Initializer list (feature from c++11).
I compile QL using gcc. I wonder, if other users may experience similar
problems. Is there a simple way to use this flag in the whole project? I
tried to compile it using VS2010 and VS2012 but both failed (initializer
lists are still missing in VS).

Regards,
Mateusz

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-21 01:26

Message:
Mateusz,
    I've added your code to the repository.  I've made a few refactorings
to make it more in line with the style we've been using in the library, so
you might want to check that everything still works.  In particular:

- I've replaced the use of boost::random with our mersenne-twister
generator;
- I've turned the configuration class into an inner class;
- I've removed setters, which don't play well with observability;
- I've removed pointer data members;
- plus some minor cleanup.

Thanks,
    Luigi


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

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=1274

[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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mateusz Kapturski (fenixcitizen)
Assigned to: Luigi Ballabio (lballabio)
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-26 14:13

Message:
Hi Luigi, 

thank you for your amendments. The logic has not changed and it works for
me. All tests passed. 

However, I had to change Makefile.am file in ql/math/optimisation directory
and put -std=c++0x flag as you used Initializer list (feature from c++11).
I compile QL using gcc. I wonder, if other users may experience similar
problems. Is there a simple way to use this flag in the whole project? I
tried to compile it using VS2010 and VS2012 but both failed (initializer
lists are still missing in VS).

Regards,
Mateusz

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-21 01:26

Message:
Mateusz,
    I've added your code to the repository.  I've made a few refactorings
to make it more in line with the style we've been using in the library, so
you might want to check that everything still works.  In particular:

- I've replaced the use of boost::random with our mersenne-twister
generator;
- I've turned the configuration class into an inner class;
- I've removed setters, which don't play well with observability;
- I've removed pointer data members;
- plus some minor cleanup.

Thanks,
    Luigi


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

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

Re: [Quantlib-dev] thread safe session handling via TSS

[Riccardo G. <rg...@la...>]

Well, Singleton returns an instance ... perhaps we could mix the two 
solutions at this level ...
What about changing a little the default ?
Instead of defaulting to a single session per application, default to a 
single session per thread (via TSS).
When the user registers a sessionId function (via setSessionIdFunc), 
switch to lock+map.
If you want, I'll try to concoct an implementation along these lines.

I am a bit uncomfortable, however, with a sessionId-based solution.
IMO is inherently fragile: one must ensure than no one will modify the 
same session from different threads.
So the application must be single-threaded, or use some other method to 
avoid trashing the singletons.
This even when Singleton is using locks, as in Mortoray implementation. 
A lock in this case protects only the mapping id-singleton, not the 
singleton data.
Consider this example, with a default sessionId(), i.e. one returning 
always 0:

thread 1  calls
         Settings::instance().evaluationDate()= Date(1, Jan, 2012);
meanwhile thread 2 calls
         Settings::instance().evaluationDate()= Date(15, Jan, 2012);

Settings::instance() can be accessed by one thread at time, but 
afterward both threads have a reference to the same instance, so no one 
knows really what value will have the evaluation date.
To avoid this race you have to lock the entire sequence, or associate a 
session to a single thread, perhaps via thread storage :).

Riccardo

-------- Original Message --------
Subject: Re: [Quantlib-dev] thread safe session handling via TSS
From: Luigi Ballabio <lui...@gm...>
To: Riccardo Ghetta <rg...@la...>
CC: "qua...@li..." 
<qua...@li...>, Ferdinando Ametrano 
<na...@am...>
Date: Monday, November 26, 2012 16:21:14
> It might be reasonable. But as mortoray argued, one might want to
> switch between the two possibilities without recompiling; especially
> those that don't compile the library and get it packaged from a Linux
> distribution.  If we provide such a switch, linking libboost_thread
> would be required anyway.  What do you think?
>
> A future possibility would be to rework mortoray's patch so that the
> pluggable function returns the instance directly instead of an integer
> id; in such an implementation, your technique would just provide a
> particular function.  However, that's not backward compatible...
>
> Luigi
>
>
> On Tue, Oct 23, 2012 at 3:43 PM, Riccardo Ghetta <rg...@la...> wrote:
>> Not directly, no.
>> I've looked at mortoray patch. Unfortunately that scheme is not compatible
>> with thread storage;  having a per-thread instance makes all the
>> sessionId/sessionIdFunc machinery useless.  In a way, is implicitly handled.
>> Likewise for the instances_ map.
>>
>> On the other hand, perhaps I can rework the tss patch to avoid including
>> boost thread headers in singleton.hpp, if we don't want to force quantlib
>> users to compile with boost:thread.
>> That should preserve the main qualities of the above patch, i.e. being
>> thread-safe and not requiring libboost_thread, plus the added safety,
>> simplicity and performance of tss.
>>
>> it might be a reasonable solution ?
>> Ciao,
>>
>> R
>>
>>
>> -------- Original Message --------
>> Subject: Re: [Quantlib-dev] thread safe session handling via TSS
>> From: Luigi Ballabio <lui...@gm...>
>> To: Riccardo Ghetta <rg...@la...>
>> CC: qua...@li..., Ferdinando Ametrano
>> <na...@am...>
>> Date: Tuesday, October 23, 2012 12:10:59
>>> Riccardo,
>>>
>>>      I just had a look at your patch.  Is there any chance that it can
>>> be made to work together with the pending patch at
>>>
>>> <https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>?
>>>    (Yes, we have stuff all over the place and it's not easy to find it.
>>> Our bad.)
>>>
>>> About the contributor agreement: in the past we used something like
>>> the document I'm attaching.  You can scan the signed document and send
>>> it to me and Ferdinando (whose address is in cc).
>>>
>>> Thanks,
>>>       Luigi
>>>
>>>
>>> On Fri, Oct 19, 2012 at 3:22 PM, Riccardo Ghetta <rg...@la...> wrote:
>>>> Hi,
>>>> I've just posted a patch to enable thread safe session handling.  It
>>>> should also solve bug 3441748.
>>>> The company I work for, Thema Consulting SA (www.themaconsulting.ch),
>>>> uses QuantLib in its MasterFinance product and has other patches we like
>>>> to contribute back (as soon they're cleared by management/legal).
>>>>
>>>> BTW, is the contributor agreement needed ? Where should be sent ?
>>>> I searched the mailing list, but without luck.
>>>>
>>>> Ciao,
>>>> Riccardo Ghetta
>>>> Thema Consulting SA
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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_sfd2d_oct
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>

Re: [Quantlib-dev] Black Vega

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

Fixed, thanks.

Luigi

On Mon, Nov 26, 2012 at 4:39 PM, Luigi Ballabio
<lui...@gm...> wrote:
> Yes, you're correct.  I'll fix it.
>
> Luigi
>
>
> On Mon, Nov 12, 2012 at 11:49 AM, Peter Caspers <pca...@gm...> wrote:
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> 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] Black Vega

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

Yes, you're correct.  I'll fix it.

Luigi


On Mon, Nov 12, 2012 at 11:49 AM, Peter Caspers <pca...@gm...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> 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] thread safe session handling via TSS

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

It might be reasonable. But as mortoray argued, one might want to
switch between the two possibilities without recompiling; especially
those that don't compile the library and get it packaged from a Linux
distribution.  If we provide such a switch, linking libboost_thread
would be required anyway.  What do you think?

A future possibility would be to rework mortoray's patch so that the
pluggable function returns the instance directly instead of an integer
id; in such an implementation, your technique would just provide a
particular function.  However, that's not backward compatible...

Luigi


On Tue, Oct 23, 2012 at 3:43 PM, Riccardo Ghetta <rg...@la...> wrote:
> Not directly, no.
> I've looked at mortoray patch. Unfortunately that scheme is not compatible
> with thread storage;  having a per-thread instance makes all the
> sessionId/sessionIdFunc machinery useless.  In a way, is implicitly handled.
> Likewise for the instances_ map.
>
> On the other hand, perhaps I can rework the tss patch to avoid including
> boost thread headers in singleton.hpp, if we don't want to force quantlib
> users to compile with boost:thread.
> That should preserve the main qualities of the above patch, i.e. being
> thread-safe and not requiring libboost_thread, plus the added safety,
> simplicity and performance of tss.
>
> it might be a reasonable solution ?
> Ciao,
>
> R
>
>
> -------- Original Message --------
> Subject: Re: [Quantlib-dev] thread safe session handling via TSS
> From: Luigi Ballabio <lui...@gm...>
> To: Riccardo Ghetta <rg...@la...>
> CC: qua...@li..., Ferdinando Ametrano
> <na...@am...>
> Date: Tuesday, October 23, 2012 12:10:59
>>
>> Riccardo,
>>
>>     I just had a look at your patch.  Is there any chance that it can
>> be made to work together with the pending patch at
>>
>> <https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>?
>>   (Yes, we have stuff all over the place and it's not easy to find it.
>> Our bad.)
>>
>> About the contributor agreement: in the past we used something like
>> the document I'm attaching.  You can scan the signed document and send
>> it to me and Ferdinando (whose address is in cc).
>>
>> Thanks,
>>      Luigi
>>
>>
>> On Fri, Oct 19, 2012 at 3:22 PM, Riccardo Ghetta <rg...@la...> wrote:
>>>
>>> Hi,
>>> I've just posted a patch to enable thread safe session handling.  It
>>> should also solve bug 3441748.
>>> The company I work for, Thema Consulting SA (www.themaconsulting.ch),
>>> uses QuantLib in its MasterFinance product and has other patches we like
>>> to contribute back (as soon they're cleared by management/legal).
>>>
>>> BTW, is the contributor agreement needed ? Where should be sent ?
>>> I searched the mailing list, but without luck.
>>>
>>> Ciao,
>>> Riccardo Ghetta
>>> Thema Consulting SA
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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_sfd2d_oct
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

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

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

Oh, I see. You had sent this to the mailing list already.  I got a
very similar email recently that was sent to me directly, and when I
saw yours I mixed them up.  Sorry, I made a fool of myself again.

Folks, word of advice: write to the mailing list as Theo did.

Later,
    Luigi


On Mon, Nov 26, 2012 at 3:31 PM, Luigi Ballabio
<lui...@gm...> wrote:
> Theo,
>     just to check: I'm not sure that the forward option implemented in
> forwardengine.hpp is what you mean as "an option on a forward".  What
> it prices is an option whose strike will be fixed at a later time as a
> percentage of the forward price. For instance, when we close the deal
> today we agree that the maturity will be in 9 months, and the strike
> will be 90% of the underlying price in 3 months.  Three months from
> today, we observe the underlying price, we calculate the strike
> accordingly, and from that point hence the option is a normal one.  Is
> this what you had in mind?
>
> Also, I'd like to post the answer to the mailing list as well, since
> it might be useful to others.  Should I remove your name and/or
> address before doing so?
>
> Later,
>     Luigi
>
>
> On Thu, Nov 15, 2012 at 11:29 AM, Theo Boafo <tb...@ao...> wrote:
>> 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

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

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

Hi Sebastian,
    the problem is that we'd like to provide the means to build a
custom leg more or less manually, and that can play havoc with the
types as set in a hierarchy.  For instance, if one wants to create a
fixed-to-floater leg and writes:

Leg l = FloatingRateLeg(...);
l[0] = shared_ptr<CashFlow>(new FixedRateCoupon(...));

then you'd have something which is a floating-rate leg in type, but
not in reality.  Trying to prevent this would lead to restrict too
much (in my opinion, at least) the interface of Leg.  Actually, I
don't even think I would want to prevent the above code...

Luigi



On Sun, Nov 18, 2012 at 10:37 PM, Sebastian Poloczek
<Seb...@gm...> wrote:
>
> 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.
>
>
> ------------------------------------------------------------------------------
> 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

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

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

Theo,
    just to check: I'm not sure that the forward option implemented in
forwardengine.hpp is what you mean as "an option on a forward".  What
it prices is an option whose strike will be fixed at a later time as a
percentage of the forward price. For instance, when we close the deal
today we agree that the maturity will be in 9 months, and the strike
will be 90% of the underlying price in 3 months.  Three months from
today, we observe the underlying price, we calculate the strike
accordingly, and from that point hence the option is a normal one.  Is
this what you had in mind?

Also, I'd like to post the answer to the mailing list as well, since
it might be useful to others.  Should I remove your name and/or
address before doing so?

Later,
    Luigi


On Thu, Nov 15, 2012 at 11:29 AM, Theo Boafo <tb...@ao...> wrote:
> 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

[Quantlib-dev] Simulating Heston/Bates processes

[P. H. <pat...@ke...>]

Hello,

I'm interested in simulating processes in the heston/bates family.

An issue comes up when trying to simulate the Bates double exponential 
process, or the Bates process with deterministic jumps, because these 
processes are defined as models, not processes (the models use the 
regular heston and bates processes, with extra features that are defined 
in the model).

As a result, the path generator logic (see the Examples/DiscreteHedging 
for example) cannot be used. Does anyone know how to adress this issue, 
and simulate a stochastic process that is defined in a model class?

Thanks in advance,

-- 
Patrick Hénaff
T: +33 (0)1 70 29 47 53
    +33 (0)2 98 82 09 79
M: +33 (0)6 01 30 13 67
skype: pahenaff

[Quantlib-dev] Lazy Calibration Helper

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

Hi Luigi,

if I understand it correctly a CalibrationHelper observes its market 
data and triggers the market price calculation every time this data 
changes directly via the update() method. Doesn't that mean that the 
yield term structure feeded into a calibrationhelper will effectively 
loose its lazy behaviour? At least I have code that makes problems and I 
think the reason is exactly this. My solution would be as follows:

Make the CalibrationHelper lazy by virtual inheritance to Observer and 
LazyObject by defining:

class CalibrationHelper : public virtual Observer, public Observable, 
public virtual LazyObject {

...

void performCalculations() const {
    marketValue_ = blackPrice(volatility_->value());
}

void update() {
    LazyObject::update();
}

//! returns the actual price of the instrument (from volatility)
Real marketValue() const { calculate(); return marketValue_; }

...

This solves my problem. The testsuite seems to run with that change 
without problems.

What do you think ? Good idea or bad idea ?

Thanks a lot and kind regards
Peter

[Quantlib-dev] Fwd: Lagrange Spline

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

maybe better with checking the number of given points ...
Peter

---------- Forwarded message ----------
From: Peter Caspers <pca...@gm...>
Date: 2012/11/22
Subject: Lagrange Spline
To: qua...@li...


Hi,

I added the missing Lagrange boundary condition to the cubic interpolation.
I tested against the MatLab implementation. Please feel free to add it to
some future release.

Kind regards
Peter

[Quantlib-dev] Lagrange Spline

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

Hi,

I added the missing Lagrange boundary condition to the cubic 
interpolation. I tested against the MatLab implementation. Please feel 
free to add it to some future release.

Kind regards
Peter

Re: [Quantlib-dev] CDS last period

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

Hi Peter,
Great, thanks for setting up the code. 
Also, can you change the constructors to this one pls, used the wrong variable in the previous one.
Best regards
Pepe


----- Original Message -----
From: "Peter Caspers" <pca...@gm...>
To: ja...@fr...
Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
Sent: Monday, 19 November, 2012 8:45:55 PM
Subject: Re: [Quantlib-dev] CDS last period


Hi Pepe, 

thanks for your feedback. I will try to merge your code in a separate commit, so one can compare the approaches on github and discuss the pros and cons. 


Just a few comments why I did it how I did it: 


If you set up a full coupon CDS with upfront (using the second constructor), the real upfront date and amount is taken into account. In case it lies in the future, you will get the accrual rebate npv from the pricing engines as an additional result, that doesn't hurt. In case it is in the past, you will get zero upfront npv and zero accrual rebate npv, which is fine, too. 

If you set up the same CDS without upfront information (using the first constructor), then the accrual rebate npv is computed as if trading in the position on the evaluation date. Since this is only an additional information, this should not be irritating. Furthermore, for the fair spread result it is very reasonable to take into account the rebate npv because otherwise you can not compare it to traded spreads (this indeed is not achieved in the case above when the upfront date is explicitly given and lies in the past - one could think about making this more consistent ... or just leave that as it is ... ? ). 

However, there is a bug in my code, because the accrual rebate computation only works if the first period of the CDS is the current one (line 65 in the midpoint engine and similar in the integral engine). I will have to fix that. 

Concerning the default lookback I explicitly added a comment concerning the protection start parameter, i.e. that it does not refer to the legal protection start but rather the "pricing" protection start. That is indeed important. 

Concerning the day counter, of course, why not. On the other hand the actual360(inc) is the only example I needed so far. But again, why not. 


Thanks again and kind regards 
Peter 



2012/11/19 < 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). 

Re: [Quantlib-dev] Cashflows accrued methods

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

Fixed in subversion.

Thanks,
    Luigi


On Wed, Oct 3, 2012 at 5:11 PM, Luigi Ballabio <lui...@gm...> wrote:
> Yes, you're right.  Thanks for the heads-up.
>
> Luigi
>
> On Mon, Sep 17, 2012 at 10:06 PM, Peter Caspers <pca...@gm...> wrote:
>> Hi Luigi, Nando,
>>
>> the methods Cashflows::accruedPeriod(), accruedDays() and accruedAmount()
>> default the settlementDate to Date(), which I guess should mean to take the
>> evaluation date as the settlement date. However this does not work with the
>> methods in Coupon invoked from here. As a result 0.0 is returned always,
>> when no settlement date is specified.
>>
>> I think therefore that
>>
>> if (settlementDate == Date())
>>        settlementDate = Settings::instance().evaluationDate();
>>
>> should be added to the methods mentioned above. I observe this in 1.1.
>>
>> Regards
>> 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 lballabio
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: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mateusz Kapturski (fenixcitizen)
>Assigned to: Luigi Ballabio (lballabio)
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: Luigi Ballabio (lballabio)
Date: 2012-11-21 01:26

Message:
Mateusz,
    I've added your code to the repository.  I've made a few refactorings
to make it more in line with the style we've been using in the library, so
you might want to check that everything still works.  In particular:

- I've replaced the use of boost::random with our mersenne-twister
generator;
- I've turned the configuration class into an inner class;
- I've removed setters, which don't play well with observability;
- I've removed pointer data members;
- plus some minor cleanup.

Thanks,
    Luigi


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

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

Re: [Quantlib-dev] CDS last period

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

Hi Pepe,
thanks for your feedback. I will try to merge your code in a separate 
commit, so one can compare the approaches on github and discuss the pros 
and cons.
Just a few comments why I did it how I did it:
If you set up a full coupon CDS with upfront (using the second 
constructor), the real upfront date and amount is taken into account. In 
case it lies in the future, you will get the accrual rebate npv from the 
pricing engines as an additional result, that doesn't hurt. In case it 
is in the past, you will get zero upfront npv and zero accrual rebate 
npv, which is fine, too.
If you set up the same CDS without upfront information (using the first 
constructor), then the accrual rebate npv is computed as if trading in 
the position on the evaluation date. Since this is only an additional 
information, this should not be irritating. Furthermore, for the fair 
spread result it is very reasonable to take into account the rebate npv 
because otherwise you can not compare it to traded spreads (this indeed 
is not achieved in the case above when the upfront date is explicitly 
given and lies in the past - one could think about making this more 
consistent ... or just leave that as it is ... ? ).
However, there is a bug in my code, because the accrual rebate 
computation only works if the first period of the CDS is the current one 
(line 65 in the midpoint engine and similar in the integral engine). I 
will have to fix that.
Concerning the default lookback I explicitly added a comment concerning 
the protection start parameter, i.e. that it does not refer to the legal 
protection start but rather the "pricing" protection start. That is 
indeed important.

Concerning the day counter, of course, why not. On the other hand the 
actual360(inc) is the only example I needed so far. But again, why not.

Thanks again and kind regards
Peter


2012/11/19 <ja...@fr... <mailto: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).