Re: [QuantLib-svn] SF.net SVN: quantlib: [13854] trunk/QuantLib/ql/interestrate.hpp

[Luigi Ballabio]

On Dec 19, 2007, at 8:02 PM, [hidden email] wrote:

> Log Message:
> -----------
> added default parameters
>
> @@ -45,8 +45,8 @@
>          InterestRate();
>          //! Standard constructor
>          InterestRate(Rate r,
> -                     const DayCounter& dc,
> -                     Compounding comp,
> +                     const DayCounter& dc = Actual365Fixed(),
> +                     Compounding comp = Continuous,
>                       Frequency freq = Annual);
>          //@}
>          //! \name conversions

Nando,
        somehow I can see that the compounding may default to Continuous, but
why should the day-count convention default to actual/365?

Later,
        Luigi


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

On Dec 20, 2007 11:11 PM, Luigi Ballabio <[hidden email]> wrote:

> > Log Message:
> > -----------
> > added default parameters
> >
> > @@ -45,8 +45,8 @@
> >          InterestRate();
> >          //! Standard constructor
> >          InterestRate(Rate r,
> > -                     const DayCounter& dc,
> > -                     Compounding comp,
> > +                     const DayCounter& dc = Actual365Fixed(),
> > +                     Compounding comp = Continuous,
> >                       Frequency freq = Annual);
> >          //@}
> >          //! \name conversions
>
> Nando,
>         somehow I can see that the compounding may default to Continuous, but
> why should the day-count convention default to actual/365?

Actual/365Fixed is the default DayCounter we use in all
TermStructures, in order to minimize the inconsistency risk of using
different DayCounters for differerent (vol/yield) TermStructures.

In few places InterestRate is used to define a FlatForward and its
DayCounter is used as the YieldTermStructure's DayCounter, so I
default it to Actual365Fixed. Besides this is the usual assumption in
the textbook examples (e.g. Hull), where you would want 5 years to be
5.0 (and for this reason ActualActual::ISDA would be even better...)

Actually any strictly monotone DayCounter (Actual360, Actual/365Fixed,
ActualActual::ISDA) would be ok as default DayCounter for
TermStructures.
It's quite a while that I've been considering to define the default
DayCounter in userconfig.hpp (and switch to ActualActual::ISDA in the
meantime): any objection if I do it?

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Wed, 2008-01-02 at 11:15 +0100, Ferdinando Ametrano wrote:
> >         somehow I can see that the compounding may default to Continuous, but
> > why should the day-count convention default to actual/365?
>
> Actual/365Fixed is the default DayCounter we use in all
> TermStructures, in order to minimize the inconsistency risk of using
> different DayCounters for differerent (vol/yield) TermStructures.

Is it? I'm not sure that we should use a default day counter for the
term structures that require one.  If anything, it _increases_ the
inconsistency risk---if the user sets the day counter to one curve and
not to the other, he'll (silently) get two curves with different day
counters. It would be safer to have him specify both explicitly.


> In few places InterestRate is used to define a FlatForward and its
> DayCounter is used as the YieldTermStructure's DayCounter, so I
> default it to Actual365Fixed.

Yes, but that's not the only effect of the default. It affects all
InterestRate instances, flat forward or not.


> Besides this is the usual assumption in
> the textbook examples (e.g. Hull), where you would want 5 years to be
> 5.0 (and for this reason ActualActual::ISDA would be even better...)

...since it doesn't hold for act/365.


> It's quite a while that I've been considering to define the default
> DayCounter in userconfig.hpp (and switch to ActualActual::ISDA in the
> meantime): any objection if I do it?

Yes--I don't like it :)  I'd rather have no default at all.

Later,
        Luigi


--

Things should be made as simple as possible, but no simpler.
-- Albert Einstein



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

On Jan 2, 2008 3:59 PM, Luigi Ballabio <[hidden email]> wrote:
> > It's quite a while that I've been considering to define the default
> > DayCounter in userconfig.hpp (and switch to ActualActual::ISDA in the
> > meantime): any objection if I do it?
>
> Yes--I don't like it :)  I'd rather have no default at all.

ok, I take your point: feel free to remove them as soon as you like or
wait for me to gradually remove them.
For what I'm mostly concerned it is enough to have defaults in the xml
specification of QuantLibXL, I don't need C++ defaults.

> I'm not sure that we should use a default day counter for the
> term structures that require one.  If anything, it _increases_ the
> inconsistency risk---if the user sets the day counter to one curve and
> not to the other, he'll (silently) get two curves with different day
> counters. It would be safer to have him specify both explicitly.

just to get the record straight: I think we shouldn't have a day
counter at all in term structure, as the way to calculate time might
be an implementation detail not available to end user tweaking.
On one hand a user selectable day counter might result in potential
mistakes, as it would happen if one uses 30/360, uses different day
counters for interacting term structures, etc. On the other hand it
does provide little benefit, namely it allows for a time-based public
interface where the user can decide how to measure time.
I don't feel that requiring ActualActual::ISDA as the only way to
measure time would harm anyone, and would remove all those possible
inconsistencies.
Just my 0.02€

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Wed, 2008-01-02 at 16:35 +0100, Ferdinando Ametrano wrote:
> On Jan 2, 2008 3:59 PM, Luigi Ballabio <[hidden email]> wrote:
> > > It's quite a while that I've been considering to define the default
> > > DayCounter in userconfig.hpp (and switch to ActualActual::ISDA in the
> > > meantime): any objection if I do it?
> >
> > Yes--I don't like it :)  I'd rather have no default at all.
>
> ok, I take your point: feel free to remove them as soon as you like or
> wait for me to gradually remove them.

Don't remove them from the base classes though. In those ones it makes
sense to have a null day counter as a default.

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.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev