quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Problems with QuantLib on Mac OSX 10.4

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

On Wed, 2008-05-28 at 19:16 +0200, Ralph Schreyer wrote:
> What happens?
> - Error message:
> ...
> ar cru .libs/libCashFlows.a  averagebmacoupon.o capflooredcoupon.o  
> cashflows.o cashflowvectors.o cmscoupon.o conundrumpricer.o coupon.o  
> couponpricer.o digitalcmscoupon.o digitalcoupon.o digitaliborcoupon.o  
> dividend.o duration.o fixedratecoupon.o floatingratecoupon.o  
> iborcoupon.o rangeaccrual.o replication.o timebasket.o~ranlib .libs/ 
> libCashFlows.a
> ar: .libs/libCashFlows.a: Invalid operation
> make: *** [libCashFlows.la] Error 1
> ...

Do you have any other error before this one?

Luigi


-- 

There is no opinion so absurd that some philosopher will not 
express it. 
-- Marcus Tullius Cicero, "Ad familiares" 

Re: [Quantlib-dev] Non copyable curves.

[Simon I. - S. <Sim...@st...>]

Hi all,

For this improvement (copy-constructors for curves), I've developed some
code for this method. The current copy behaviour is to keep the linkage
to the original Interpolation::Impl object. We need to create a new
object derived from Interpolation::Impl and link the new object to a new
vector of data.
There are two possible ways (that I know of), a virtual clone method to
be implemented by the classes that derive from Interpolation::Impl or
use of the CRT pattern. 
As the Interpolation::Impl class already uses pure virtual methods, I've
implemented the pure virtual function method. Does anyone have any
preferences?

Cheers,

Simon


-----Original Message-----
From: qua...@li...
[mailto:qua...@li...] On Behalf Of Simon
Ibbotson
Sent: 18 April 2008 09:54
To: lui...@gm...
Cc: qua...@li...
Subject: Re: [Quantlib-dev] Non copyable curves.


Okay, that makes sense. I'll implement copy-constructors for the
interpolated curves (I've got several more changes to contribute, so I
may as well make them all consistent).

Regarding "good behaviour" for development in quantitative libraries, in
the past I've worked in small development teams (up to 15 people) where
there were minimal restrictions on what a developer can/can't do:
namely, the code should compile and the test application should not fail
any tests (of course, bug fixes should never break an interface). 

This method isn't perfect (by any means) but with this method, if a user
wishes to use new released functionality, it then becomes the
responsibility of them to integrate any interface changes for a new
release. Alternatively, they can get involved in the development process
and ensure that any interface changes can easily be incorporated into
their external applications.

Is there any documentation on "good practise" for QuantLib / open-source
development? Freezing an interface (at the C++ level during the
development cycle) would mean allowing only incremental additions to the
header files... is that the intention for QuantLib? Alternatively, do we
have a set of classes which form a fixed interface, behind which the
implementation structure (all other classes) can change? 

All advice welcome.

Simon


-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...] 
Sent: 18 April 2008 09:31
To: Simon Ibbotson - Straumur
Cc: op; qua...@li...
Subject: Re: [Quantlib-dev] Non copyable curves.


On Thu, 2008-04-17 at 17:14 +0000, Simon Ibbotson wrote:
> This change has occurred on \trunk, the library still compiles and it
> doesn't break any of the test-suite, so it meets all requirements that
> I would have for a multi-developer library.
> 
> If you need a frozen user interface - use a published release instead.

No, Ole is right---interfaces shouldn't break between releases.
Unfortunately, as we're nearing 1.0, we became aware of a few bad design
choices we made earlier. Correcting those will break something, but we
think that the resulting design will make up for the inconvenience.
After 1.0, the interfaces will be frozen.

As for this particular change:

> My concern is that - as someone trying to contribute to the library -
> a rather restrictive ban on copying curves has been introduced.

