quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Please disregard previous message. Email confusion.

[Chuck H. <cah...@ea...>]

What's the emoticon for embarrassment?

[Quantlib-dev] 2 bedroom rent

[Chuck H. <cah...@ea...>]

Hi, 

This is Chuck in #12. My wife wants to know what the rent is for a 2 bedroom apartment in the Firs.

Thanks,
Chuck

[Quantlib-dev] ObjectHandler XLL

[eric e. <eri...@gm...>]

Hello

I'm interested in implementing ObjectHandler as an XLL such that the
object repository can be shared by other XLLs in the current Excel
session.  I've documented the idea in more detail at this link:

http://quantlib.org/objecthandler/ohxll.html

Any feedback would be welcome.  I intend to implement this in a CVS
branch to allow for it to be tested before being merged onto the
trunk.

Regards,
Eric

[Quantlib-dev] Quantlib within a multithreaded architecture.

[Toyin A. <toy...@ho...>]

Hi All,

As some of you may have noticed, I have pulled my CapeTools QuantLib Web 
Site. I am in the process of producing a new version which uses the current 
QuantLib C++ library, complete with user documentation.

I've been working with QuantLib the last serveral months looking at the 
possibility of producing
a commercial multithreaded .NET engine. Basically another layer on top on 
QuantLib C++
itself, rather than a total rewrite like I did before.

The previous approach was fine and educational in terms of how QuantLib is 
structured, but it was a pain in the neck to keep it up to date with the 
pace of development that the QuantLib guys were generating.

With a C# wrapper on top of the C++ framework in which the wrapper itself is 
enabled for multi-threaded use as well as other wrappers I am developing for 
.NET web services,  .NET remoting
and a full Excel implementation (1000+ Excel functions thus far...), I can 
concentrate on these sexy features without the full re-write of QuantLib in 
.NET.

The main problem I have found which would prevent this from working within a 
multi-threaded environment (Wrapper on top of the C++ layer), are those of 
the 3 Singleton classes.

ExchangeRateManager, IndexManager and Settings.

Now that first 2 are not that difficult to overcome as they are used in a 
relatively small portion of the QuantLib codebase. The latter class, 
Settings, is the problem.

This is used by almost every pricing, YieldCurve class.

Thus if you have the scenario, even within a multithreaded C++ application, 
where User A creates a YieldCurve (ie - the PiecewiseFlatForward class, 
using the constructor that takes a reference date) with reference date 
2/MAR/2005 and User B creates a similar curve with reference date 2/JUN/2006 
and both submit the request to a server, the server may strip the curves 
correctly, but when the 2 users want to calculate a swap price/rate, you now 
have a problem.

The Settings::instance.evaluationDate() function is called to retrieve the 
calculation date. But User A wants his at 2/MAR/2005  and UserB at 
2/JUN/2006.

You could override the evaluationDate() within the global Settings class in 
each case, but then you open up a can of worms because while UserA has set 
the Settings::instance.evalutionDate() (either externally, which is not a 
good idea, because he is manipulating a global variable) or the programmer 
in code within the wrapper swap() function, UserB may come in a split second 
later into the same function and change the value again, thus invalidating 
the results that UserA will generate.

You could add some sort of mutex within the Wrapper Swap() function to block 
the call until UserA has finished (The Swap function will manipulate the 
evaluationDate() function), but the locations within the QuantLib library 
where Settings::instance.evalutionDate()
are called are too numerous. Thus you would have to write some sort of 
critical section, mutex for the whole library or make the quantlib library 
single-threaded in use.

This problem is actually not only tied to YieldCurves, almost every pricing 
function is affected by this too. Thus anyone who wants to manipulate the 
evaluationDate() function within a multithreaded application is asking for 
trouble.

However, maybe you guys have a solution for this, or someone has encounted 
this and has a solution.

I had the chance on working on a similar library within a commercial bank 
for 6 years implementing everything from YieldCurves to the pricing and risk 
management of portfolios of CapFloors, Swaps and Swaptions. Also the pricing 
of exotic structured deals and I can tell you, the quantLib infrastructure, 
apart from CMS Swaps and portfolio and risk management features, contains 
nearly everything else that this library had. In addition, you have all the 
exotic option calculation as well.

By the way, apart from this singleton issue, I believe that this is the best 
library that all financial engineers should look at, if they want to get 
their C++ financial skills to up speed in a relatively short space of time.


Best Regards,
Toyin Akin.
CapeTools.

Re: [Quantlib-dev] Design question on virtual methods in QuantLib classes

[Luca B. <bao...@ti...>]

Actually I would prefer to avoid the use of any adapter classes (and the
Decorator design pattern certainly falls into this category). This is bec=
ause
using adapters (or decorators) would not solve many practical problems.

Indeed, consider the following simple issue (very common in my code): I w=
ould
like to create an instance of a Xibor object so I would need -among other=

inputs- an object of type Handle<YieldTermStructure>. Now I can't clearly=

use an object of type Handle<MyOwnYieldTermStructureClass>, as it is a co=
mpletely
different type. You can see that in such cases the use of Decorators (or
more generally adapters) can't  really help.



>-- Messaggio Originale --
>Subject: Re: [Quantlib-dev] Design question on virtual methods in QuantL=
ib
> classes
>Date: Thu, 28 Jul 2005 11:01:53 +0100


That=B4s a perfect setting to use the Decorator Design Pattern.



You basically encapsulate a YieldTermStructure QuantLib object as a priva=
te
member of your own MyOwnYieldTermStructureClass and delegate the existing=

functionality with no need for virtual functions nor inheritance. Decorat=
ors
provide a flexible alternative to subclassing for extending functionality=
.



---------------------- MENSAGEM ORIGINAL ----------------------

    

Hi all  

  

I have a question regarding the declaration of some methods in QuantLib c=
lasses.
 

  

Before asking the question I would like to describe my problem. I'm tryin=
g
 

to integrate my QuantLib-based pricers and models in the position-keeping=

 

software being used in the bank where I work.  

  

This is what I would like to do: I would like to derive my position-keepi=
ng
 

software classes from QuantLib "basic" classes, like e.g. YieldTermStruct=
ure,
 

BlackVolTermStructure, CapVolatilityStructure, and so on. In such a way I=

 

would be able to trasparently use QuantLib classes in the code I write, w=
hen
 

porting my proprietary pricers and models to the bank position-keeping so=
ftware.
 

  

But there is a problem in doing so: I would take as an example the class
 

YieldTermStructure, yet the same issue could go for many other QuantLib c=
lasses
 

as well. Basically the class YieldTermStructure only requires that I writ=
e
 

the discountImpl() method, which take as input a year-fraction. BUT -unfo=
rtunately-
 

the position-keeping software APIs only allow to compute discount factors=

 

using dates (not year-fractions) as inputs.  

I have temporarily solved this issue by writing a function converting a y=
ear
 

fraction to a date (once the day-counting convention has been specified).=

 

But this is somewhat "inelegant", and also inefficient for day-counters w=
here
 

a direct inversion formula could not be applied.  

  

Neverthless, there could be a simpler approach: if YieldTermStructure met=
hods
 

were all declared as virtual (like it always happens in Java) I could red=
efine
 

in my derived classes all the methods I need to, without worrying about i=
f
 

the inputs I can use are dates or year-fractions. Unfortunately, however,=

 

YieldTermStructure (and many other similar classes) declare as virtual on=
ly
 

discountImpl(), and not the other methods like discount(), zeroRate(), fo=
rwardRate()
 
and so on.  

Is there a rationale for not declaring all the methods in an "abstract" c=
lass
 

-like YieldTermStructure- as virtual?  

  

Sorry if I was bit long.  

Thanks in advance.  

  

Luca  

  

  



__________________________________________________________________
TISCALI ADSL 1.25 MEGA
Solo con Tiscali Adsl navighi senza limiti e telefoni senza canone Teleco=
m
a partire da  19,95 Euro/mese.
Attivala entro il 28 luglio, il primo MESE =E8 GRATIS! CLICCA QUI.
http://abbonati.tiscali.it/adsl/sa/1e25flat_tc/

Re: [Quantlib-dev] PiecewiseYieldCurve

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

On 07/28/2005 01:13:18 PM, Plamen Neykov wrote:
> I'm using the PiecewiseFlatForward and accounted some strange
> behaviour there
> - I think it is just because the  PiecewiseYieldCurve class had not
> overwritten the DiscountFactor discountImpl(Time) const method and
> therefore
> the calculate() method of the LazyObject (resp. the
> PiecewiseYieldCurve<C,I>::performCalculations() method) got never
> called.
>=20
> Am I seeing this correct or is there something other going wrong?

It's correct. I never noticed this bug as it is only triggered when =20
extrapolation =3D true. I fixed it in CVS and added a test.

Thanks,
	Luigi


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

There is no likelihood man can ever tap the power of the atom.
-- Robert Millikan, Nobel Prize in Physics, 1923

[Quantlib-dev] PiecewiseYieldCurve

[Plamen N. <Pla...@re...>]

Hi all,

I'm using the PiecewiseFlatForward and accounted some strange behaviour the=
re=20
=2D I think it is just because the  PiecewiseYieldCurve class had not=20
overwritten the DiscountFactor discountImpl(Time) const method and therefor=
e=20
the calculate() method of the LazyObject (resp. the=20
PiecewiseYieldCurve<C,I>::performCalculations() method) got never called.

I've added the following implementation in the PiecewiseYieldCurve and it=20
solved my problem:

template <class C, class I>
inline DiscountFactor PiecewiseYieldCurve<C,I>::discountImpl(Time t) const {
	calculate();
	return base_curve::discountImpl(t);
}


Am I seeing this correct or is there something other going wrong?

cheers
Plamen

[Quantlib-dev] Design question on virtual methods in QuantLib classes

[Luca B. <bao...@ti...>]

Hi all

I have a question regarding the declaration of some methods in QuantLib c=
lasses.

Before asking the question I would like to describe my problem. I'm tryin=
g
to integrate my QuantLib-based pricers and models in the position-keeping=

software being used in the bank where I work. 

This is what I would like to do: I would like to derive my position-keepi=
ng
software classes from QuantLib "basic" classes, like e.g. YieldTermStruct=
ure,
BlackVolTermStructure, CapVolatilityStructure, and so on. In such a way I=

would be able to trasparently use QuantLib classes in the code I write, w=
hen
porting my proprietary pricers and models to the bank position-keeping so=
ftware.

But there is a problem in doing so: I would take as an example the class
YieldTermStructure, yet the same issue could go for many other QuantLib c=
lasses
as well. Basically the class YieldTermStructure only requires that I writ=
e
the discountImpl() method, which take as input a year-fraction. BUT -unfo=
rtunately-
the position-keeping software APIs only allow to compute discount factors=

using dates (not year-fractions) as inputs.
I have temporarily solved this issue by writing a function converting a y=
ear
fraction to a date (once the day-counting convention has been specified).=

But this is somewhat "inelegant", and also inefficient for day-counters w=
here
a direct inversion formula could not be applied.

Neverthless, there could be a simpler approach: if YieldTermStructure met=
hods
were all declared as virtual (like it always happens in Java) I could red=
efine
in my derived classes all the methods I need to, without worrying about i=
f
the inputs I can use are dates or year-fractions. Unfortunately, however,=

YieldTermStructure (and many other similar classes) declare as virtual on=
ly
discountImpl(), and not the other methods like discount(), zeroRate(), fo=
rwardRate()
and so on.
Is there a rationale for not declaring all the methods in an "abstract" c=
lass
-like YieldTermStructure- as virtual?

Sorry if I was bit long.
Thanks in advance.

Luca





__________________________________________________________________
TISCALI ADSL 1.25 MEGA
Solo con Tiscali Adsl navighi senza limiti e telefoni senza canone Teleco=
m
a partire da  19,95 Euro/mese.
Attivala entro il 28 luglio, il primo MESE =E8 GRATIS! CLICCA QUI.
http://abbonati.tiscali.it/adsl/sa/1e25flat_tc/

[Quantlib-dev] Announcing ObjectHandler 0.1.1 and QuantLibAddin 0.3.10

[eric e. <eri...@gm...>]

ObjectHandler version 0.1.1 and QuantLibAddin version 0.3.10 have been
released and are available for download at
http://sourceforge.net/project/showfiles.php?group_id=3D12740

ObjectHandler and QuantLibAddin share the QuantLib project structure
with regard to distribution,  licensing, etc., all of which is
documented on the main QuantLib website:
http://quantlib.org

Please log any problems you have with this release in the SourceForge
bug tracker at
http://sourceforge.net/tracker/?group_id=3D12740&atid=3D112740
specifying the relevant package name and version number.

ObjectHandler
http://quantlib.org/objecthandler/

Integration of a generic C++ library such as Quantlib into
spreadsheets and other end user tools requires a standalone
ObjectHandler component, a repository allowing objects to be stored,
shared, updated, interrogated, and destroyed.

QuantLibAddin
http://quantlib.org/quantlibaddin/

QuantLibAddin supplements QuantLib's existing C++ API with an
additional, higher-level API, implemented as a procedural interface
that can be deployed on any platform capable of linking C++ libraries.
QuantLibAddin is less flexible than the native API but allows QuantLib
functionality to be loaded directly to end-user environments such as
spreadsheets.

         The QuantLib group

Re: [Quantlib-dev] MATLAB Extension

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

Pavel,
	apologies for the delay in answering.

On 06/28/2005 08:18:40 PM, Pavel Tugarin wrote:
>=20
> 1) How long could MATLAB Extension project take (specific deadline
> yet?) to complete and how much workforce could it require?

As for deadlines, there are none. As for how much it would take, I =20
think it largely depends on the technology one would use. Manual =20
binding would take forever. Does any kind of wrapper generator exist =20
for MATLAB? Also, you might want to take a look at the wrapper =20
generator Eric Ehlers implemented for his QuantLibAddin project---it =20
might be possible to add a MATLAB frontend. Eric, if you're reading, do =20
you have any comments?


> 2) What is the performce of MATLAB/Quantlib system compared to
> Quantlib-based framework built in C++.

I'm afraid I have no data on this.

Later,
	Luigi


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

Use every man after his desert, and who shall scape whipping?
-- Hamlet, Act II, scene II

Re: [Quantlib-dev] Problems with RamdomizedLDS and GenericLowDiscrepancy

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

On 06/21/2005 03:12:12 PM, hav...@el... wrote:
>=20
> I'm having problems compiling the following lines of code with 0.3.9.
>=20
>       typedef
> QuantLib::GenericLowDiscrepancy<QuantLib::RamdomizedLDS<QuantLib::SobolRs=
g,
>=20
> QuantLib::RandomSequenceGenerator<MersenneTwisterUniformRng> >,
>=20
> QuantLib::InverseCumulativeNormal>  GaussianRLDSCumulative;
>=20
>       GaussianRLDSCumulative::rsg_type gaussQuasiSeqGen2 =3D
>=20
> GaussianRLDSCumulative::make_sequence_generator(2*mTimeSteps,0);

Haavard,
	I managed to compile the above once I added the 'QuantLib::' =20
qualification before the MersenneTwisterUniformRng class. Does the =20
problem persist after doing this? What compiler are you using?

Later,
	Luigi


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

Flon's Law:
         There is not now, and never will be, a language in
         which it is the least bit difficult to write bad programs.

[Quantlib-dev] 0.3.10 candidate

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

Hi all,
	candidate tarballs for the 0.3.10 release are available at =20
<http://quantlib.org/prerelease/>. Please try them out---if no problems =20
are found, I'll make the release in a few days.

Thanks,
	Luigi

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

An ideal world is left as an exercise to the reader.
-- Paul Graham

Re: [Quantlib-dev] MATLAB Extension

[Mark T. <mtr...@gm...>]

Hi Pavel,

about 2 years ago I started a matlab extension and even posted a
message to the quantlib users group but now searching the archive I
can't find the email (maybe that's why I never heard responses from
anyone).  You can download the file from
"http://www.eng.uwaterloo.ca/~mrtreibe/Quantlib-Matlab-0.0.1.zip".=20
Even though the file says its GPL I'm now a BSD believer so consider
it BSD licensed.  After I made that version I re-wrote it based on
what I learnt developing that version before later abanding it.  That
version was much nicer than the one I attached (which is basically a
proof of concept based on ql 3.2 I beleive)  Unfortunately I had a
hard drive failing 8 months ago and I lost that newer version.

