quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] QuantLibXL not working with Excel 2007 ?

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

Hi all,

QuantLibXL compiled successfully with MSVC 2008  and boost  1.40.
But the addin cannot be loaded by Excel 2007.  It gives the error 
message R6043 Runtime Error.

Did anybody succesfully load the addin in EXCEl 2007?


Best regards,
Kim Tang

Re: [Quantlib-dev] Dates

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

I like it very much. Makes the constructors more compact, in particular
when FX markets are covered, as you mentioned. Do you have an official
source about these conventions?

I quite like the index classes and think something similar for other markets
would be nice. I think some function which returns a schedule according to
the
date offset would be nice. For example

boost::shared_ptr<Schedule> makeSchedule(Date start, Period p, Size times)

e.g. from start advance 6 Months and apply the date offset. do this "times"
times.
This should work backwards from start too

Do you think it would make sense to add an optional daycounter to a class
like
StandardPeriodOffset?



2009/9/25 <s.i...@gm...>

> Hi Dima,
>
> Okay, the concept is to separate the dates that we need for our
> calculations from the market conventions required to calculate those dates.
> In other words, why should the instruments need to know the conventions that
> apply for a given market?
>
> We could simply just pass the dates instead of the logic, but we can't do
> that in many instances (e.g. for market data purposes) or simply don't want
> to (calculating fixing dates, ex-div dates).
>
>
> First, I'll show a few simple examples of the functionality that a
> DateOffset could do.
>
> //base class
> class DateOffset {
>
>   public:
>     virtual Date operator() (const Date&) const = 0;
>
>     virtual Date reversed(const Date& endDate) const {
>         Date workingDate(endDate);
>         while( operator()(workingDate) != endDate) {
>             --workingDate;
>     }
> };
>
> The reversed() function should also be overridden but below I've
> concentrated on the initial date offset operator.
>
>
> //a trivial example - simply moves the original date by a set number of
> calendar days
> class CalendarDaysOffset : public DateOffset {
>
>   public:
>     CalendarDaysOffset(Natural days) : days_(days) {}
>
>     virtual Date operator() (const Date& initialDate) const { //derived
> from the base class
>         return (initialDate + days_);
>     }
>
>   private:
>     Natural days_;
> };
>
> //a standard period, which can be adjusted using a calendar and a roll
> convention.
> class StandardPeriodOffset : public DateOffset {
>
>   public:
>     StandardPeriodOffset(const Period& period,
>             const Calendar& calendar,
>             BusinessDayConvention convention)
>         : period_(period), calendar_(calendar), convention_(convention) {}
>
>     Date operator() (const Date& initialDate) const {
>         return ( calendar_.adjust(initialDate + period_, convention) );
>     }
>   private:
>     Period period_;
>     Calendar calendar_;
>     BusinessDayConvention convention_;
> };
>
> //a fixed date
> class FixedDate : public DateOffset {
>
>   public:
>     FixedDate(const Date& fixedDate)
>     : fixedDate_(fixedDate) {}
>
>     Date operator() (const Date& ) {
>         return fixedDate_;
>     }
>
>   private:
>     Date fixedDate_;
> };
>
> //standard FX rule
> class StandardFXSpotOffset : public DateOffset {
>
>   public:
>     StandardFXSpotOffset(const Calendar& firstCalendar,
>                                                   const Calendar&
> secondCalendar,
>                                                   Natural spotDays,
>                                                   const Calendar&
> thirdCalendar = USDCalendar() )
>     : firstCalendar_(firstCalendar), secondCalendar_(secondCalendar),
> thirdCalendar_(thirdCalendar), spotDays_(spotDays) { }
>
>     Date operator() (const Date& initialDate) {
>
>         Date workingDate(initialDate);
>         Date spot2(initialDate);
>         workingDate = firstCalendar_.advance(workingDate, spotDays, Days);
>         spot2 = secondCalendar_.advance(spot2, spotDays, Days);
>         workingDate = spot2 > workingDate ? spot2 : workingDate;
>         while(!thirdCalendar_.isBusinessDay(workingDate) ) {
>             ++workingDate;
>         }
>         return workingDate;
>     }
>   private:
>     Calendar firstCalendar_, secondCalendar_, thirdCalendar_;
>     Natural spotDays_;
> };
>
> //so that multiple rules can be applied consecutively.
> class MultiOffset : public DateOffset {
>
>   public:
>     MultiOffset(const std::vector<boost::shared_ptr<DateOffset> >&
> dateOffsets)
>     : dateOffsets_(dateOffsets) {}
>
>     Date operator() (const Date& initialDate) {
>         Date workingDate = initialDate;
>         for(Size i=0; i < dateOffsets_.size(); ++i) {
>             workingDate = (*dateOffsets[i])(workingDate);
>         }
>         return workingDate;
>     }
>
>   private:
>     std::vector<boost::shared_ptr<DateOffset> > dateOffsets_;
> };
>
>
> Now, here's an example with a money-market instrument (I know there isn't
> one in QuantLib at the moment).
>
> class CashMM : public Instrument {
>
>   public:
>     CashMM( const Date& tradeDate,
>             boost::shared_ptr<DateOffset>& spotOffset,
>             boost::shared_ptr<DateOffset>& maturityOffsetFromSpot,
>             Rate cashRate,
>             //+ other parameters);
> };
>
>
> The DateOffset class does not increase the current functionality as cash
> instruments have standard rules.
> However, here's an example which would benefit from a more generic method
> as there are so many different rules for calculating the spot date and
> fixing dates within the FX market.
>
> class FXNonDeliverable {
>
>   public:
>     FXNonDeliverable( const Date& tradeDate,
>             boost::shared_ptr<DateOffset>& spotOffset,
>             boost::shared_ptr<DateOffset>& maturityOffset,
>             boost::shared_ptr<DateOffset>& fixingOffset
>             Rate contractFX {
>                  settlementDate_ =
> (*maturityOffset)(spotOffset(tradeDate));
>                  fixingDate_ =  fixingOffset->reversed(settlementDate);
>              }
> };
>
>
> And you can imagine a dynamically generated Schedule created from a generic
> set of rules, which would only need a single date as an input. This would
> mean that market data instruments could be regenerated extremely easily.
>
>
> The final piece in the jigsaw would be to attach these DateOffset class
> objects to the markets whose conventions are represented.
>
> eg. GBPEUR FX market uses the standard FX spot calculation with 2 spot
> days.
>        EURRUB FX market uses 1 spot day and the USD calendar is ignored.
>
>
> leading to constructors such as:
>
> EuropeanOption(const Date& expiryDate, const OptionMarket& optionMarket);
>
> where from the expiryDate(or a tenor) the settlement date, the reference
> settlement date (for non-deliverables), the underlying period (for rates)
> etc. can all be calculated using the OptionMarket  - which may be an
> EquityOptionMarket, a SwaptionMarket etc.
>
> We do something very similar for indices - so why not extend the concept?
>
> Simon
>
>
> ---
>
> Sent from my BlackBerry® wireless device
> ------------------------------
> *From: * Dima <dim...@go...>
> *Date: *Fri, 25 Sep 2009 14:42:00 +0200
> *To: *<s.i...@gm...>
> *Cc: *<qua...@li...>
> *Subject: *Re: [Quantlib-dev] Dates
>
>
> Simon. Can you give a little example how this could look like for a simple
> class?
>
>
>
>
> 2009/9/25 <s.i...@gm...>
>
>> Hi folks,
>>
>> I've been looking at the QuantLib constructors and have a feeling that
>> something better could be done regarding periods.
>>
>> Lots of the constructors have elements that ask for "number of days" or
>> "day offset", then date rule and holiday calendar - sometimes for several
>> different days - that it becomes confusing.
>>
>> For bonds (which I've helped in developing) the rules for ex-div days are
>> complicated. Also, for FX the rules for determining the spot date from
>> today's date or the expiry date from the settlement date can be exceedingly
>> complicated.
>>
>> Why don't we have a DateOffset class (a base class) that can act as this
>> function?
>>
>> So, when we need to obtain one date from another, we simply apply the
>> DateOffset (which can contain a holiday calendar / many holiday calendars)
>> to the initial date and obtain the relevant date - without needing to know
>> what those rules are.
>>
>> These DateOffset objects could then be obtained from a relevant market
>> (such as the LiborIndex objects we already have) and applied to a given
>> instrument. This would be particularly useful for interest-rate and FX
>> markets. For equity / credit markets (where there are a huge number of
>> underlyings) this information would have to be derived externally to
>> QuantLib - but the interfaces would be much cleaner.
>>
>> In other words, we decouple the market conventions from the instruments
>> that are traded on those markets.
>>
>> I know that this would be a major project to apply throughout QuantLib,
>> but that's no reason not to create this functionality and to encourage its
>> use in new developments / changes.
>>
>> Thoughts please?
>>
>> Cheers,
>> Simon
>>
>>
>> Sent from my BlackBerry® wireless device
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>
>

Re: [Quantlib-dev] The Null<> Class

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

I still think we need a little wrapper instead of the pure optional class.
It is not convenient to dereference the optional object in the code by
writing

// -------------------------------------
optional<double> a(1.1);
double b=2.2;
double res;

QL_REQUIRE(a,"Empty a")
res=b*a.get();
// -------------------------------------

Would require a lot of rewriting of old Null class code too. How about the
following alternative:

 template <class Type>

 class Optional{
      public:

        Optional(){}
        Optional(Type val):val_(val) {}

        operator Type() const {
            return val_.get();
        }

        bool isEmpty() const{
            return !val_;
        }

        bool isInitialized() const{
            return !isEmpty();
        }

        void reset(const Type& val){
            val_.reset(val);
        }

        void reset(){
            val_.reset();
        }

        bool operator==(Type const& x){
            return x==val_;
        }

        bool operator==(Optional<Type> const& x){
            return x==val_;
        }

    private:
        boost::optional<Type> val_;
    };

Here, Optional has a cast operator to the template class. So we would
check isInitialized() and then use the class without dereferencing. Here is
some example code

    Optional<double> a(2.0);
    Optional<double> b;
    double c=1.1;

    std::cout << "------------" << std::endl;
    std::cout << "a empty:" << a.isEmpty() << std::endl;
    std::cout << "b empty:" << b.isEmpty() << std::endl;
    std::cout << "------------" << std::endl;
    std::cout << "a initialized:" << a.isInitialized() << std::endl;
    std::cout << "b initialized:" << b.isInitialized() << std::endl;
    std::cout << "------------" << std::endl;
    b.reset(c);
    std::cout << "b initialized:" << b.isInitialized() << std::endl;
    std::cout << "------------" << std::endl;
    b.reset();
    std::cout << "b initialized:" << b.isInitialized() << std::endl;
    std::cout << "------------" << std::endl;

    // simple multiplication, as if a is a double
    std::cout << "c*a: " << c*a << std::endl;

// comparison of a with a double
    a.reset(c);
    std::cout << "a==c: " << (a==c) << std::endl;


Gives

------------
a empty:0
b empty:1
------------
a initialized:1
b initialized:0
------------
b initialized:1
------------
b initialized:0
------------
c*a: 2.2
a==c: 1


A QuantLib rewriting example for the Instrument class:


// instead of
//---------------------------------------------------------------------------
public:
inline Instrument::Instrument()
    : NPV_(Null<Real>()), errorEstimate_(Null<Real>()) {}

private:
Real NPV_

 inline Real Instrument::NPV() const {
        calculate();
        QL_REQUIRE(NPV_ != Null<Real>(), "NPV not provided");
        return NPV_;
    }
//---------------------------------------------------------------------------

// Optional version
//---------------------------------------------------------------------------
public:
inline Instrument::Instrument(){} // no initialization of member needed

private:
// make NPV_ an Optional variable
Optional<Real> NPV_

 inline Real Instrument::NPV() const {
        calculate();
        QL_REQUIRE(NPV_.isInitialized(), "NPV not provided");
        return NPV_;
    }
//---------------------------------------------------------------------------


Of course, the Optional class has to be polished. Thoughts?



2009/9/25 Luigi Ballabio <lui...@gm...>

> On Fri, 2009-09-25 at 07:58 +0200, Jose Aparicio-Navarro wrote:
> > > > I'm aware of boost::optional and think it could be the way to go.
> > > > However, I don't see an easy way to incorporate it in the current
> Null
> > > > design.
> > >
> > > Neither do I. It would replace Null entirely.
> > >
> >
> > Should we start dropping Null<> and move to optional then?
>
> Moving to optional for new functionality---yes.
> Dropping Null in existing code---no. At this point we keep
> compatibility.
>
> Luigi
>
>
> --
>
> Green's Law of Debate:
> Anything is possible if you don't know what you're talking about.
>
>
>

[Quantlib-dev] Some more explanation about LongstaffSchwartz

[Andrea <mar...@go...>]

In ql/methods/montecarlo/longstaffschwartz.hpp at around line 155 there is the following code

             else {
             // if number of itm paths is smaller then the number of
             // calibration functions -> no early exercise
                 coeff_[i] = Array(v_.size(), 0.0);
             }

The array of coefficients is used at around line 113 & 164.
These are coefficients of a linear combination of basis functions

                     Real continuationValue = 0.0;
                     for (Size l=0; l<v_.size(); ++l) {
                         continuationValue += coeff_[i][l] * v_[l](x[k]);
                     }

so that if the array is full of 0.0, the continuation value is 0.0 as well.
Then, the check is

                     if (continuationValue < exercise[j]) {
                         prices[j] = exercise[j];
                     }

which implies exactly the opposite of what the comment says (exercise[j] is > 0.0)

This is not very important because it only happens for paths where the exercise is positive which 
were anyway very few.

I just find the comment misleading.

Re: [Quantlib-dev] Dates

[<s.i...@gm...>]

Hi Dima,

Okay, the concept is to separate the dates that we need for our calculations from the market conventions required to calculate those dates. In other words, why should the instruments need to know the conventions that apply for a given market? 
 
We could simply just pass the dates instead of the logic, but we can't do that in many instances (e.g. for market data purposes) or simply don't want to (calculating fixing dates, ex-div dates). 

 
First, I'll show a few simple examples of the functionality that a DateOffset could do. 
 
//base class 
class DateOffset { 
 
  public: 
    virtual Date operator() (const Date&) const = 0; 
 
    virtual Date reversed(const Date& endDate) const { 
        Date workingDate(endDate); 
        while( operator()(workingDate) != endDate) { 
            --workingDate; 
    } 
}; 
 
The reversed() function should also be overridden but below I've concentrated on the initial date offset operator. 
        
 
//a trivial example - simply moves the original date by a set number of calendar days 
class CalendarDaysOffset : public DateOffset { 
 
  public: 
    CalendarDaysOffset(Natural days) : days_(days) {} 
 
    virtual Date operator() (const Date& initialDate) const { //derived from the base class 
        return (initialDate + days_); 
    } 
 
  private: 
    Natural days_; 
}; 
 
//a standard period, which can be adjusted using a calendar and a roll convention. 
class StandardPeriodOffset : public DateOffset { 
 
  public: 
    StandardPeriodOffset(const Period& period, 
            const Calendar& calendar, 
            BusinessDayConvention convention) 
        : period_(period), calendar_(calendar), convention_(convention) {} 
 
    Date operator() (const Date& initialDate) const { 
        return ( calendar_.adjust(initialDate + period_, convention) ); 
    } 
  private: 
    Period period_; 
    Calendar calendar_; 
    BusinessDayConvention convention_; 
}; 
 
//a fixed date 
class FixedDate : public DateOffset { 
 
  public: 
    FixedDate(const Date& fixedDate) 
    : fixedDate_(fixedDate) {} 
 
    Date operator() (const Date& ) { 
        return fixedDate_; 
    } 
 
  private: 
    Date fixedDate_; 
}; 
 
//standard FX rule 
class StandardFXSpotOffset : public DateOffset { 
 
  public: 
    StandardFXSpotOffset(const Calendar& firstCalendar, 
                                                  const Calendar& secondCalendar, 
                                                  Natural spotDays, 
                                                  const Calendar& thirdCalendar = USDCalendar() ) 
    : firstCalendar_(firstCalendar), secondCalendar_(secondCalendar), thirdCalendar_(thirdCalendar), spotDays_(spotDays) { } 
 
    Date operator() (const Date& initialDate) { 
 
        Date workingDate(initialDate); 
        Date spot2(initialDate); 
        workingDate = firstCalendar_.advance(workingDate, spotDays, Days); 
        spot2 = secondCalendar_.advance(spot2, spotDays, Days); 
        workingDate = spot2 > workingDate ? spot2 : workingDate; 
        while(!thirdCalendar_.isBusinessDay(workingDate) ) { 
            ++workingDate; 
        } 
        return workingDate; 
    } 
  private: 
    Calendar firstCalendar_, secondCalendar_, thirdCalendar_; 
    Natural spotDays_; 
}; 
 
//so that multiple rules can be applied consecutively. 
class MultiOffset : public DateOffset { 
 
  public: 
    MultiOffset(const std::vector<boost::shared_ptr<DateOffset> >& dateOffsets) 
    : dateOffsets_(dateOffsets) {} 
 
    Date operator() (const Date& initialDate) { 
        Date workingDate = initialDate; 
        for(Size i=0; i < dateOffsets_.size(); ++i) { 
            workingDate = (*dateOffsets[i])(workingDate); 
        } 
        return workingDate; 
    } 
 
  private: 
    std::vector<boost::shared_ptr<DateOffset> > dateOffsets_; 
}; 
            
 
Now, here's an example with a money-market instrument (I know there isn't one in QuantLib at the moment). 
 
class CashMM : public Instrument { 
 
  public: 
    CashMM( const Date& tradeDate, 
            boost::shared_ptr<DateOffset>& spotOffset, 
            boost::shared_ptr<DateOffset>& maturityOffsetFromSpot, 
            Rate cashRate, 
            //+ other parameters);       
}; 
 
 
The DateOffset class does not increase the current functionality as cash instruments have standard rules. 
However, here's an example which would benefit from a more generic method as there are so many different rules for calculating the spot date and fixing dates within the FX market. 
 
class FXNonDeliverable { 
 
  public: 
    FXNonDeliverable( const Date& tradeDate, 
            boost::shared_ptr<DateOffset>& spotOffset, 
            boost::shared_ptr<DateOffset>& maturityOffset, 
            boost::shared_ptr<DateOffset>& fixingOffset 
            Rate contractFX { 
                 settlementDate_ = (*maturityOffset)(spotOffset(tradeDate)); 
                 fixingDate_ =  fixingOffset->reversed(settlementDate); 
             } 
}; 
 
 
And you can imagine a dynamically generated Schedule created from a generic set of rules, which would only need a single date as an input. This would mean that market data instruments could be regenerated extremely easily. 
 
 
The final piece in the jigsaw would be to attach these DateOffset class objects to the markets whose conventions are represented. 
 
eg. GBPEUR FX market uses the standard FX spot calculation with 2 spot days. 
       EURRUB FX market uses 1 spot day and the USD calendar is ignored. 
      
 
leading to constructors such as: 
 
EuropeanOption(const Date& expiryDate, const OptionMarket& optionMarket); 
 
where from the expiryDate(or a tenor) the settlement date, the reference settlement date (for non-deliverables), the underlying period (for rates) etc. can all be calculated using the OptionMarket  - which may be an EquityOptionMarket, a SwaptionMarket etc. 
 
We do something very similar for indices - so why not extend the concept? 
 
Simon 
 
 
 ---

Sent from my BlackBerry® wireless device

-----Original Message-----
From: Dima <dim...@go...>
Date: Fri, 25 Sep 2009 14:42:00 
To: <s.i...@gm...>
Cc: <qua...@li...>
Subject: Re: [Quantlib-dev] Dates

Simon. Can you give a little example how this could look like for a simple
class?




2009/9/25 <s.i...@gm...>

> Hi folks,
>
> I've been looking at the QuantLib constructors and have a feeling that
> something better could be done regarding periods.
>
> Lots of the constructors have elements that ask for "number of days" or
> "day offset", then date rule and holiday calendar - sometimes for several
> different days - that it becomes confusing.
>
> For bonds (which I've helped in developing) the rules for ex-div days are
> complicated. Also, for FX the rules for determining the spot date from
> today's date or the expiry date from the settlement date can be exceedingly
> complicated.
>
> Why don't we have a DateOffset class (a base class) that can act as this
> function?
>
> So, when we need to obtain one date from another, we simply apply the
> DateOffset (which can contain a holiday calendar / many holiday calendars)
> to the initial date and obtain the relevant date - without needing to know
> what those rules are.
>
> These DateOffset objects could then be obtained from a relevant market
> (such as the LiborIndex objects we already have) and applied to a given
> instrument. This would be particularly useful for interest-rate and FX
> markets. For equity / credit markets (where there are a huge number of
> underlyings) this information would have to be derived externally to
> QuantLib - but the interfaces would be much cleaner.
>
> In other words, we decouple the market conventions from the instruments
> that are traded on those markets.
>
> I know that this would be a major project to apply throughout QuantLib, but
> that's no reason not to create this functionality and to encourage its use
> in new developments / changes.
>
> Thoughts please?
>
> Cheers,
> Simon
>
>
> Sent from my BlackBerry® wireless device
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
>_______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Dates

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

Simon. Can you give a little example how this could look like for a simple
class?




2009/9/25 <s.i...@gm...>

> Hi folks,
>
> I've been looking at the QuantLib constructors and have a feeling that
> something better could be done regarding periods.
>
> Lots of the constructors have elements that ask for "number of days" or
> "day offset", then date rule and holiday calendar - sometimes for several
> different days - that it becomes confusing.
>
> For bonds (which I've helped in developing) the rules for ex-div days are
> complicated. Also, for FX the rules for determining the spot date from
> today's date or the expiry date from the settlement date can be exceedingly
> complicated.
>
> Why don't we have a DateOffset class (a base class) that can act as this
> function?
>
> So, when we need to obtain one date from another, we simply apply the
> DateOffset (which can contain a holiday calendar / many holiday calendars)
> to the initial date and obtain the relevant date - without needing to know
> what those rules are.
>
> These DateOffset objects could then be obtained from a relevant market
> (such as the LiborIndex objects we already have) and applied to a given
> instrument. This would be particularly useful for interest-rate and FX
> markets. For equity / credit markets (where there are a huge number of
> underlyings) this information would have to be derived externally to
> QuantLib - but the interfaces would be much cleaner.
>
> In other words, we decouple the market conventions from the instruments
> that are traded on those markets.
>
> I know that this would be a major project to apply throughout QuantLib, but
> that's no reason not to create this functionality and to encourage its use
> in new developments / changes.
>
> Thoughts please?
>
> Cheers,
> Simon
>
>
> Sent from my BlackBerry® wireless device
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] The Null<> Class

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

On Fri, 2009-09-25 at 07:58 +0200, Jose Aparicio-Navarro wrote:
> > > I'm aware of boost::optional and think it could be the way to go.
> > > However, I don't see an easy way to incorporate it in the current Null
> > > design.
> >
> > Neither do I. It would replace Null entirely.
> >
> 
> Should we start dropping Null<> and move to optional then?

Moving to optional for new functionality---yes.
Dropping Null in existing code---no. At this point we keep
compatibility.

Luigi


-- 

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

[Quantlib-dev] Dates

[<s.i...@gm...>]

Hi folks, 
 
I've been looking at the QuantLib constructors and have a feeling that something better could be done regarding periods. 
 
Lots of the constructors have elements that ask for "number of days" or "day offset", then date rule and holiday calendar - sometimes for several different days - that it becomes confusing. 
 
For bonds (which I've helped in developing) the rules for ex-div days are complicated. Also, for FX the rules for determining the spot date from today's date or the expiry date from the settlement date can be exceedingly complicated. 
 
Why don't we have a DateOffset class (a base class) that can act as this function? 
 
So, when we need to obtain one date from another, we simply apply the DateOffset (which can contain a holiday calendar / many holiday calendars) to the initial date and obtain the relevant date - without needing to know what those rules are. 
 
These DateOffset objects could then be obtained from a relevant market (such as the LiborIndex objects we already have) and applied to a given instrument. This would be particularly useful for interest-rate and FX markets. For equity / credit markets (where there are a huge number of underlyings) this information would have to be derived externally to QuantLib - but the interfaces would be much cleaner. 
 
In other words, we decouple the market conventions from the instruments that are traded on those markets. 
 
I know that this would be a major project to apply throughout QuantLib, but that's no reason not to create this functionality and to encourage its use in new developments / changes. 
 
Thoughts please? 
 
Cheers, 
Simon 
 

Sent from my BlackBerry® wireless device

Re: [Quantlib-dev] Any projects?

[Jose Aparicio-N. <ja...@fr...>]

Hi,

I am in to join forces for credit stuff, I am working on a couple of things now
and would like critics on the credit classes concepts.
My intention is to go all the 'standard' road on credit derivatives up to the
dynamical models. Also apply these to risk management (capital, etc...) Nathan
Abbott also started work on ABS/Mortgage pools, I think thats another important
line.

I am also trying to figure out the implications of the Big Bang issues, mainly
the default lookback period. If you had any thoughts on this (impact on events
and probability bootstrapping) please share them.

I have read some of the Brigo's work on counterparty but in the CDS context not
in the IRS context your talking about. Fine to be in to learn if u put up with
it, dont know how much help I could be if any.

Regards
Pepe





Quoting s.i...@gm...:

> No bites as yet. I thought potentially a HJM framework for FX/credit/IR
> hybrids such as CCDS (or to measure counterparty exposure). This could also
> be used for FX/IR hybrids with the judicious application of stoch-vol for the
> FX surface.
>
> However, I'm interested in any suggestions.
>
> Sent from my BlackBerry® wireless device
>
> -----Original Message-----
> From: Dima <dim...@go...>
> Date: Thu, 24 Sep 2009 10:19:09
> To: <s.i...@gm...>
> Cc: QuantLib developers<qua...@li...>
> Subject: Re: [Quantlib-dev] Any projects?
>
> Nobody biting with project ideas? This all sounds interesting Simon. We
> should tryto take care of potential new contributors
>
>
> 2009/9/19 <s.i...@gm...>
>
> > Hi folks,
> > I've contributed a few things before to QuantLib and find myself with a
> > little spare time on my hands. Is there anything that someone would like to
> > see added to QuantLib?
> > My background is as a quant with 8 years experience - in fixed-income,
> > credit and especially hybrids...
> > Any of that sound interesting?
> >
> > Cheers,
> > Simon
> >
> > Sent from my BlackBerry® wireless device
> >
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> > http://p.sf.net/sfu/devconf
> >_______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
>
>

Re: [Quantlib-dev] The Null<> Class

[Jose Aparicio-N. <ja...@fr...>]

> > I'm aware of boost::optional and think it could be the way to go.
> > However, I don't see an easy way to incorporate it in the current Null
> > design.
>
> Neither do I. It would replace Null entirely.
>

Should we start dropping Null<> and move to optional then?

Regards
Pepe

Re: [Quantlib-dev] Any projects?

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

On Thu, 2009-09-24 at 08:50 +0000, s.i...@gm... wrote:
> No bites as yet. I thought potentially a HJM framework for
> FX/credit/IR hybrids such as CCDS (or to measure counterparty
> exposure). This could also be used for FX/IR hybrids with the
> judicious application of stoch-vol for the FX surface.
> 
> However, I'm interested in any suggestions.

Simon,
	it's probably much less interesting than your proposal, but given your
experience in fixed income, you might have a look at the issues raised
on the QuantLib-users list by Mike Benson [1] and Sergey Andreyev [2].
Give them a shout if you decide to tackle either problem.

Thanks,
	Luigi

[1] <http://thread.gmane.org/gmane.comp.finance.quantlib.user/5980>
[2] <http://thread.gmane.org/gmane.comp.finance.quantlib.user/6056>



-- 

Poets have been mysteriously silent on the subject of cheese. 
-- Gilbert K. Chesterton 

Re: [Quantlib-dev] Optimizer Discussion

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

I'll try to code an alternative for one of the existing optimizers. This
will take
a while though since I've realized that they are tightly coupled with other
classes
such as Problem/EndCriteria, which makes it difficult to recode....I'll try
to set up
something simple and will post an example as soon as I have it.



2009/9/24 Luigi Ballabio <lui...@gm...>

> Dima,
>        looks ok. Would you be willing to code the new design? We could add
> it
> in a future release.
>
> Luigi
>
>
> On Sun, 2009-09-13 at 13:10 +0200, Dima wrote:
> > I'm not sure. I'm not happy with the whole setup, I think it is to
> > tightly
> > coupled. I'd prefer a design which is similar to the root solvers: you
> > don't need a class for an optimizer whith a "value" function. As in
> > the
> > root solver, it should be a template that has an operator(...), e.g. a
> > functor
> > or a boost function. Anything. Makes it much more convenient to use.
> > The optimizing criteria could go into the constructor, which takes
> > only the
> > criteria which it really uses. The start value could go into a
> > optimize function,
> > which takes a template. If we have a multidimensional setup as in the
> > LM
> > case, the template should return a std::vector<Real>
>
>
>
> --
>
> fix, n.,v.
> What one does when a problem has been reported too many times
> to be ignored.
> -- the Jargon file
>
>
>

Re: [Quantlib-dev] Optimizer Discussion

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

Dima,
	looks ok. Would you be willing to code the new design? We could add it
in a future release.

Luigi


On Sun, 2009-09-13 at 13:10 +0200, Dima wrote:
> I'm not sure. I'm not happy with the whole setup, I think it is to
> tightly
> coupled. I'd prefer a design which is similar to the root solvers: you
> don't need a class for an optimizer whith a "value" function. As in
> the
> root solver, it should be a template that has an operator(...), e.g. a
> functor
> or a boost function. Anything. Makes it much more convenient to use. 
> The optimizing criteria could go into the constructor, which takes
> only the
> criteria which it really uses. The start value could go into a
> optimize function, 
> which takes a template. If we have a multidimensional setup as in the
> LM
> case, the template should return a std::vector<Real>



-- 

fix, n.,v. 
What one does when a problem has been reported too many times 
to be ignored. 
-- the Jargon file 

Re: [Quantlib-dev] Any projects?

[<s.i...@gm...>]

No bites as yet. I thought potentially a HJM framework for FX/credit/IR hybrids such as CCDS (or to measure counterparty exposure). This could also be used for FX/IR hybrids with the judicious application of stoch-vol for the FX surface.

However, I'm interested in any suggestions.
 
Sent from my BlackBerry® wireless device

-----Original Message-----
From: Dima <dim...@go...>
Date: Thu, 24 Sep 2009 10:19:09 
To: <s.i...@gm...>
Cc: QuantLib developers<qua...@li...>
Subject: Re: [Quantlib-dev] Any projects?

Nobody biting with project ideas? This all sounds interesting Simon. We
should tryto take care of potential new contributors


2009/9/19 <s.i...@gm...>

> Hi folks,
> I've contributed a few things before to QuantLib and find myself with a
> little spare time on my hands. Is there anything that someone would like to
> see added to QuantLib?
> My background is as a quant with 8 years experience - in fixed-income,
> credit and especially hybrids...
> Any of that sound interesting?
>
> Cheers,
> Simon
>
> Sent from my BlackBerry® wireless device
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
>_______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Any projects?

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

Nobody biting with project ideas? This all sounds interesting Simon. We
should tryto take care of potential new contributors


2009/9/19 <s.i...@gm...>

> Hi folks,
> I've contributed a few things before to QuantLib and find myself with a
> little spare time on my hands. Is there anything that someone would like to
> see added to QuantLib?
> My background is as a quant with 8 years experience - in fixed-income,
> credit and especially hybrids...
> Any of that sound interesting?
>
> Cheers,
> Simon
>
> Sent from my BlackBerry® wireless device
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] New to QuantLib

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

On Mon, 2009-09-21 at 10:33 -0700, Abhishek Khemka wrote:
>  I would like to be a part of QuantLIb developement community. I have
> been a software developer for three years and would like to contribut
> to this project. Please let me know how can I get started and also
> some guidance about how can I understand the code base.

Abhishek,
	I see you've already been pointed to the new-developer page on the
QuantLib site.  Also, to help you understand the code base, you can have
a look at the docs (in progress) that I've published at
<http://luigi.ballabio.googlepages.com/qlbook>.

Luigi


-- 

Zawinski's Law: 
Every program attempts to expand until it can read mail. Those 
programs which cannot so expand are replaced by ones which can. 

Re: [Quantlib-dev] The Null<> Class

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

Luigi, I know that you're working on the 1.0 release and it wasn't meant
to go into the next release. I just wanted it to be on some to do list -
where
I'd be happy to contribute.

The shortcomings are not bad since it is probably used correctly in the
current library. However, some users might use the particular class- as
a standalone class- in their own applications and might not know about
the mentioned behavior. Also, other contributors might use it without
looking into the details and some errors can occurr, in particular in the
default constructor comparison. This is why I  proposed a temporary fix
until we have something better.

I'm aware of boost::optional and think it could be the way to go. However,
I don't see an easy way to incorporate it in the current Null design. I
think
it would have to be used directly such as in:

boost::optional<double> optVar;
QL_REQUIRE(optVar!=NULL,".....");
double var=*optVar;

Anyways, you might be busy with more important stuff. If you need help
to rewrite classes with boost::optional in the future, let me know.



2009/9/23 Luigi Ballabio <lui...@gm...>

> On Fri, 2009-09-18 at 15:58 +0200, Dima wrote:
> >
> > I had a closer look at it and would like to propose some changes.
>
> Dima,
>        I know, Null<> has a number of shortcomings.  But rather than trying
> to
> patch it, I'd replace it with boost::optional<> instead.
>
> The problem is, we're already late for the 1.0 train.  Over the next
> releases, I'll try to replace it in a few places where it doesn't break
> backward compatibility.  For the other places, I guess we'll wait for
> the next overhaul (2.0, probably in a few years.)  The shortcomings are
> not that bad anyway.
>
> Thoughts?
>        Luigi
>
>
> --
>
> Newton's Law of Gravitation:
> What goes up must come down. But don't expect it to come down
> where you can find it. Murphy's Law applies to Newton's.
>
>
>

Re: [Quantlib-dev] The Null<> Class

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

On Wed, 2009-09-23 at 15:48 +0200, Dima wrote:
> Luigi, I know that you're working on the 1.0 release and it wasn't
> meant to go into the next release. I just wanted it to be on some to
> do list - where I'd be happy to contribute.

Sure, I had taken it in this spirit. 

> I'm aware of boost::optional and think it could be the way to go.
> However, I don't see an easy way to incorporate it in the current Null
> design. 

Neither do I. It would replace Null entirely.

Luigi


-- 

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

Re: [Quantlib-dev] The Null<> Class

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

On Fri, 2009-09-18 at 15:58 +0200, Dima wrote:
> 
> I had a closer look at it and would like to propose some changes.

Dima,
	I know, Null<> has a number of shortcomings.  But rather than trying to
patch it, I'd replace it with boost::optional<> instead.  

The problem is, we're already late for the 1.0 train.  Over the next
releases, I'll try to replace it in a few places where it doesn't break
backward compatibility.  For the other places, I guess we'll wait for
the next overhaul (2.0, probably in a few years.)  The shortcomings are
not that bad anyway.

Thoughts?
	Luigi


-- 

Newton's Law of Gravitation: 
What goes up must come down. But don't expect it to come down 
where you can find it. Murphy's Law applies to Newton's. 

[Quantlib-dev] CDS stubs schedules rule

[Jose Aparicio-N. <ja...@fr...>]

Hi all,
The long/short stub CDS rule (since the "big bang" aka 'old' CDS rule) states
that: (quoting MarkIt docs)

<<
If the trade date falls before 30 days before the first coupon date, the
accrual is due on the first coupon date for the number of days of effective
protection during the period. This is called a “short stub” period. If the
trade date is within 30 days before the first coupon date, there is a “long
stub period”.
No accrual of premium is paid on this first IMM coupon date, rather the long
stub is paid on the following coupon date. That payment will include the
portion of premium owed for protection in the first period plus the full
premium for the second period.
>>

Long stub meaning then a coupon larger thant the CDS tenor.
Ironically, with the big bang, this will no longer be the way the quoted CDS
will have the coupons generated in the US. Still, it is relevant for on the
run positions and non-US ones (though they might change too). But thats another
issue for another post.
This rule makes fwd spreads jump around the cds imm dates, with the effect on
options.

So far I have been using the 20thIMM rule which matches this rule in the short
stub case only.
I have added a new rule to account for the long stub.

For frequencies other than the 'usual' ones I do not think the rule makes sense
(think say, 10days). The stub rule was intended to make the coupon dates
homogeneous. So I have (arbitrarily) chosen to revert to the short stub in
that case. Another alternative is a QL_REQUIRE at the beginning of the Schedule
creation method refusing to take that combination.


I have also forced unadjustment on the first schedule date in this case since
theres no particular convention variable for that date. If we want a convention
on the startDate we pass it already adjusted (as it is done in the helpers).


Another small change I would like to request is for the cds helpers not to
adjust the final protection date accrual, which is the default convention (the
swaps will still adjust the final payment date when building the leg). They
would look like this:

   96     void CdsHelper::initializeDates() {
   97         Date protectionStart_ = evaluationDate_ + settlementDays_;
   98         Date startDate = calendar_.adjust(protectionStart_,
   99                                           paymentConvention_);
  100         Date endDate = evaluationDate_ + tenor_;
  101
  102         schedule_ =
  103             MakeSchedule().from(startDate)
  104                           .to(endDate)
  105                           .withFrequency(frequency_)
  106                           .withCalendar(calendar_)
  107                           .withConvention(paymentConvention_)
  >>>>>>>>>                     .withTerminationDateConvention(Unadjusted) <<<<
  108                           .withRule(rule_);
  109         earliestDate_ = schedule_.dates().front();
  110         latestDate_   = schedule_.dates().back();
  111     }

Alternatively we could have another convention variable in the helper
constructor.
Maybe the rule should be called 20thCDSstub or something different....

Tell me what you think.
Best regards
Pepe

--
Impacted files:
dategenerationrule.Xpp
schedule.cpp

Re: [Quantlib-dev] Patch to exposure to QuantLibXL a few more functions of InterestRate object

[Ferdinando A. <qf...@am...>]

On Mon, Sep 21, 2009 at 8:43 PM, Eric Ehlers <eri...@na...> wrote:
> Sorry for the delay in my reply - I will have a look at it before the
> next release goes out.  Thanks Piter.

Thank you Eric, but I will probably commit it tomorrow. It's taken a
while just because it triggered some InterestRate clean up.

ciao -- Nando

Re: [Quantlib-dev] Patch to exposure to QuantLibXL a few more functions of InterestRate object

[Eric E. <eri...@na...>]

Quoting Luigi Ballabio <lui...@gm...>:

> On Fri, 2009-09-18 at 18:31 -0300, Piter Dias wrote:
>> I made a patch (just XML changes) in order to exposure to below
>> functions to QuantLibXL. [...]
>>
>>       * qlInterestRateImpliedRate - Returns the implied rate between
>>         two dates based on the given a compound factor
>>       * qlInterestRateDiscountFactor - Returns the discount factor
>>         between two dates based on the given InterestRate object
>>       * qlInterestRateCompoundFactor - Returns the compound factor
>>         between two dates based on the given InterestRate object
>>
>> I hope it is useful enough to go to trunk.
>
> I think so, but I'll leave that to the QuantLibXL people.

Sorry for the delay in my reply - I will have a look at it before the  
next release goes out.  Thanks Piter.

Regards,
Eric

[Quantlib-dev] New to QuantLib

[Abhishek K. <abh...@gm...>]

Hi,

 I would like to be a part of QuantLIb developement community. I have been a
software developer for three years and would like to contribut to this
project. Please let me know how can I get started and also some guidance
about how can I understand the code base.

Thanks
Abhishek

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[16484] trunk/QuantLib/ql/pricingengines/bond/ bondfunctions.cpp

[Ferdinando A. <na...@am...>]

On Mon, Sep 21, 2009 at 4:02 PM, Luigi Ballabio
<lui...@gm...> wrote:
>> fixed bug: InterestRate non-explicit constructor was used instead of input parameters
>
> Ouch. We should prevent this---either by making it explicit or by
> removing the default day counter. Which one do you prefer?

remove default parameters.
I was going to commit Piter's contribution, and while exposing the
full interface to Excel I noticed a couple of glitches: I'm fixing
them and will commit today or tomorrow.

ciao -- Nando

-- 
RSS feed: http://www.google.com/reader/shared/ferdinando.ametrano

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[16484] trunk/QuantLib/ql/pricingengines/bond/ bondfunctions.cpp

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

On Mon, 2009-09-21 at 13:37 +0000, na...@us... wrote:
> Revision: 16484
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=16484&view=rev
> Author:   nando
> Date:     2009-09-21 13:37:45 +0000 (Mon, 21 Sep 2009)
> 
> Log Message:
> -----------
> fixed bug: InterestRate non-explicit constructor was used instead of input parameters

Ouch. We should prevent this---either by making it explicit or by
removing the default day counter. Which one do you prefer?

Luigi


-- 

Ninety percent of everything is crap. 
--- Theodore Sturgeon