This was not based on some design principle. Simply, I suddenly noticed
that copying behavior for interpolated curves was broken---if you copied
an interpolated curve, the interpolation inside the copy would still
point to the data in the original curve. As a quick safety measure, I
disabled copying; a full solution which I haven't had the time to
implement would be to implement the correct copy constructors. We'll
have to do that before release (and, Simon, feel free to go ahead if you
want,) at which point the broken code would work again as before. No, on
second thought, not as before---it would work correctly...

Luigi


-- 

Present to inform, not to impress; if you inform, you will impress. 
-- Fred Brooks 



------------------------------------------------------------------------
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Problems with QuantLib on Mac OSX 10.4

[Marco M. <mar...@st...>]

Hi,
I compiled the trunk of QuantLib as revision 15012, more precisely,

URL: https://quantlib.svn.sourceforge.net/svnroot/quantlib/trunk/QuantLib
Repository Root: https://quantlib.svn.sourceforge.net/svnroot/quantlib
Repository UUID: 8618b1d8-e22c-0410-b026-96a5dba3e089
Revision: 15012

without any problem using
./autogen.sh
./configure
./make

Marco

-- 
Marco Marchioro, Ph. D.
Head of Quantitative Finance, StatPro Italia



On Wednesday, 2008-05-28 , at 19:16 , Ralph Schreyer wrote:

> Hi,
>
> I'm trying to get the QuantLib up and running under Mac OSX 10.4 on
> my MacBook.
>
> What have I done?
> - Updated to the GNU binutils and GNU build system (autotools)
> - Checked out the QuantLib HEAD using SVN
> - Changed to the QuantLib directory
> - ./autogen.sh --> OK
> - ./configure --with-boost-include=/usr/local/include/boost-1_34_1 --
> disable-shared --> OK
> - make -j2
>
> What happens?
> - Error message:
> ...
> ar cru .libs/libCashFlows.a  averagebmacoupon.o capflooredcoupon.o
> cashflows.o cashflowvectors.o cmscoupon.o conundrumpricer.o coupon.o
> couponpricer.o digitalcmscoupon.o digitalcoupon.o digitaliborcoupon.o
> dividend.o duration.o fixedratecoupon.o floatingratecoupon.o
> iborcoupon.o rangeaccrual.o replication.o timebasket.o~ranlib .libs/
> libCashFlows.a
> ar: .libs/libCashFlows.a: Invalid operation
> make: *** [libCashFlows.la] Error 1
> ...
>
> Any ideas? Thanks a lot for any help.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Problems with QuantLib on Mac OSX 10.4

[Ralph S. <ori...@we...>]

Hi,

I'm trying to get the QuantLib up and running under Mac OSX 10.4 on  
my MacBook.

What have I done?
- Updated to the GNU binutils and GNU build system (autotools)
- Checked out the QuantLib HEAD using SVN
- Changed to the QuantLib directory
- ./autogen.sh --> OK
- ./configure --with-boost-include=/usr/local/include/boost-1_34_1 -- 
disable-shared --> OK
- make -j2

What happens?
- Error message:
...
ar cru .libs/libCashFlows.a  averagebmacoupon.o capflooredcoupon.o  
cashflows.o cashflowvectors.o cmscoupon.o conundrumpricer.o coupon.o  
couponpricer.o digitalcmscoupon.o digitalcoupon.o digitaliborcoupon.o  
dividend.o duration.o fixedratecoupon.o floatingratecoupon.o  
iborcoupon.o rangeaccrual.o replication.o timebasket.o~ranlib .libs/ 
libCashFlows.a
ar: .libs/libCashFlows.a: Invalid operation
make: *** [libCashFlows.la] Error 1
...

Any ideas? Thanks a lot for any help.

[Quantlib-dev] Newbie projects

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

Hi,

I am interested in some of the newbie projects at the following page:

http://wiki.quantlib.org/twiki/bin/view/Quantlib/NewbieProjects

Please let me know how I can get more involved. Specifically, implementing
pricing engines, GARCH models sound interesting to me.

Hope to hear from you soon.

Thanks,

Abhishek

Re: [Quantlib-dev] Reorganised EquityOption Example

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

On Sun, 2008-05-18 at 12:52 +0100, Bojan Nikolic wrote:
> To enable some experiments with QuantLib I've reorganised the
> EquityOption example so that each of the pricing methods sits in a
> separate function. It is a pretty trivial change but I think it makes
> the example a bit more readable. Feel free to merge if you wish.

Hi Bojan,
	thanks for the contribution; however, I'm not sure about merging it.
One of the points of the example is to show that a single instrument
instance can be set several engines during its lifetime. I'm afraid that
moving each calculation into a separate function might hide the point.

Thoughts anyone?

Luigi


-- 

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

Re: [Quantlib-dev] Inflation curves

[Chris K. <chr...@ya...>]

Hi Simon,

some answers to your questions - let me know if they don't make sense.

date lags
- the assumption is not that inflation indexes are published on the first of a month, but that they are valid for the whole of the period that they refer to.  If they are monthly then the fixing is valid for every day of the month.  
- if you need interpolated fixings (in the past) then you must calculate this separately.

base date
- this is the date at the start of the period that the inflation term structure starts from
- since inflation indexes are lagged this date is in the past
- thus the baseDate() of an inflation term structure is always before the referenceDate() of the corresponding nominal term structure.  The referenceDate() of a nominal term structure is the date when the discount factor is 1 (one).

baseDate() versus trueBaseDate
- baseDate is the start of the last known fixing period
- trueBaseDate is the end of the last known fixing period
- the forecastFixing takes the zero inflation term structure as starting from the end of the period in which the base date falls.  N.B. there must be a fixing in the period when the base date falls, or else there is no way to forecast the index forward with the inflation term structure.  

initial values (values at base date)
- yes, these never change
- in the market, the earliest that ZCIIS and YYIIS quotes are available is one year
- hence to have a curve that goes from the base date to the first market point the user must take a view on the value at the base date (i.e. there is no market data so the user must supply a number).  If you have an inflation instrument with a payoff at less than one year you must take a view.  One view would be the last fixing (for YoY Inf) or some suitable extrapolation (for Zero Inf).  However, I decided that the creation of such a view belonged outside the class, not in it.
- clearly for non-integer years seasonality is important ... this is in progress - see other posts on -dev.


Best regards,
Chris

> From: Simon Ibbotson - Straumur <Sim...@st...>
> To: qua...@li...
> Subject: [Quantlib-dev] Inflation curves
> Date: Thu, 15 May 2008 13:28:24 -0000
> 
> Hi,
> 
>  
> 
> I’m trying to develop an inflation swap (with intermediate coupons)
> where the fixed payments are scaled by a factor (inflation index /
> base value).
> 
> At the moment, I simply cannot understand the way in which inflation
> curves & inflation indexes work in QuantLib. 
> 
>  
> 
> I understand that there has to be a distinction between inflation
> rates based upon year-on-year (either synthetic or derived from an
> index). However, I don’t understand the date lag mechanism. There are
> several assumptions in place: for instance, the inflation numbers are
> assumed to always be published on the 1st of the month. Also, in
> ZeroInflationIndex::forecastFixing, why is there a difference between
> the baseDate, the trueBaseDate, and the curve reference date?
> 
>  
> 
> Can anyone explain the reasoning behind these dates – also, why does
> the initial zero rate (the value at the base date) not change during
> the bootstrapping?
> 
>  
> 
> Cheers,
> 
>  
> 
> Simon
> 
>  
> 
>  
> 
> Simon Ibbotson
> 
> Quantitative Analytics
> 
> Capital Markets
> 
> Straumur
> 
>  
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________ QuantLib-dev mailing list Qua...@li... https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 

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

Re: [Quantlib-dev] Error after calling quantlib-c++-dll viaswig-c#-interface

[Frank H. <fho...@gm...>]

Hi Luigi,
the solution was quite easy, since the c++-dlls are native ones, and the
call into any one such is by DllImport within the SWIG wrapper, you do not
have to include them as a reference in a c#-project, which I did. The only
one thing one has to do is to place the dll where the c# code is able to
find it. Then it works properly, fast, and without any load/unload errors as
described below.

Regards
Frank

> -----Ursprüngliche Nachricht-----
> Von: Luigi Ballabio [mailto:lui...@gm...] 
> Gesendet: Freitag, 16. Mai 2008 17:30
> An: fho...@gm...
> Cc: qua...@li...
> Betreff: Re: [Quantlib-dev] Error after calling 
> quantlib-c++-dll viaswig-c#-interface
> 
> 
> On Mon, 2008-05-05 at 21:09 +0200, Frank Hövermann wrote:
> > I think this is a matter of unproper garbage collection or 
> something 
> > similar but I need some guru advice: A properly coded function (in 
> > C++, some double* serve as input, and a .txt or .csv file is the 
> > output but the function call is like "void func_name(double *input, 
> > char *path)" so nothing is actually
> > returned) which does some calculations using some QuantLib 
> objects somehow
> > changes its behaviour under /clr compiler option. This I 
> need to be able to
> > use it via SWIG under C#. Calculations are done as supposed 
> to, but upon C#
> > program termination an "unknown software exception" (0xc0020001) at
> > 0x7c81eb33 pops up. I googled a bit and indications point 
> to a too quick
> > (unmanaged) object disposal where the program terminates 
> before the C++
> > object does. Does this sound familiar to one of you? Are 
> there any hints to
> > prevent this?
> 
> Hi Frank,
> 	unfortunately, I'm not an expert at all in managed 
> C++/C#---my only exposure to C# has been to compile the SWIG 
> wrappers before release to check that they work...  Did you 
> try asking on the SWIG mailing list? It doesn't seem a SWIG 
> problem (since all you're exporting is a function taking some 
> basic types---no class instances are passing through the 
> wrapping layer) but there might be people there with more expertise.
> 
> Luigi
> 
> 
> 
> -- 
> 
> Dealing with failure is easy: work hard to improve. Success is also 
> easy to handle: you've solved the wrong problem. Work hard to 
> improve. 
> -- Alan Perlis 
> 

Re: [Quantlib-dev] Credit probas ahead of mkt tenors

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

Quite convenient.
I better study the interface a bit more.
thank u

pp

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

> On Thu, 2008-05-22 at 12:47 +0200, ja...@fr... wrote:
> > The way it is right now we have no option to tell the interpolator to
> > extrapolate the default probabilities outside the engine level without
> rewriting
> > a specific new engine. Whats the reason for this?
>
> We do. For any curve (yield, default probability, etc.) you can call
>
> curve->enableExtrapolation();
>
> to, well, enable extrapolation :)
>
> Luigi
>
>
> --
>
> The rule on staying alive as a forecaster is to give 'em a number or
> give 'em a date, but never give 'em both at once.
> -- Jane Bryant Quinn
>
>
>

Re: [Quantlib-dev] Credit probas ahead of mkt tenors

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

On Thu, 2008-05-22 at 12:47 +0200, ja...@fr... wrote:
> The way it is right now we have no option to tell the interpolator to
> extrapolate the default probabilities outside the engine level without rewriting
> a specific new engine. Whats the reason for this?

We do. For any curve (yield, default probability, etc.) you can call

curve->enableExtrapolation();

to, well, enable extrapolation :)

Luigi


-- 

The rule on staying alive as a forecaster is to give 'em a number or 
give 'em a date, but never give 'em both at once. 
-- Jane Bryant Quinn 

[Quantlib-dev] Credit probas ahead of mkt tenors

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

The way it is right now we have no option to tell the interpolator to
extrapolate the default probabilities outside the engine level without rewriting
a specific new engine. Whats the reason for this?

If I'm not missing something this applies to all engines (interpolated
discounts/zeros) but the bond curve mkt can expand up to 50Y so we are not going
to run into this problem as easily as with credit.

Extrapolation might or not make sense depending on the interpolator, shouldn't
we decide to extrapolate at the level we set the interpolator template (the
curve passed to the engine)?

pp

Re: [Quantlib-dev] CDS

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

This is what I used to do (removed the code to get this done by the
user-coupons) but only applies to the CDSs and it is not the 3rd Wedn rule.
Theres a broken period from "start date" to the (badly named) "first date"

Another feature to be added is the specific day count convention for CDS that
adds an extra day to the last coupon period. Again one can do it passing the
coupon schedule that way.

Rgds
pp


            Date cdsFstDate;
            if( (cds_start_date.month() == Month::March) ||
                (cds_start_date.month() == Month::April) ||
                (cds_start_date.month() == Month::May)){
                    cdsFstDate = Date(20, Month::June, cds_start_date.year());
            }else if( (cds_start_date.month() == Month::June) ||
                (cds_start_date.month() == Month::July) ||
                (cds_start_date.month() == Month::August)){
                    cdsFstDate = Date(20, Month::September,
cds_start_date.year());
            }else if( (cds_start_date.month() == Month::September) ||
                (cds_start_date.month() == Month::October) ||
                (cds_start_date.month() == Month::November)){
                    cdsFstDate = Date(20, Month::December,
cds_start_date.year());
            }else if( (cds_start_date.month() == Month::December)) {
                cdsFstDate = Date(20, Month::March, cds_start_date.year()+1);
            }else if( (cds_start_date.month() == Month::January) ||
                (cds_start_date.month() == Month::February)){
                    cdsFstDate = Date(20, Month::March, cds_start_date.year());
            }
            cdsFstDate = cal.adjust(cdsFstDate, bdc);


Quoting Simon Ibbotson <s.i...@gm...>:

> There's a function in QuantLib for deriving the next CME IMM date (3rd
> Wednesday). Is there anything similar for other exchanges?
> In particular, most CDS roll on the 20th of the IMM month (except emerging
> markets which roll on the 20th of every month). I could write some external
> code, but I guessed that it would be better within QuantLib - anyone
> done/doing this?
>
> Cheers,
>
> Simon
>

[Quantlib-dev] CDS

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

There's a function in QuantLib for deriving the next CME IMM date (3rd
Wednesday). Is there anything similar for other exchanges?
In particular, most CDS roll on the 20th of the IMM month (except emerging
markets which roll on the 20th of every month). I could write some external
code, but I guessed that it would be better within QuantLib - anyone
done/doing this?

Cheers,

Simon

Re: [Quantlib-dev] Overnight Index Swaps

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

On Tue, 2008-05-20 at 05:34 -0700, mlavin wrote:
> Has anyone begun work on modeling Overnight Index Swaps (EONIA, SONIA, etc)?

Not that I know of.

> If not and noone objects I thought I would try my hand at it.

Yes, go ahead.

Thanks,
	Luigi


-- 

The wisdom of the wise and the experience of the ages are perpetuated 
by quotations. 
-- Benjamin Disraeli 

Re: [Quantlib-dev] Overnight Index Swaps

[snovik <sn...@gm...>]

I would only really appreciate it.


mlavin wrote:
> 
> Has anyone begun work on modeling Overnight Index Swaps (EONIA, SONIA,
> etc)?
> If not and noone objects I thought I would try my hand at it.
> 

-- 
View this message in context: http://www.nabble.com/Overnight-Index-Swaps-tp17339263p17344078.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] Overnight Index Swaps

[mlavin <mar...@gm...>]

Has anyone begun work on modeling Overnight Index Swaps (EONIA, SONIA, etc)?
If not and noone objects I thought I would try my hand at it.
-- 
View this message in context: http://www.nabble.com/Overnight-Index-Swaps-tp17339263p17339263.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] Reorganised EquityOption Example

[Bojan N. <bo...@bn...>]

-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

[Quantlib-dev] [ quantlib-Bugs-1966376 ] Bug: isInSubset

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

Bugs item #1966376, was opened at 2008-05-18 01:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1966376&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug: isInSubset

Initial Comment:
Hello,

the function isInSubset in ql/models/marketmodels/utilities.cpp crashes in some cases.

Subset loop:

while (true) {
  subsetElement = subset[j];
  result[i] = false;
  if (setElement < subsetElement) break;
  if (setElement == subsetElement) {
    result[i] = true;
    break;
  }
  if (j > dimsubSet-1) break;
  ++j;
}