In general I came to the conclusion that a quantlib/matlab extension
isn't really feasible because you have to make huge concessions
because of matlab's interface.  Most of the comments I'm going to make
are based upon 6.1 (and probably 6.5) but I havn't checked whether
they've been corrected for 7.0.

1) You have to use a single mex function with a parameter that
specifies which quantlib function your actually calling because matlab
only supports one mex function per shared library.  This is a pretty
common workaround that I've seen others use for matlab.

2) There exists a cmex glue library for octave that allowed me to
provide octave support.  However I found that there was a memory leak
somewhere in either the glue library or octave's interface that make
it unstable.  The matlab interface was pretty stable.  Also there were
several other incapatibilities between matlab and octave which
unfortunately I forget.  That being said the native octave c interface
is a lot nicer than the matlab one but unfortunately I couldn't use
it.

3) The biggest limitation with the matlab interface is that while the
matlab m-language does provide object oriented capabilities, the mex
interface does not.  The mex interface is purely procedureal.  In fact
you cannot even create a new object through the mex interface, you
would have to describe the interface using m-files (basically how you
would normally do it through the m-language).  And then you would can
that object through the mex interface.

4) If you absolutely must write a matlab interface, I would suggest
writing developing swig support for matlab first and then using that
to develop the matlab interface.  That would conceivably automate a
lot of the mundane workarounds that have to be done everywhere.

I hope this helps...

Mark.

On 6/28/05, Pavel Tugarin <ptu...@gm...> wrote:
> To whom it may concern:
>=20
> I am writing regarding the proposed MATLAB extension. I am interested
> in this project, and potentially could work on it ( Please see my
> resume attached. What is not in the resume, however, is that I am
> starting my job as a software engineer at Teradyne in North Reading,
> MA on July 25).
>=20
> For now, I am doing research for Writing for Professions regarding
> financial modeling in MATLAB. I would like to talk to someone at
> Quantlib team and have some questions answered:
>=20
> 1) How long could MATLAB Extension project take (specific deadline
> yet?) to complete and how much workforce could it require?
>=20
> 2) What is the performce of MATLAB/Quantlib system compared to
> Quantlib-based framework built in C++.
>=20
> I would appreciate if someone could answer these. Also, I may be
> interested in contributing to this project in the near future.
>=20
> Thanks,
> Pavel
>=20
>=20
>

[Quantlib-dev] will be happy to contribute

[Ivan G. <geo...@vt...>]

I sent this message yesterday without realizing that I have to subscribe 
to the quantlib-dev list first, so it rebounced back to me. Here I 
re-post it again. Rgds.

Dear developers,

I will be happy to contribute to the Quantlib project. I am a physicist 
and currently work as a postdoc. I have been doing scientific 
programming in C/C++/Java for the last 6-7 years (mostly in plain C). 
Started to read about quantitative finance 6 months ago and will be 
happy to develop something on my own. From the TODO list the 
CliquetOption (local/global...) and the ExplicitEuler (Richardson 
extrapolation) seems appealing to me. Please let me know how to proceed. 
If you think I should start with something else, let me know.

Kind regards,
Ivan

[Quantlib-dev] will be happy to contribute

[Ivan G. <geo...@vt...>]

Dear developers,

I will be happy to contribute to the Quantlib project. I am a physicist 
and currently work as a postdoc. I have been doing scientific 
programming in C/C++/Java for the last 6-7 years (mostly in plain C). 
Started to read about quantitative finance 6 months ago and will be 
happy to develop something on my own. From the TODO list the 
CliquetOption (local/global...) and the ExplicitEuler (Richardson 
extrapolation) seems appealing to me. Please let me know how to proceed 
(please reply to me directly). If you think I should start with 
something else, let me know.

Kind regards,
Ivan

[Quantlib-dev] Looking for Quantlib Developers with 3-8 years of exp

[Mukesh <con...@et...>]

[Quantlib-dev] MATLAB Extension

[Pavel T. <ptu...@gm...>]

To whom it may concern:

