quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] How to use test suite

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

On Mon, 2009-03-16 at 14:47 +0530, Ramesh Pedhamalla wrote:
>   Iam useing Quantilib in my application,i want to test some API in
> Quantlib.Please let me know how to use test suite.

Sorry, I'm not following.  May you add some details and/or some context?

Luigi


-- 

These are my principles, and if you don't like them... Well, I have
others. 
-- Groucho Marx 

[Quantlib-dev] [ quantlib-Bugs-2691902 ] Bootstrapping for bonds: Inconsistency in the clean price

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

Bugs item #2691902, was opened at 2009-03-18 15:28
Message generated for change (Comment added) made by klriedel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2691902&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: Karl Riedel (klriedel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bootstrapping for bonds: Inconsistency in the clean price

Initial Comment:
Dear ladies and gentlemen,

when considering the bootstrapping of a coupon bond according to the example "FittedBondCurve.cpp" I found an inconsistency in the results of the bootstrapper according to
        boost::shared_ptr<YieldTermStructure> ts0 (
              new PiecewiseYieldCurve<Discount,LogLinear>(curveSettlementDays,
                                                          calendar,
                                                          instrumentsB,
                                                          bondDayCount));

This inconsistency was as follows: For simplicity I considered a coupon bond with only one remaining payment date t_1, at which the coupon c and the redemption 1 will be paid. Let t_0 be the last coupon date and today t is within the interval [t_0,t_1]. For this situation the discount factor df(t,t_1) was calculated according to
Clean Price = df(t,t_1) * [ 1 + c*(t_1-t) ].      (1)
This formula refers to a Clean Price which is theoretically correct, i.e. the accrued amount is discounted. 
On the other hand, what has actually to be paid (marked standard) for a bond is the Clean price + the accrued amount according to the simple formula c*(t-t_0) which does not take into account discounting the accrued amount. The net present value of future payments must equal the spot price:
Clean Price + c * (t-t_0) = df(t,t_1) * [1+c].   (2)

In the middle of a payment period the resulting discount factors df(t,t_1) of (1) and (2) differ most. In my example this lead to a difference in the zero rate of around 10 BIPs.

Best regards,
Karl Riedel 

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

>Comment By: Karl Riedel (klriedel)
Date: 2009-03-19 11:28

Message:
Hello Luigi,

unfortunately I did not have the time to search the relevant position(s)
in the code. I just compared the results of Quantlib bootstrapping to
formula (1) and (2) considering an easy example. The bootstrapper
calculates results according to formula (1) while formula (2) describes the
correct net present value. 

Please find the example code attached. The produced output is as follows:

Today's date: January 2nd, 2009
Bootstrapping 1 bond with 0.5 years tenor and 4% coupon ...

According to
Clean Price = df(t,t_1) * [ 1 + c*(t_1-t) ].      (1)
df = 1 / (1+0.5*c) = 1 / 1.02 = 0.980392156863
ts0->discount(maturity) =       0.980392156863
r = -log(df)/0.5 =              0.0396052545924
ts0->zeroRate(... =             0.0396052545924

According to correct net present value
Clean Price + c * (t-t_0) = df(t,t_1) * [1+c].   (2)
df = (1+0.5*c)/(1+c) = 1.02/1.04 = 0.980769230769
r = -log(df)/0.5 =                 0.0388361717142
Drücken Sie eine beliebige Taste . . .



Karl

File Added: CleanpriceInconsistencyExample.txt

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

Comment By: Luigi Ballabio (lballabio)
Date: 2009-03-18 17:14

Message:
Karl,
   may you point out the places in the code where the calculations (1) and
(2) are performed?
Also, do you have some code to reproduce the error?

Luigi


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

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

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib:[16031] trunk/QuantLib

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

On Thu, 2009-03-19 at 09:55 +0000, na...@us... wrote:
> Revision: 16031
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=16031&view=rev
> Author:   nando
> Date:     2009-03-19 09:55:34 +0000 (Thu, 19 Mar 2009)
> 
> Log Message:
> -----------
> - partially reverted Rev16029 to have date, nominal order (as it is a
> less invasive change than switching to nominal, date)

You read my mind. Thanks.

Luigi


-- 

To err is human -- to blame it on a computer is even more so. 
-- unknown 

[Quantlib-dev] [ quantlib-Bugs-2691902 ] Bootstrapping for bonds: Inconsistency in the clean price

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

Bugs item #2691902, was opened at 2009-03-18 15:28
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2691902&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: Karl Riedel (klriedel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bootstrapping for bonds: Inconsistency in the clean price

Initial Comment:
Dear ladies and gentlemen,

when considering the bootstrapping of a coupon bond according to the example "FittedBondCurve.cpp" I found an inconsistency in the results of the bootstrapper according to
        boost::shared_ptr<YieldTermStructure> ts0 (
              new PiecewiseYieldCurve<Discount,LogLinear>(curveSettlementDays,
                                                          calendar,
                                                          instrumentsB,
                                                          bondDayCount));

This inconsistency was as follows: For simplicity I considered a coupon bond with only one remaining payment date t_1, at which the coupon c and the redemption 1 will be paid. Let t_0 be the last coupon date and today t is within the interval [t_0,t_1]. For this situation the discount factor df(t,t_1) was calculated according to
Clean Price = df(t,t_1) * [ 1 + c*(t_1-t) ].      (1)
This formula refers to a Clean Price which is theoretically correct, i.e. the accrued amount is discounted. 
On the other hand, what has actually to be paid (marked standard) for a bond is the Clean price + the accrued amount according to the simple formula c*(t-t_0) which does not take into account discounting the accrued amount. The net present value of future payments must equal the spot price:
Clean Price + c * (t-t_0) = df(t,t_1) * [1+c].   (2)

In the middle of a payment period the resulting discount factors df(t,t_1) of (1) and (2) differ most. In my example this lead to a difference in the zero rate of around 10 BIPs.

Best regards,
Karl Riedel 

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2009-03-18 17:14

Message:
Karl,
   may you point out the places in the code where the calculations (1) and
(2) are performed?
Also, do you have some code to reproduce the error?

Luigi


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

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

[Quantlib-dev] [ quantlib-Bugs-2691902 ] Bootstrapping for bonds: Inconsistency in the clean price

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

Bugs item #2691902, was opened at 2009-03-18 15:28
Message generated for change (Tracker Item Submitted) made by klriedel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2691902&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: Karl Riedel (klriedel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bootstrapping for bonds: Inconsistency in the clean price

Initial Comment:
Dear ladies and gentlemen,

when considering the bootstrapping of a coupon bond according to the example "FittedBondCurve.cpp" I found an inconsistency in the results of the bootstrapper according to
        boost::shared_ptr<YieldTermStructure> ts0 (
              new PiecewiseYieldCurve<Discount,LogLinear>(curveSettlementDays,
                                                          calendar,
                                                          instrumentsB,
                                                          bondDayCount));

This inconsistency was as follows: For simplicity I considered a coupon bond with only one remaining payment date t_1, at which the coupon c and the redemption 1 will be paid. Let t_0 be the last coupon date and today t is within the interval [t_0,t_1]. For this situation the discount factor df(t,t_1) was calculated according to
Clean Price = df(t,t_1) * [ 1 + c*(t_1-t) ].      (1)
This formula refers to a Clean Price which is theoretically correct, i.e. the accrued amount is discounted. 
On the other hand, what has actually to be paid (marked standard) for a bond is the Clean price + the accrued amount according to the simple formula c*(t-t_0) which does not take into account discounting the accrued amount. The net present value of future payments must equal the spot price:
Clean Price + c * (t-t_0) = df(t,t_1) * [1+c].   (2)

In the middle of a payment period the resulting discount factors df(t,t_1) of (1) and (2) differ most. In my example this lead to a difference in the zero rate of around 10 BIPs.

Best regards,
Karl Riedel 

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

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

[Quantlib-dev] [ quantlib-Bugs-2691647 ] Problems in calculating the ParRates

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

Bugs item #2691647, was opened at 2009-03-18 12:16
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2691647&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: Problems in calculating the ParRates

Initial Comment:
Dear ladies and gentlemen,

when considering the example "FittedBondCurve.cpp" I found the behavior of the function "parRates" to be strange. The parRate is defined as the fixed rate for which the instrument is noted at par. This means that the CLEAN price equals the notional, say 1. The net present value of future cashflows, however, equals the DIRTY price. For the purpuse of calculating the Par Yield Curve, which is most interesting, yearly coupons and annual compounding is to be assumed in order to calculate the  theoretically correct accrued amount (Hans-Peter Deutsch, Derivate und Interne Modelle, 3. Ed., p. 74,75).
Thus, I coded a solution c to

(1+c)^(t-t_m) = Sum_{i=m+1}^{n} df(t,t_i)*c(t_i-t_{i-1}) + df(t,t_n),  (1)

instead of 

1 = Sum_{i=m+1}^{n} df(t,t_i)*c(t_i-t_{i-1}) + df(t,t_n),  (2)

where t is today, t_m < t < t_{m+1} < ... < t_n, t_i are the coupon dates, df(t,t_i) the corresponding discount factors and c the coupons. Eq. (1) follows from (6.6) in [H. P. Deutsch] with (6.5), annual compounding (table 3.4) and N(t_m)=N(t_n)=1. Eq. (2) is correct only at the coupon dates, but not in between.

- For the solution of (1) I did Taylor-series approximation and solved the quadratic equation. This should be improved by some iterative scheme like Regula Falsi or Newton.

- Presumably at the 29.2. for some curves there were small jumps. Thus maybe I did not completely correct implement the elapsed time since the last coupon payment.

- Further it would be a good thing to have a possibility to get the Par Yield Curve without having to calculate the coupon dates (which I did in main). Just transferring the date like for the "zeroRate" would be much more convenient, i.e. to call e.g.
"ts3->parRate(date)"

The resulting figure shows a reasonable behavior. The Par Yield Curve fits to the coupons, i.e. parRates of the underlying data points. The Par Yield Curve is above the zero curve for a falling zero structure as expected (and vice versa for an increasing zero structure). 

I would be interested in and happy about a new release including the calculation of Par Yield Curves as proposed. 

Best regards,
Karl Riedel
Nagler & Company GmbH



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

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

Re: [Quantlib-dev] legacy McCliquetOption class

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

On Tue, 2009-03-17 at 20:01 +0100, Ferdinando Ametrano wrote:
> McCliquetOption

It's being worked on.  A few students at Nice polytechnique are
migrating it to the new framework as an assignment for a course of
theirs.  The model is not going to change, though---it's going to be a
straight migration to instrument + pricing engine.

Luigi


-- 

Never mistake motion for action. 
-- Ernest Hemingway 

[Quantlib-dev] legacy McCliquetOption class

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

Hi all

McCliquetOption

I wrote McCliquetOption 5 years ago and even then I was quite
unsatisfied, since it priced cliquet option using local vol neglecting
the smile dynamic (or even worse using a black model with no smile).

Because of its inappropriate modeling and since it is the last legacy
class inheriting from the obsolete and deprecated McPricer, I suggest
to remove it before 1.0

ciao -- Nando

[Quantlib-dev] Questions regarding amortizing bonds

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

First of all, sorry for the long post. I might be looking at the problem from
my own castle and therefore miss some points. 

I can not understand why implementation of amortiting bonds is so complex
and unfriendly. 

All bond constructors use some leg helper to produce coupon cashflows of
some arbitrary notional schedule plus again some arbitrary final redemption.
I see it being as flexbile as it could be. However if I want to have an
amortizing bond I used to use a single original (not current) notional to
produce "full" coupon cash flows which where then wrapped and adjusted for
factor on each given factor date. Here factor is the bond paydown schedule,
starting from 1 at issue and going to 0 at maturity or final paydown date.

Current implementation of amortizing bond requires me to pre-calculate
already amortized (current) notionals and then send them to the bond
constructor which then uses a leg helper and so on... and at the end still
extracts amortized amounts from provided notionals.

My questions are:

First, I do not understand why I have to pre-calculate current notionals.
Factors allow for basic bond comparision and if I need to model amortisation
of bonds I am modelling factors which means that I am going to stick with my
wrapper and avoid pre-calculation currently required. If I am using historic
information to construct an amortizing bond, then factor information of much
more readily available than current notionals which again leaves me with the
wrapper.

Second, when I am looking into the code, I fail to "wrap" ;) my head around
it. Calculation of amortisation cash-flows is very straightforward if one
uses factors that there is no need to store notionals, cashflows, schedules
and redemptions and do any magic with them. I know memory if cheap these
days and should be a low concern but only if it makes code easier or faster,
not more complex ;)

Finally, I do not understand why notionals are not allowed to increase (or
be greater than final payment). There are plenty of in general amortizing
instruments which are PIK-able, i.e. when interest can be capitalized (CLOs
are like this to start with).

I hope I am not missing some major point here and would be happy to get
clarifications. Most of bonds I work with are amortizing and I find current
implementation in general useless or at minimum overly complex and
unfriendly.
-- 
View this message in context: http://www.nabble.com/Questions-regarding-amortizing-bonds-tp22564134p22564134.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] How to use test suite

[Ramesh P. <ram...@3i...>]

Hello

  Iam useing Quantilib in my application,i want to test some API in Quantlib.Please let me know how to use test suite.

Thanks in advance
P.Ramesh
09987198868.



---
This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient.If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that 3i Infotech or its subsidiaries and  associated companies, (collectively "3i Infotech"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of 3i Infotech. Before opening any attachments please check them for viruses and defects.

Re: [Quantlib-dev] mortgage bond

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

Quoting Nathan Abbott <nka...@gm...>:

> Btw, if anybody is interested in residential prepayments/OAS calculations
> and willing to implement that or is working on that, please contact me and
> we can hopefully coordinate. Please note however that we have limited
> (almost zero) expertise on that subject.
>

I can do the prepayment and default bits if you want, I am familiar with the
prepayment models. As you suggest this might change your pricing, I could
implement them as a probability of a notional surviving fraction.
We can work out the details.

Regards
Pepe

Re: [Quantlib-dev] Kernel Interpolation

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

On Tue, 2009-03-10 at 16:58 +0100, Dima wrote:
> I finished my
> implementations which you can find in the following zip:
> 
> www.longvega.com/KernelInterpolation.zip
> 
> ready for submission from my perspective. The test functions can be
> copied straightforwardly to the other test functions in
> interpolations.cpp in the testcases project. 

Ok, thanks.  I'll try and give it a look as soon as I get some time.


> Not sure if this form of submission is convenient for you, let me know
> if some other form creates less work.

If you're contributing new files, as in this case, it's ok.  If you
happen to contribute changes to existing files in the future, diff files
would be the preferred way. But don't worry too much about it.

Luigi


-- 

Any software problem can be solved by adding another layer of
indirection. 
-- Steven M. Bellovin 

Re: [Quantlib-dev] mortgage bond

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

On Sun, 2009-03-08 at 14:14 -0800, Nathan Abbott wrote:
> I am c++ programmer that only knows the basics of quantitative
> finance. Because I have been programming with QuantLib for two years,
> I think I have a good understanding on how QuantLib works. Luigi
> Ballabio's Implementing QuantLib has been a great help on
> understanding QuantLib. I am working with a financial person who uses
> my program, He is fluent with quantitative finance, but only knows a
> little c++ and does not know how QuantLib works.

It seems like a good match.  No, seriously.


> We want to implement a simple version of mortgage bonds through a
> MorgtageBond class that will probably inherit from the Bond class (and
> maybe a FixedRateMortageBond and FloatingRateMortageBond classes
> derived from the MortgageBond class) and would like to solicit some
> opinions/suggestions/objections.

[ snipped ]

At this time, I'm not aware of work being done on this (well, except for
proprietary work, but that's out of the picture.)  Given the model you
want to implement, your approach seems correct.  If possible, keep the
calculations in a pricing engine so that they can be replaced easily
when someone (or you) add a prepayment model or anything else.

Later,
	Luigi


-- 

The idea that an arbitrary naive human should be able to properly 
use a given tool without training or understanding is even more 
wrong for computing than it is for other tools (e.g. automobiles, 
airplanes, guns, power saws). 
-- Doug Gwyn 

Re: [Quantlib-dev] Kernel Interpolation

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

Thanks  Luigi,

makes sence. I considered this in my implementation. I finished my
implementations which you can find in the following zip:

www.longvega.com/KernelInterpolation.zip

ready for submission from my perspective. The test functions can be copied
straightforwardly to the other test functions in interpolations.cpp in the
testcases project.

Not sure if this form of submission is convenient for you, let me know
if some other form creates less work.

Best regards, Dima



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

> On Mon, 2009-03-09 at 14:40 +0100, Dima wrote:
> > I'm almost done with coding an additional 1D interpolation technique:
> > the kernel approach, which can
> > for example be found in the book "Foreign Exchange Risk" by Hakkala,
> > Wystup. I plan to
> > code it for 2D later.
> >
> > I have some questions regarding the existing interpolation functions:
> >
> > - As usual: Any reasons not to include it? Is someone else working on
> > the same project?
>
> Not that I know of.
>
> > - The existing  classes all have primitive, derivative and second
> > derivative functions, which I don't all have for kernels. What shall I
> > do? Return a zero/throw error?
>
> Throw an error.
>
> > - For me its not really clear, what the function update is doing. Can
> > someone elaborate?
>
> It recalculates the interpolation coefficients.  The point is that the
> Interpolation object only stores iterators into the underlying data, not
> a copy of the data.  If external code changes the original data, it will
> invalidate the interpolation (since the stored interpolated coefficients
> are still based on the old data, but the stored iterators will now
> access the new data.) After changing the data, the external
> code---which, usually, is some method of the object storing the data and
> the interpolation---must call update() to renew the interpolation
> coefficients.
>
> Luigi
>
>
> --
>
> Prediction is very difficult, especially if it's about the future.
> -- Niels Bohr
>
>
>

Re: [Quantlib-dev] Kernel Interpolation

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

On Mon, 2009-03-09 at 14:40 +0100, Dima wrote:
> I'm almost done with coding an additional 1D interpolation technique:
> the kernel approach, which can
> for example be found in the book "Foreign Exchange Risk" by Hakkala,
> Wystup. I plan to
> code it for 2D later. 
> 
> I have some questions regarding the existing interpolation functions:
> 
> - As usual: Any reasons not to include it? Is someone else working on
> the same project?

Not that I know of.

> - The existing  classes all have primitive, derivative and second
> derivative functions, which I don't all have for kernels. What shall I
> do? Return a zero/throw error?

Throw an error.

> - For me its not really clear, what the function update is doing. Can
> someone elaborate?

It recalculates the interpolation coefficients.  The point is that the
Interpolation object only stores iterators into the underlying data, not
a copy of the data.  If external code changes the original data, it will
invalidate the interpolation (since the stored interpolated coefficients
are still based on the old data, but the stored iterators will now
access the new data.) After changing the data, the external
code---which, usually, is some method of the object storing the data and
the interpolation---must call update() to renew the interpolation
coefficients.

Luigi


-- 

Prediction is very difficult, especially if it's about the future. 
-- Niels Bohr 

[Quantlib-dev] Kernel Interpolation

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

Hi all.

I'm almost done with coding an additional 1D interpolation technique: the
kernel approach, which can
for example be found in the book "Foreign Exchange Risk" by Hakkala, Wystup.
I plan to
code it for 2D later.


I have some questions regarding the existing interpolation functions:

- As usual: Any reasons not to include it? Is someone else working on the
same project?
- The existing  classes all have primitive, derivative and second derivative
functions, which
I don't all have for kernels. What shall I do? Return a zero/throw error?

- For me its not really clear, what the function update is doing. Can
someone elaborate?


Best regards, Dima

[Quantlib-dev] mortgage bond

[Nathan A. <nka...@gm...>]

I am c++ programmer that only knows the basics of quantitative finance.
Because I have been programming with QuantLib for two years, I think I have
a good understanding on how QuantLib works. Luigi Ballabio's * Implementing
QuantLib *has been a great help on understanding QuantLib. I am working with
a financial person who uses my program, He is fluent with quantitative
finance, but only knows a little c++ and does not know how QuantLib works.

We want to implement a simple version of mortgage bonds through a
MorgtageBond class that will probably inherit from the Bond class (and maybe
a FixedRateMortageBond and FloatingRateMortageBond classes derived from the
MortgageBond class) and would like to solicit some
opinions/suggestions/objections.

Currently we are thinking that it will be defined similar to the amortizing
bond classes (taking in a vector of nominals and dates generated outside of
QuantLib), but be derived from bond (and inherit all it's functions) and
adding specific functions to it (like weighted average life calculation).
Has anyone already done/thought of doing something similar?

Secondly, assuming prepayments are not an issue (which for our purposes they
are not), a simple mortgage bond is priced similar to corporate bonds,
meaning as a spread over swaps (i.e. on a yield basis, yield = swap rate +
spread), then use that sum as the yield to calculate the price. The bond
class has dirtyPrice and cleanPrice functions which take yield as an input.
We can get the par rate from the yield curve by using the parRate function
or instantiate a simple swap (as explained in yieldtermstructure.hpp
comments).

Our question is w.r.t the spread. We want to build a spread grid/matrix with
rating on one axis/rows and maturity/columns on the other. We were thinking
of creating a termspreadsurface (similar to capfloortermvolsurface) which
could be useful for mbs and corporate bonds (spread per rating/term). Has
anyone already done something similar?

Btw, if anybody is interested in residential prepayments/OAS calculations
and willing to implement that or is working on that, please contact me and
we can hopefully coordinate. Please note however that we have limited
(almost zero) expertise on that subject.

[Quantlib-dev] Debugging QuantLib applications on OSX Leopard

[Tamas S. <ta...@ao...>]

Hello all,

here is some notes on debugging QuantLib applications on OSX Leopard:

by default QuantLib is build with -g -O2 flag which will create a  
special folder in ql/.libs called libQuantLib-0.9.8.dylib.dSYM,
this will hold all the debugging info. However since all the "not  
important *.o" files are deleted the gdb debugger will crash on OSX if  
this two files located together:
libQuantLib-0.9.8.dylib.dSYM
libQuantLib-0.9.8.dylib

by default "make install" will copy the dylib file to the installation  
location, since this should be the release version the debug  
informations (folder of lib*.dSYM) are not copied of course, but the  
library files still hold some debug information. So if an application  
based on QuantLib is debugged the gdb will create lots of warnings  
about missing debug info:
.....
warning: Could not find object file "/Users/tamas/Programming/ 
QuantLibRoot/QuantLib/ql/.libs/libQuantLib.lax/libCashFlows.a/ 
averagebmacoupon.o" - no debug information available for  
"averagebmacoupon.cpp"
___etc___
.....

to avoid this when the "make install" script is called, on OSX one  
should run
`strip -S libQuantLib-0.9.8.dylib`
before installing the library to its final location (eg removing all  
"useless"debug info from the library)

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

So the real question now is how to debug QuantLib on OSX Leopard?  
Well, during "make" one should keep these files:
ql/.libs/libQuantLib.lax/libCashFlows.a/averagebmacoupon.o
ql/.libs/libQuantLib.lax/libExperimental.a/abcdatmvolcurve.o

by forcing the libtool (or make script) to not to clean up after  
successful linking...

I hope this will help someone...

Best,

Tamas

Re: [Quantlib-dev] QuantLib linking causes debugger crash on OS X whether QuantLib used or not.

[Tamas S. <ta...@ao...>]

Hello Keith,

you did not install QuantLib to its default location eg : /usr/local/lib

please go to your QuatLib folder:
cd /Users/kw/MyC++/QuantLib-0.9.7

and type:
sudo make install 
(after giving your password the libs will be installed)
and compile your source with :

g++ -o qlTest  -g -I/usr/local/include qlTest.cpp -L/usr/local/lib  -lQuantLib

OR

if you don't want to install system wide (no need password) do:
cd /Users/kw/MyC++/QuantLib-0.9.7
../configure --prefix=/Users/kw/MyC++/QuantLib-0.9.7/build
make
make install

the QuantLib libs will be in : /Users/kw/MyC++/QuantLib-0.9.7/build/libs
and the includefiles will be in : /Users/kw/MyC++/QuantLib-0.9.7/build/includes

so compile your code with:

g++ -o qlTest  -g -I/Users/kw/MyC++/QuantLib-0.9.7/build/includes qlTest.cpp -L/Users/kw/MyC++/QuantLib-0.9.7/build/libs -lQuantLib

I hope this will help,

Best,

Tamas

On Thursday 05 March 2009 13:54:47 Keith Weintraub wrote:
> Tamas,
>    Here is what I did and got the same result.
> 
> 
> 
> qlTest.cpp and qlTest2.cpp are the same program.
> 
> The difference between the two build scripts is obvious. All  
> references to QuantLib in qlTestBuild2.sh have been taken out.
> 
> The executables both run fine from the command line.
> 
> The qlTest program crashes the debugger:
> 
> The info.plist files (I don't know what Mac OSX does with the "*.dSYM"  
> directory structure) differ so I am including them here as well:
> 
>   (I hope the naming is obvious here).
> 
> The only think I can think of that might be a little different is that  
> I "built" boost. In other words I did the section 5.1 part of the  
> boost installation page.
> 
> I have checked and I think I have the latest version of Xcode as well:
> 
> Here is the g++ version info:
> 
> /Users/kw/MyC++/boost_1_38_0 $ g++ -dumpversion
> 4.0.1
> 
> /Users/kw/MyC++/boost_1_38_0 $ g++ -version
> i686-apple-darwin9-g++-4.0.1: no input files
> 
> And the gdb version info is in the debuggerCrash.txt file above.
> 
> If there is something else that will help you help me please let me  
> know.
> 
> I really appreciate the help. I am also posting this to the quantlib- 
> dev list (if it goes through).
> 
> Thanks so much for your time and in advance for any future help!
> 
> KW
> 
> 
> 
> --
> 
> On Mar 5, 2009, at 3:45 AM, Tamas Sashalmi wrote:
> 
> > Hello Keith,
> >
> > I cannot reproduce your problem, please make sure you are using the  
> > newest
> > xcode (it comes with updated gdb, gcc etc):
> >
> > http://developer.apple.com/technology/xcode.html
> >
> > Also please compile your example code from terminal instead of  
> > eclipse.
> > (eclipse may use a special flag which cause the problem ) with -g  
> > flag  only
> > eg:
> >
> > g++ -o prgname  -g prgsrc.cc -L/usr/local/lib -lQuantLib
> > and see if gdb is working or not with the produced binary.
> >
> > Best,
> >
> > Tamas
> 
> 

Re: [Quantlib-dev] QuantLib linking causes debugger crash on OS X whether QuantLib used or not.

[Keith W. <kw...@gm...>]

Tamas,
   Here is what I did and got the same result.



qlTest.cpp and qlTest2.cpp are the same program.

The difference between the two build scripts is obvious. All  
references to QuantLib in qlTestBuild2.sh have been taken out.

The executables both run fine from the command line.

The qlTest program crashes the debugger:

The info.plist files (I don't know what Mac OSX does with the "*.dSYM"  
directory structure) differ so I am including them here as well:

  (I hope the naming is obvious here).

The only think I can think of that might be a little different is that  
I "built" boost. In other words I did the section 5.1 part of the  
boost installation page.

I have checked and I think I have the latest version of Xcode as well:

Here is the g++ version info:

/Users/kw/MyC++/boost_1_38_0 $ g++ -dumpversion
4.0.1

/Users/kw/MyC++/boost_1_38_0 $ g++ -version
i686-apple-darwin9-g++-4.0.1: no input files

And the gdb version info is in the debuggerCrash.txt file above.

If there is something else that will help you help me please let me  
know.

I really appreciate the help. I am also posting this to the quantlib- 
dev list (if it goes through).

Thanks so much for your time and in advance for any future help!

KW



--

On Mar 5, 2009, at 3:45 AM, Tamas Sashalmi wrote:

> Hello Keith,
>
> I cannot reproduce your problem, please make sure you are using the  
> newest
> xcode (it comes with updated gdb, gcc etc):
>
> http://developer.apple.com/technology/xcode.html
>
> Also please compile your example code from terminal instead of  
> eclipse.
> (eclipse may use a special flag which cause the problem ) with -g  
> flag  only
> eg:
>
> g++ -o prgname  -g prgsrc.cc -L/usr/local/lib -lQuantLib
> and see if gdb is working or not with the produced binary.
>
> Best,
>
> Tamas

Re: [Quantlib-dev] building under x64

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

On Wed, 2009-03-04 at 11:41 +1100, Mark joshi wrote:
> As far as I can tell the type of Size is
> 
> const unsigned __int64
> 
> I am never very keen on using code with __ in it. What do you think?

I think it stinks...  sigh.  Had I faced this problem earlier on, I'd
have gotten rid of Null altogether and used boost::optional instead.
Now it's probably too messy to tackle before 1.0.

Anyway: the specialization would be into a VC9-specific section of code,
so I think it's not a bit deal if we use the specific __int64 type.

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] Towards version 1.0 - plans for home stretch

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

On Mon, 2009-03-02 at 00:34 -0800, Chris Kenyon wrote:
> Re inflation there are a number of changes in the pipeline:
> 
> 1) add the calibration stability updates for inflation vol
> 
> 2) add the tests for the inflation vol 
> 
> 3) move the inflation vol to the main area (i.e. out of experimental)
> 
> 4) add seasonality (multiplicative)
> 
> Timeframe realistically is around three to four weeks, say the end of
> March.  How does that suit for these steps?  I'd like to have infl vol
> out of experimental for 1.0, what do you think?