The largest allowed j in the line with the break is j==dimsubSet-1. In the next line j is increased by 1 and we have j==dimsubSet. The next statement at the beginning of the while-loop will exceed the array-boundary:
subsetElement = subset[j].

I think a greater or equal would be a solution:
if (j >= dimsubSet-1) break;

Kind regards
Jan van Heys

email: ml...@va...


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

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

Re: [Quantlib-dev] bondhelpers.cpp bug

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

On Mon, 2008-03-31 at 10:40 +0000, Simon Ibbotson wrote:
> The constructor for the FixedRateBondHelper class that takes a bond as
> a parameter doesn’t instantiate member variable ::bond_ before use.

True--I've fixed that. Thanks for the report.


> b)       If we use the input bond, there’s no guarantee that the bond
> is not used elsewhere with a different yieldcurve which would lead to
> uncertain results.

True, but as you wrote it's tricky to make it safe. For the time being,
I've added a warning to the documentation pointing out the problem.

Luigi


-- 

When all else fails, pour a pint of Guinness in the gas tank, 
advance the spark 20 degrees, cry "God Save the Queen!", and pull 
the starter knob. 
-- MG "Series MGA" Workshop Manual 

Re: [Quantlib-dev] Error after calling quantlib-c++-dll via swig-c#-interface

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

On Mon, 2008-05-05 at 21:09 +0200, Frank Hövermann wrote:
> I think this is a matter of unproper garbage collection or something similar
> but I need some guru advice: A properly coded function (in C++, some double*
> serve as input, and a .txt or .csv file is the output but the function call
> is like "void func_name(double *input, char *path)" so nothing is actually
> returned) which does some calculations using some QuantLib objects somehow
> changes its behaviour under /clr compiler option. This I need to be able to
> use it via SWIG under C#. Calculations are done as supposed to, but upon C#
> program termination an "unknown software exception" (0xc0020001) at
> 0x7c81eb33 pops up. I googled a bit and indications point to a too quick
> (unmanaged) object disposal where the program terminates before the C++
> object does. Does this sound familiar to one of you? Are there any hints to
> prevent this?

Hi Frank,
	unfortunately, I'm not an expert at all in managed C++/C#---my only
exposure to C# has been to compile the SWIG wrappers before release to
check that they work...  Did you try asking on the SWIG mailing list? It
doesn't seem a SWIG problem (since all you're exporting is a function
taking some basic types---no class instances are passing through the
wrapping layer) but there might be people there with more expertise.

Luigi



-- 

Dealing with failure is easy: work hard to improve. Success is also 
easy to handle: you've solved the wrong problem. Work hard to improve. 
-- Alan Perlis 

[Quantlib-dev] Inflation curves

[Simon I. - S. <Sim...@st...>]

Hi,

 

I'm trying to develop an inflation swap (with intermediate coupons)
where the fixed payments are scaled by a factor (inflation index / base
value).

At the moment, I simply cannot understand the way in which inflation
curves & inflation indexes work in QuantLib. 

 

I understand that there has to be a distinction between inflation rates
based upon year-on-year (either synthetic or derived from an index).
However, I don't understand the date lag mechanism. There are several
assumptions in place: for instance, the inflation numbers are assumed to
always be published on the 1st of the month. Also, in
ZeroInflationIndex::forecastFixing, why is there a difference between
the baseDate, the trueBaseDate, and the curve reference date?

 

Can anyone explain the reasoning behind these dates - also, why does the
initial zero rate (the value at the base date) not change during the
bootstrapping?

 

Cheers,

 

Simon

 

 

Simon Ibbotson

Quantitative Analytics

Capital Markets

Straumur

 

Re: [Quantlib-dev] New Calendars

[Lecuyer, F. <Fab...@cb...>]

It makes sense. However, aren't belgian bonds also denominated in Euro?
In any case, if bloomberg confirms their data, I back off and apologise
for the mess I created... 

-----Original Message-----
From: qua...@li...
[mailto:qua...@li...] On Behalf Of Luigi
Ballabio
Sent: Thursday, 15 May 2008 5:28 AM
To: MJC1
Cc: qua...@li...
Subject: Re: [Quantlib-dev] New Calendars