I am writing regarding the proposed MATLAB extension. I am interested
in this project, and potentially could work on it ( Please see my
resume attached. What is not in the resume, however, is that I am
starting my job as a software engineer at Teradyne in North Reading,
MA on July 25).

For now, I am doing research for Writing for Professions regarding
financial modeling in MATLAB. I would like to talk to someone at
Quantlib team and have some questions answered:

1) How long could MATLAB Extension project take (specific deadline
yet?) to complete and how much workforce could it require?

2) What is the performce of MATLAB/Quantlib system compared to
Quantlib-based framework built in C++.

I would appreciate if someone could answer these. Also, I may be
interested in contributing to this project in the near future.

Thanks,
Pavel

[Quantlib-dev] Bond Rate Helper

[Joseph W. <jo...@co...>]

The simplest  yield term structure is probably FlatForward.cpp

[Quantlib-dev] Vanilla dividend engines

[Joseph W. <jo...@co...>]

The place to start is to look at the

QuantLib/ql/PricingEngines/Vanilla directory in the CVS tree.  Take a 
look at the fddividendengine classes.  They calculate the option price 
using the Black-Scholes equation with explicit calculation for the 
dividends.  Right now I'm trying to figure out how to generalize the 
engines to be useful for things other than options (namely convertible 
bonds).

As far as how dividends are represented.  The are currently stored as a 
vector inside of the VanillaOption class.  This is suboptimal for a 
number of reasons.  The first is that it doesn't use the scheduling and 
calendar classes or have provision for different times of options.  The 
other problem that it bothers me is that the dividends should be 
assocated with a stock, and not the option.  This is going to be a 
problem with modelling convertible bonds since the bond could turn into 
a dividend-paying stock.

One other thing I would advise you to do is to be bold in refactoring 
the classes.  I like the basic design of quantlib, but there are a lot 
of things that could be cleaned up, which haven't been for lack of time.

[Quantlib-dev] (no subject)

[Quentin A. <que...@su...>]

Dear Quantlib developers,

I'm an engineer from french engineering school Sup=E9lec and will be
graduating in september. I have a strong interest in mathematical finance=
,
and would like to contribute to this project. I would like to add a RGW
engine to the Vanilla engines in order to be able to price American
Options with  one discrete dividend (or many discrete dividends with an
approximation).

I'm currently looking at the code to see how much will have to be designe=
d
and implemented, mostly, I don't know which class, if any holds discrete
dividends information for a stock following a BS process I could only fin=
d
a dividend yield.




 Best Regards,
 Quentin Arnaud

Re: [Quantlib-dev] Bond Rate Helper

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

On 06/21/2005 07:22:38 PM, Chuck Hinman wrote:
> How does one use QuantLib to value a bond portfolio? I am trying to
> use the FloatingRateBond class but I don't understand what
> YieldTermStructure to give it. I had thought to use
> PieceWiseFlatForward but I don't see a bond rate helper to construct =20
> a fixed rate bond instruments. What do other people use to construct
> their bond price curves? Or must I write a bond rate helper class?

A bond rate helper would be the way to go. You can look at =20
SwapRateHelper to see how it can be implemented.

Later,
	Luigi

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

Everything that can be invented has been invented.
-- Charles Duell, Director of U.S. Patent Office, 1899

[Quantlib-dev] Problems with RamdomizedLDS and GenericLowDiscrepancy

[<hav...@el...>]

Hi,

I'm having problems compiling the following lines of code with 0.3.9.

      //typedef QuantLib::RamdomizedLDS<QuantLib::SobolRsg,
      //
QuantLib::RandomSequenceGenerator<MersenneTwisterUniformRng> > ranLDS;
      // Tried this before now it is copied into the below statement

      typedef
QuantLib::GenericLowDiscrepancy<QuantLib::RamdomizedLDS<QuantLib::SobolRsg,

QuantLib::RandomSequenceGenerator<MersenneTwisterUniformRng> >,

QuantLib::InverseCumulativeNormal>  GaussianRLDSCumulative;

      GaussianRLDSCumulative::rsg_type gaussQuasiSeqGen2 =

GaussianRLDSCumulative::make_sequence_generator(2*mTimeSteps,0);