Timeframe is OK. I'd leave inflation vol in experimental for 0.9.9/1.0,
though, since it would be the first release that includes it.

Luigi



-- 

A debugged program is one for which you have not yet found the 
conditions that make it fail. 
-- Jerry Ogdin 

Re: [Quantlib-dev] QuantLib linking causes debugger crash on OS X whether QuantLib used or not.

[Tamas S. <ta...@ao...>]

Hello Keith,

I cannot reproduce your problem, please make sure you are using the newest 
xcode (it comes with updated gdb, gcc etc):

http://developer.apple.com/technology/xcode.html

Also please compile your example code from terminal instead of eclipse. 
(eclipse may use a special flag which cause the problem ) with -g flag  only  
eg:

g++ -o prgname  -g prgsrc.cc -L/usr/local/lib -lQuantLib
and see if gdb is working or not with the produced binary. 

Best,

Tamas

On Wednesday 04 March 2009 22:43:28 Keith Weintraub wrote:
> OK. Here is more information:
>
> I have compiled and linked the following program:
>
>    #include <iostream>
>    #include <string>
>
>    int main()
>    {
>
>     std::cout << "Hello GDB How Art Thee" << std::endl;
>    }
>
>
> Note that QuantLib is not used anywhere. If I link with -lQuantLib gdb
> crashes. Whether I use gdb in Eclipse or out of Eclipse it crashes.
>
> If I just run the program from the command line it runs fine whether the
> program was linked with QuantLib or not.
>
> If you haven't seen any of my posts before please note that I have the same
> problem whether the program uses QuantLib or not.
>
> I am very puzzled but I am sure one of you smart people has the answer.
>
> Thanks for your time,
> KW
>
>
>
>
> ---------------------------------------------------------------------------
>--- Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing
> the Enterprise -Strategies to boost innovation and cut costs with open
> source participation -Receive a $600 discount off the registration fee with
> the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Confronting the upfront

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

Hello again,
my drive is quite a mess with so many versions of the lib and two of the files I
have send you are the wrong ones. Please substitute them by these (for the new
interface case).

Apologies
Pepe

[Quantlib-dev] QuantLib linking causes debugger crash on OS X whether QuantLib used or not.

[Keith W. <kw...@gm...>]

OK. Here is more information:

I have compiled and linked the following program:

   #include <iostream>
   #include <string>

   int main()
   {

   	std::cout << "Hello GDB How Art Thee" << std::endl;
   }


Note that QuantLib is not used anywhere. If I link with -lQuantLib gdb crashes.
Whether I use gdb in Eclipse or out of Eclipse it crashes.

If I just run the program from the command line it runs fine whether the program
was linked with QuantLib or not.

If you haven't seen any of my posts before please note that I have the same
problem whether the program uses QuantLib or not.

I am very puzzled but I am sure one of you smart people has the answer.

Thanks for your time,
KW