On May 13, 2008, at 11:17 PM, MJC1 wrote:
> It should be the calendar indicating all non-settlement days.
>
> I'll check with Bloomberg to see if their is an error on their end.

No, it's probably not an error. It might just be that, being denominated
in Euro, French bonds settle according to TARGET.

Luigi


> Luigi Ballabio wrote:
>>
>> On Tue, 2008-05-13 at 10:24 +1000, Lecuyer, Fabrice wrote:
>>> I just looked at Bloomberg and they do see those dates only as non 
>>> settlement dates. However, I still doubt a french bond can settle on

>>> the 14 of July (Bastille day) for example. Even Belgium has it's 
>>> national day as a non-settlement day.
>>
>> Ok, I just had a more careful look at the submitted France calendar.
>> It looks to me it's just the TARGET calendar. Am I wrong?



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

************** IMPORTANT MESSAGE *****************************       
This e-mail message is intended only for the addressee(s) and contains information which may be
confidential. 
If you are not the intended recipient please advise the sender by return email, do not use or
disclose the contents, and delete the message and any attachments from your system. Unless
specifically indicated, this email does not constitute formal advice or commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us, please reply to this
e-mail by typing Unsubscribe in the subject line. 
**************************************************************

Re: [Quantlib-dev] New Calendars

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

On May 13, 2008, at 11:17 PM, MJC1 wrote:
> It should be the calendar indicating all non-settlement days.
>
> I'll check with Bloomberg to see if their is an error on their end.

No, it's probably not an error. It might just be that, being 
denominated in Euro, French bonds settle according to TARGET.

Luigi


> Luigi Ballabio wrote:
>>
>> On Tue, 2008-05-13 at 10:24 +1000, Lecuyer, Fabrice wrote:
>>> I just looked at Bloomberg and they do see those dates only as non
>>> settlement dates. However, I still doubt a french bond can settle on
>>> the 14 of July (Bastille day) for example. Even Belgium has it's
>>> national day as a non-settlement day.
>>
>> Ok, I just had a more careful look at the submitted France calendar.
>> It looks to me it's just the TARGET calendar. Am I wrong?

[Quantlib-dev] [ quantlib-Bugs-1963642 ] Possible redundancy with stubDate_ in MakeSchedule

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

Bugs item #1963642, was opened at 2008-05-14 09:59
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1963642&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible redundancy with stubDate_ in MakeSchedule

Initial Comment:
The member variable stubDate_ of MakeSchedule is set to default Date in the constructor, and none of the MakeSchedule methods modify it. Yet in the initial part of MakeSchedule operator::Schedule(), there is code that resets firstDate, nextToLastDate etc if stubDate_ is not equal to the default date. Given that stubDate_ is fixed at default Date, this code is never used. Is it possible that either a method "withStubDate" is required, or that stubDate_ needs to be reset in "withFirstDate" and "withNextToLastDate" methods?

ohk...@gm...

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

Comment By: Luigi Ballabio (lballabio)
Date: 2008-05-14 14:36

Message:
Logged In: YES 
user_id=75450
Originator: NO

The bug is now fixed in the Subversion repository.
Thank you for the report.


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

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

Re: [Quantlib-dev] CDS example

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

On Wed, May 14, 2008 at 12:17 PM, Luigi Ballabio
<lui...@gm...> wrote:
> Since we have an additional point for today's date (and since this
> also holds for all other bootstrapped curves)
mmm... I'm not so sure this is always the case. E.g. if you model the
YieldTermStructure as interpolated zero rates, the zero rate at time
t=0 is not unambiguously defined. For the time being the code defaults
to a given value, but this is not really needed and as a matter of
fact is often problematic, as it can break bootstrapping when using
global interpolation.

> I changed the check in
> IterativeBootstrap so that it requires a number of instruments equal to
> the number of required points minus one.

why don't we skip this early check altogether and adopt the lazy
approach of delegating the check to the interpolation class?

ciao -- Nando