My experience with c++ is limited but I have from time to time managed to
use QL. Previously I used the following line of code to do the same thing
with the sobol-generator (with success):

      QuantLib::LowDiscrepancy::rsg_type gaussQuasiSeqGen =

QuantLib::LowDiscrepancy::make_sequence_generator(2*mTimeSteps,0);

I dont quite see the difference when comparing the code above with the one
in rngtraits.hpp. Is it a bug or am I doing something wrong?

regards,
Haavard




                                NOTICE
               Please immediately e-mail back to sender 
               if you are not the intended recipient. 

               Thereafter delete the e-mail along with 
               any attachments without making copies. 

               Elkem reserves all rights of privilege, 
               confidentiality and copyright.

[Quantlib-dev] Bond Rate Helper

[Chuck H. <cah...@ea...>]

Hello,

How does one use QuantLib to value a bond portfolio? I am trying to use the FloatingRateBond class but I don't understand what YieldTermStructure to give it. I had thought to use PieceWiseFlatForward but I don't see a bond rate helper to construct a fixed rate bond instruments. What do other people use to construct their bond price curves? Or must I write a bond rate helper class?

Thank you, Charles Hinman

Re: [Quantlib-dev] Re: Bug#314650: quantlib: FTBFS (amd64/gcc-4.0): 'Observer' has not been declared

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

Dirk and Andreas,
	thanks for the report. I applied the patch to the main sources.

Cheers,
	Luigi

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

I have yet to see any problem, however complicated, which, when you
looked at it in the right way, did not become still more complicated.
-- Poul Anderson

[Quantlib-dev] Re: Bug#314650: quantlib: FTBFS (amd64/gcc-4.0): 'Observer' has not been declared

[Dirk E. <ed...@de...>]

Andreas,

Thanks, as always, for your gcc 4.0 patches. I am passing this on to the
quantlib-dev listm and I'm sure that the simple patch will find its way into
the CVS archive.

Regards, Dirk

On 17 June 2005 at 19:10, Andreas Jochens wrote:
| Package: quantlib
| Version: 0.3.9-6
| Severity: normal
| Tags: patch
| 
| When building 'quantlib' on amd64/unstable with gcc-4.0,
| I get the following error:
| 
|  g++ -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../.. -O0 -D_REENTRANT -MT bas
| ispointsensitivity.lo -MD -MP -MF .deps/basispointsensitivity.Tpo -c basispoints
| ensitivity.cpp  -fPIC -DPIC -o .libs/basispointsensitivity.o
| In file included from /usr/include/boost/config.hpp:35,
|                  from ../../ql/qldefines.hpp:28,
|                  from ../../ql/errors.hpp:27,
|                  from ../../ql/date.hpp:28,
|                  from ../../ql/calendar.hpp:27,
|                  from ../../ql/termstructure.hpp:27,
|                  from ../../ql/yieldtermstructure.hpp:28,
|                  from ../../ql/CashFlows/basispointsensitivity.hpp:28,
|                  from basispointsensitivity.cpp:21:
| /usr/include/boost/config/compiler/gcc.hpp:92:7: warning: #warning "Unknown comp
| iler version - please run the configure tests and report the results"
| ../../ql/Patterns/observable.hpp:44: error: 'Observer' has not been declared
| ../../ql/Patterns/observable.hpp:45: error: 'Observer' has not been declared
| ../../ql/Patterns/observable.hpp:46: error: 'Observer' was not declared in this
| scope
| 
| With the attached patch 'quantlib' can be compiled
| on amd64 using gcc-4.0.
| 
| Regards
| Andreas Jochens
| 
| diff -urN ../tmp-orig/quantlib-0.3.9/ql/Patterns/observable.hpp ./ql/Patterns/observable.hpp
| --- ../tmp-orig/quantlib-0.3.9/ql/Patterns/observable.hpp	2005-03-17 11:45:28.000000000 +0100
| +++ ./ql/Patterns/observable.hpp	2005-06-17 17:36:32.000000000 +0200
| @@ -30,6 +30,8 @@
|  
|  namespace QuantLib {
|  
| +    class Observer;
| +
|      //! Object that notifies its changes to a set of observables
|      /*! \ingroup patterns */
|      class Observable {

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
         -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'