quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] yield term structure again

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

Hi all

as you might have noticed I'm working on term structures.
A few questions:

1) Enrico, have you figured out if the currency() method is really relevant 
for RiskMap's code? I would really like to remove it.
2) I would also like to remove todaysDate(), todaysDate_, and minTime(), 
assuming that the minimum time is always t=0.0 at the settlementDate, where 
I have discount = 1.0
Anyone against this change?
3) I fixed 2 bugs in DiscountCurve, but I still have problems with 
calculations between settlementDate and the first knot date, probably due 
to some problem in LogLinearInterpolation. Have someone ever used this 
classes? Do they work for you?
4) I would also like to move daycounter to the last position in the 
constructors' parameters list, so to allow for a default value (act/365, or 
act/act ISDA)
Anyone against this change?

ciao -- Nando

Re: [Quantlib-dev] term structures

[<enr...@ri...>]

>>>>> "nando" == Ferdinando Ametrano <fer...@am...> writes:

    nando> Hi all 1) I would like to remove the currency_ data member
    nando> and the currency() method from the term structure
    nando> interface. This is mainly because it is not really used in
    nando> QuantLib, except forcing the user to provide a currency to
    nando> the constructor.  In my opinion the term structure currency
    nando> definition is another issue we should revise if/when we
    nando> have a currency framework.  Anyone against this change?

hi nando,
I think there could be application code using the currency() method
(maybe here in RiskMap we use it, I can't remember), so  maybe we
could: 
 * overload the constructor, providing a "currencyless" constructor
   and throw an exception from the currency() method iff currency_ ==
   INVALID_CURRENCY (we could add an INVALID_CURRENCY item to the
   Currency enum, in case it doesn't break other stuff)
 * provide a default currency value (I would'n like it btw).
what do you think?
ciao,
enrico

-- 
Enrico Sirola <en...@us...>
gpg public key available from wwwkeys.pgp.net
Key fingerprint = B446 7332 ED55 BC68 5FE8  DE0F 98DF EC86 377F E07F

[Quantlib-dev] Encapsulation? not

[Luigi B. <bal...@ma...>]

Hi all,

class Path {
   public:
     ...
     const std::vector<Time>& times() const;
     std::vector<Time>& times();
     const Array& drift() const;
     Array& drift();
     const Array& diffusion() const;
     Array& diffusion();
   private:
     std::vector<Time> times_;
     Array drift_;
     Array diffusion_;
};

This is kind of silly. We aren't encapsulating anything this way.
Any objection to recode the above as:

class Path {
   public:
     ...
     std::vector<Time> times;
     Array drift;
     Array diffusion;
};

?

Bye,
	Luigi

[Quantlib-dev] term structures

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

Hi all

1) I would like to remove the currency_ data member and the currency() 
method from the term structure interface. This is mainly because it is not 
really used in QuantLib, except forcing the user to provide a currency to 
the constructor.
In my opinion the term structure currency definition is another issue we 
should revise if/when we have a currency framework.
Anyone against this change?

2) I would provide a default 'Time minTime()' implementation in the base class:
     inline Time TermStructure::minTime() const {
             // minDate() could return todaysDate() instead of
             // the usual settlementDate(), so that the minTime
             // could be negative
             return dayCounter().yearFraction(settlementDate(), minDate());
     }
and I would revise any instance of 'QL_REQUIRE(t>=0.0' in term of 
'QL_REQUIRE(t>=minTime()'
Is it OK?

ciao -- Nando

Re: [Quantlib-dev] Some questions

[Luigi B. <bal...@ma...>]

At 12:43 PM 6/14/02 +0200, Ferdinando Ametrano wrote:
>We currently have FiniteDifferenceModel and MonteCarloModel, but I would 
>say their names can be misleading, since a model is not strictly related 
>to the numerical approach used to implement it.

We're modeling apples and oranges here :)
Finite differences methods model _an equation_ by discretizing it.
Monte Carlo is more a technique than a model though.
Any ideas for a better name?


>Is a PricingEngine (analityc, FD, MC) a model or an object used to perform 
>calculation for different models?

It is an engine, i.e., a calculation. The details of the latter most likely 
depend on a model _and_ a numerical technique used for solving the 
equations describing the model.


>I see 3 components here: a description of the market (the yield curve, the 
>Black surface, etc.), a model (eg. constant volatility Black model, time 
>dependant volatility, time/strike dependent volatility), and a numerical 
>approach (analytic, FD, MC).
>Should the market description be an input of the Instrument/model/both?

I'd say that what changes on a per-model basis belongs to specific models.


>What about the dividend yield term structure? It probably belongs to the 
>"underlying" of the option, but ... what if I want to model a stochastic 
>process for dividends?

Beats me. We can leave where it is now and think about it when you'll model 
a stochastic process for dividends.


>Many questions and few answers, I know.
>I would suggest that we try to have a realistic general design, carefully 
>avoiding design paralysis. I would define a good design the one that 
>solves our _current_ problems. The price to pay is to have to refactor the 
>code later.

_Emphasis_ and acting bold won't make your definition any better, you know.
Even though it's a standard meeting technique :)

I agree though. I think in this case we can make single incremental changes 
(e.g., moving the volatility to the model and leave the yield curve alone 
while we think about it) when single problems arise.

Bye,
         Luigi

Re: [Quantlib-dev] Some questions

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

Hi all


>>In vanilla option:
>>we should not input a volatility. It should be the pricer that has a Black
>>model (a volatility) as an input... the volatility is part of the model, not
>>of  the instrument, IMHO.
>
>Kind of makes sense. Even though only exercise date, strike and type are 
>really part of the instrument---the yield term structure could be 
>considered part of the model too, and the current underlying price is a 
>market datum. People?
This question raises a good point.
The first problem I see is the definition of 'model'.
We currently have FiniteDifferenceModel and MonteCarloModel, but I would 
say their names can be misleading, since a model is not strictly related to 
the numerical approach used to implement it.
Is a PricingEngine (analityc, FD, MC) a model or an object used to perform 
calculation for different models?

Take the Black (market) vol surface for an equity index as a concrete 
example. This is a market observable, model independent.

Different models extract their own volatility from this surface in 
different ways: the Black model would just interpolate on this surface, 
while Derman/Kani would extract local volatilities for the underlying's 
stochastic process. These volatilities do belong to the model, the Black 
surface doesn't.

So I see 3 components here: a description of the market (the yield curve, 
the Black surface, etc.), a model (eg. constant volatility Black model, 
time dependant volatility, time/strike dependent volatility), and a 
numerical approach (analytic, FD, MC).
Should the market description be an input of the Instrument/model/both?

What about the dividend yield term structure? It probably belongs to the 
"underlying" of the option, but ... what if I want to model a stochastic 
process for dividends?

Many questions and few answers, I know.
I would suggest that we try to have a realistic general design, carefully 
avoiding design paralysis. I would define a good design the one that solves 
our _current_ problems. The price to pay is to have to refactor the code later.

>>Why not have a single instrument class, that would be nearly the same as the
>>present Option class? Stocks and swaps could then be priced with appropriate
>>pricing engines (see 3))... A swap, for example, could be priced on two
>>different term structures (Andre had to add a method to do this), or priced
>>with finite-difference methods for didactical purposes.
>Good thinking. We can just give Instrument::performCalculation the 
>implementation currently in Option.
I agree

>>How do we know in which currency the NPV is given? Instruments should have a
>>currency method...
>Or maybe a Money structure could be returned with an amount and a currency.
>The same could hold for nominals and prices.
I agree, but I would be careful to enforce this as long as we don't settle 
on a "Currency" design. That is, should I check that the yield curve 
provided to my swap has the same currency of the swap nominal? As long as 
these details are not clear I would prefer the user to take the charge of 
aggregating all the instruments of a given currency.

>I would like some way to pass a Stock instance or one of  its attributes as
>the underlying, in the construction of a VanillaOption instance.
I like this approach

>Of course, we could define the underlying to be an Instrument, but if the
>option is in fact an FX option, what do we do? Do we define Cash/Money to be
>an instrument?
I would say that Cash/Money is an instrument accruing interest and subject 
to cross currency risk.

>I think there are some american options that cannot be exercised before a
>starting date. That's why AmericanExercise instances are constructed using
>AmericanExercise(Date earliestDate, Date latestDate). This is also the way
>FpML implements the american exercise type. So, the present interface of
>VanillaOption cannot handle this case. Perhaps we should replace
>"Date exerciseDate" by "Exercise exercise".
I agree.

ciao -- Nando

Re: [quantlib-dev] Some questions

[Sadruddin R. <sad...@gm...>]

Hi Luigi,
> As for the American, one just has to pass an American engine to the=20
> VanillaOption.
I think there are some american options that cannot be exercised before a
starting date. That's why AmericanExercise instances are constructed usin=
g
AmericanExercise(Date earliestDate, Date latestDate). This is also the wa=
y
FpML implements the american exercise type. So, the present interface of
VanillaOption cannot handle this case. Perhaps we should replace=20
"Date exerciseDate" by "Exercise exercise".

Sad

RE: [Quantlib-dev] Some questions

[Andre L. <An...@de...>]

Hi,

Agree with Luigi, just 2 cents worth additionally:

> >How do we know in which currency the NPV is given? 
> Instruments should have a
> >currency method...
> 
> Or maybe a Money structure could be returned with an amount 
> and a currency.
> The same could hold for nominals and prices. But I'm not sure 
> about this.
> Anyway, I agree that the problem exists.
> 

It is definately a problem, especially when multi-currency instruments are
involved. a Money structure is a good idea. Any value where a currency is
involved would need to return this.

Andre
 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

Re: [quantlib-dev] some questions

[Luigi B. <bal...@ma...>]

At 11:37 AM 6/13/02 +0000, Sadruddin Rejeb wrote:
> > If it's for the sake of pricing stocks, we can just override
> > performCalculations in the Stock class to short-circuit the pricing
> > engine.
>Sure, but I was thinking of a generic pricer that would apply to all
>instruments directly quoted as prices. If for example, I have a plain-vanilla
>option in my portfolio, I may want that its NPV is directly linked to some
>market price.

Oh, ok, I see that. I agree.


> >>5)
> >>I would like some way to pass a Stock instance or one of its attributes as
> >>the underlying, in the construction of a VanillaOption instance.
> >>Of course, we could define the underlying to be an Instrument, but if the
> >>option is in fact an FX option, what do we do? Do we define Cash/Money to
> >> be an instrument?
> >
> >I'm not getting this, but then again, it's 11pm.
>
>What I meant is:
>If I have a Stock instance, and I want to define an option on it, how can I
>do this if I don't have access to the MarketElement linked to the stock
>  price? What I was thinking is that we may want the underlying to be an
>  instrument instead of a MarketElement.

And then call NPV() instead of value(). Yes, I agree.


>Then, I have other questions. Does the VanillaOption class refer to
>stock-options only, or is it supposed to include FX vanilla-options?
>And are we going to define another class for american options?

As for the American, one just has to pass an American engine to the 
VanillaOption.

As for FX options, VanillaOption could be used if they take the same 
parameters. However, I'm not sure that it wouldn't be better to 
differentiate the two just for ease of understanding.

Thoughts?

         Luigi

Re: [quantlib-dev] some questions

[Sadruddin R. <sad...@gm...>]

Hi Luigi,

> If it's for the sake of pricing stocks, we can just override
> performCalculations in the Stock class to short-circuit the pricing
> engine.

Sure, but I was thinking of a generic pricer that would apply to all
instruments directly quoted as prices. If for example, I have a plain-van=
illa
option in my portfolio, I may want that its NPV is directly linked to som=
e
market price.

>>5)
>>I would like some way to pass a Stock instance or one of its attributes=
 as
>>the underlying, in the construction of a VanillaOption instance.
>>Of course, we could define the underlying to be an Instrument, but if t=
he
>>option is in fact an FX option, what do we do? Do we define Cash/Money =
to
>> be an instrument?
>
>I'm not getting this, but then again, it's 11pm.
>Would you pseudo-code an example? A couple of constructors, for instance=
?

Yeah, I agree it's not crystal-clear. It may even be completly naive.
What I meant is:
If I have a Stock instance, and I want to define an option on it, how can=
 I
do this if I don't have access to the MarketElement linked to the stock
 price? What I was thinking is that we may want the underlying to be an
 instrument instead of a MarketElement.

Then, I have other questions. Does the VanillaOption class refer to
stock-options only, or is it supposed to include FX vanilla-options?
And are we going to define another class for american options?

Later,
Sad

Re: [Quantlib-dev] Some questions

[Luigi B. <bal...@ma...>]

Hi Sad,

At 1:44 AM +0200 6/12/02, Sadruddin Rejeb wrote:
>1)
>In vanilla option:
>we should not input a volatility. It should be the pricer that has a Black
>model (a volatility) as an input... the volatility is part of the model, not
>of  the instrument, IMHO.

Kind of makes sense. Even though only exercise date, strike and type 
are really part of the instrument---the yield term structure could be 
considered part of the model too, and the current underlying price is 
a market datum. People?

Also,
s/a volatility/a volatility term structure/
(and let's see how many people blink at the above :)


>2)
>Why not have a single instrument class, that would be nearly the same as the
>present Option class? Stocks and swaps could then be priced with appropriate
>pricing engines (see 3))... A swap, for example, could be priced on two
>different term structures (Andre had to add a method to do this), or priced
>with finite-difference methods for didactical purposes.

Good thinking. We can just give Instrument::performCalculation the 
implementation currently in Option.


>3)
>Define a generic MarketPricingEngine that just returns the value of a market
>element.

If it's for the sake of pricing stocks, we can just override 
performCalculations in the Stock class to short-circuit the pricing 
engine.


>4)
>How do we know in which currency the NPV is given? Instruments should have a
>currency method...

Or maybe a Money structure could be returned with an amount and a currency.
The same could hold for nominals and prices. But I'm not sure about this.
Anyway, I agree that the problem exists.


>5)
>I would like some way to pass a Stock instance or one of its attributes as
>the underlying, in the construction of a VanillaOption instance.
>Of course, we could define the underlying to be an Instrument, but if the
>option is in fact an FX option, what do we do? Do we define Cash/Money to be
>an instrument?

I'm not getting this, but then again, it's 11pm.
Would you pseudo-code an example? A couple of constructors, for instance?

Bye for now,
		Luigi

[Quantlib-dev] Some questions

[Sadruddin R. <sad...@gm...>]

Hello guys,
Since there's a big refactoring going on, I'd like to share a few ideas that 
have occured to me this afternoon in the train, while browsing the source.

1)
In vanilla option:
we should not input a volatility. It should be the pricer that has a Black 
model (a volatility) as an input... the volatility is part of the model, not 
of  the instrument, IMHO.

2)
Why not have a single instrument class, that would be nearly the same as the
present Option class? Stocks and swaps could then be priced with appropriate
pricing engines (see 3))... A swap, for example, could be priced on two
different term structures (Andre had to add a method to do this), or priced
with finite-difference methods for didactical purposes.

3)
Define a generic MarketPricingEngine that just returns the value of a market 
element.

4)
How do we know in which currency the NPV is given? Instruments should have a 
currency method...

5)
I would like some way to pass a Stock instance or one of  its attributes as 
the underlying, in the construction of a VanillaOption instance.
Of course, we could define the underlying to be an Instrument, but if the 
option is in fact an FX option, what do we do? Do we define Cash/Money to be 
an instrument?

Thanks for reading all this,
Sad.

-- 
---\ Sadruddin Rejeb \-----
----\ +4179 200 58 36 \----
-----\ sad...@gm... \---

Re: [Quantlib-dev] SWIG interface files

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

Hi Andre

Luigi is the master of SWIG, but here's a few suggestions while we wait for 
his answer

>I have a cpp class in a library of my own that inherits off
>QuantLib::Instrument. I now need to create a SWIG file for this.
>I assumed that I would only need to "%import Instruments.i" to get the
>needed definitions, this leads to all kinds of compile errors.
>Using "%include Instruments.i" doesn't hack it either,
I would "%include ql.i", this will include all the QuantLib interfaces and 
this is probably what you want, since you will want your module to include 
the whole QuantLib module to use all the QuantLib feautures.

>but I get weird errors when using my library: accessing
>DayCounter.yearFraction(d1,d2) for instance gives me an error saying it
>needs 5 arguments (only 3 supplied) - it's as if it doesn't know the last 2
>are default arguments.
see the file QuantLib-Python\QuantLib\defaults.py for the specification of 
default values. Your module will need that file.

Hope this helps

ciao -- Nando

PS Luigi, when we'll settle on the new forthcoming version of SWIG with all 
languages consolidated into a single QuantLib-SWIG module, do you plan to 
provide an example on how to setup a project based on QuantLib-SWIG?
It would be similar in spirit to our C++ Examples based on QuantLib.

[Quantlib-dev] SWIG interface files

[Andre L. <An...@de...>]

Hi,

I have a cpp class in a library of my own that inherits off
QuantLib::Instrument. I now need to create a SWIG file for this.

I assumed that I would only need to "%import Instruments.i" to get the
needed definitions, this leads to all kinds of compile errors.
Using "%include Instruments.i" doesn't hack it either, redoing all the
needed "typedef" statements in my interface file solves the compile errors
but I get weird errors when using my library: accessing
DayCounter.yearFraction(d1,d2) for instance gives me an error saying it
needs 5 arguments (only 3 supplied) - it's as if it doesn't know the last 2
are default arguments.

This is my SWIG file:

#ifndef myinstr_i
#define myinstr_i

%include Instruments.i
%include TermStructures.i
%include String.i

%{
#include <myinstr.hpp>
using MyNameSpace::MyInstr;
typedef RelinkableHandle<QuantLib::TermStructure>
TermStructureRelinkableHandle;
typedef Handle<QuantLib::Instrument> InstrumentHandle;
typedef QuantLib::Handle<MyInstr> MyInstrHandle;
typedef std::string String;
%}

// fake inheritance between handles
%name(MyInstr) class MyInstrHandle
: public InstrumentHandle {
  public:
    // constructor redefined below
    ~MyInstrHandle();
};

%addmethods MyInstrHandle {
    MyInstrHandle(TermStructureRelinkableHandle tStruct, 
        String isinCode, String description) {
            return new MyInstrHandle(
	       new MyInstr(tStruct, isinCode, description));
    }
    double fairRate() {
       return (*self)->fairRate();
    }
}

#endif

What is the correct way of doing something like this (i.e using SWIG
interface-files from other projects)?

Any help appreciated.

Andre

 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

Re: [Quantlib-dev] Compounded Rates

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

Luigi wrote:
>         unfortunately I can't give this much thought today, so I'm not 
> sure that I see the larger picture here. Given your time constraints, I 
> think you can go ahead as long as the other methods keep returning the 
> same thing.
>
>Nando? Others?
it's OK for me.

Andre, in the medium term I would suggest you to create your own library 
based on QuantLib, so that you can hack it as much as you like, and later 
decide what to merge into QuantLib and what to keep proprietary. This is 
the way I work, and I get the additional benefit of hiding my dirty stuff ;-)

ciao -- Nando

Re: [Quantlib-dev] Compounded Rates

[Luigi B. <bal...@ma...>]

Andre,
	unfortunately I can't give this much thought today, so I'm not sure that I 
see the larger picture here. Given your time constraints, I think you can 
go ahead as long as the other methods keep returning the same thing.

Nando? Others?

Later,
	Luigi

[Quantlib-dev] Compounded Rates

[Andre L. <An...@de...>]

Hi,

I have a big need for a proper implementation of a compounded rate
termstructure. The proposal I have is as follows:

1) Given the current TermStructure, we need access methods for rates with a
supplied compounding frequency. I see these methods implemented in the
current TermStructure the same as the existing 'forward' methods with an
additional parameter specifying the frequency. An additional implementation
specific method is needed as well, something like 'compoundForwardImpl(Time,
int, bool extrapolate)'.

Additionally we need the following structures:
	1) CompoundForwardRateStructure, leaving the implementation of
compoundForwardImpl() to the programmer. It should implement discountImpl()
using a default discountfactor-bootstrapping methodology, to implement this
it would need to store the compounding frequency of it's rates.
	2) CompoundDiscountStructure, implementing compoundForwardImpl()
using a default reverse bootstrapping methodology on the supplied
compounding frequency.

2) Additionally it should be noted that a curve could be built up of rates
with mixed compounding frequencies, this could be solved by linking
different curves into one umbrella curve - this could be implemented in an
external structure (something like PiecewiseCompoundForward).	

Please comment ASAP as I need to do this by YESTERDAY!

Thanx,

Andre
 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

Re: [Quantlib-dev] MSVC Unresolved externals

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

At 08:20 AM 5/28/2002 +0200, Andre Louw wrote:
>I have a funny when building the SWIG wrapper on Win32 using the
>straightforward 'python setup.py build':
>
>The compile step goes well. When linking it gets a bunch (15) of unresolved
>externals:
My guess is that you're compiling the current CVS version of 
QuantLib-Python while linking an older QuantLib library.
Try to update your installed QuantLib version with the current CVS version.

Under Windows you might consider using the QuantLib-Python MS Visual Studio 
project, instead of the standard 'setup.py build'. The Visual Studio 
project has a few "OnTheEdgeXXX" build configurations that link the 
QuantLib version they find in a relative ..\QuantLib path instead of the 
installed one.
I use this trick to have a "stable" version of QuantLib installed, while 
hacking on the CVS trunk head. The only requirement is to check out all the 
CVS modules in the same folder as in:
Projects\QuantLib
Projects\QuantLib-Python
Projects\QuantLib-SWIG
Projects\QuantLibXL
Projects\xlw

Let me know if this solve your problem

ciao -- Nando

Re: [Quantlib-dev] plan for soap extension

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

Hi Xiaowen

>I've been thinking about the SOAP extension of
>Quantlib. The following is my thoughts that I'd like
>to discuss with you:
Please consider to write a QuEP to be published on the web site and 
announced on the quantlib-users list for general discussion. The material 
you posted here could be a good draft.
I know there are at least a couple of quantlib-users subscribers involved 
with FpML that could be interested in your project

>1) The target of QuantLib-SOAP is to provide
>portafolio evaluation functionalities accessible via
>standardized wire protocol(http,smtp etc).
While I do not feel qualified on the technical (protocol, stateless session 
beans, etc.) side
I wonder if you have a list of functionalities you plan to provide. I would 
say that even a limited set of functionalities would be ok to start working 
on a proof of concept

>2) QuantLib-SOAP requires a complete C++ binding for
>FpML specification.
FpML specification support is in my opinion one of the most important 
QuantLib goal.

>This binding scheme will be realized in two code
>layers:
>a) FpML elements to weak typing C++ binding. This
>layer should be generated using automatic code
>generator, because the sheer volume of components in
>FpML spec is large. And because FpML is specified
>using DTD, which is weak typing (everything is bound to
>string), the C++ objects generated from this layer are
>weak typing.
>
>b) A thin layer of C++ wrapper objects for the weak
>typing C++ objects generated in a). This layer is
>nothing but type checking and conversion. As a
>reference note, the XML Java binding (JAXB) is
>currently also in this stage. Strong type checking is
>achieved through an extra type binding xml file.
Mmmm ... I'm not sure I got this description. Sorry for being so naive, but 
could you provide an example?
BTW FpML is moving to Schema instead of DTD

>3) The extension needs some helper classes to
>interface with the selected wire protocols to
>participate in the RPC.
Once again I would appreciate a concrete example

If/when you need a QuantLib-SOAP module, just let me know and I'll create it

ciao -- Nando

Re: [Quantlib-dev] Zero coupon rates

[Luigi B. <bal...@ma...>]

Hi Andre,

At 8:15 AM +0200 5/29/02, Andre Louw wrote:
>I am looking for a zero-coupon rate from a termstructure. I have been
>thinking of the following (assuming annual compounding):
>	given Time t and df at t
>		up-to compounding i.e t <= 1.0
>			zc = ((1.0/df)-1.0)/t
>		above compounding
>			zc = pow(1.0/df,1.0/t)-1.0
>
>Can I go ahead and implement this in termstructure.hpp?

I would implement it _on top_ of TermStructure rather that _in_ it. 
Could be the first step towards bonds, couldn't it?

Later,
	Luigi

-- 

[Quantlib-dev] Zero coupon rates

[Andre L. <An...@de...>]

Hi all,

I am looking for a zero-coupon rate from a termstructure. I have been
thinking of the following (assuming annual compounding):
	given Time t and df at t
		up-to compounding i.e t <=3D 1.0
			zc =3D ((1.0/df)-1.0)/t
		above compounding
			zc =3D pow(1.0/df,1.0/t)-1.0

Can I go ahead and implement this in termstructure.hpp?

Andr=E9 Louw
Decillion Limited - "Your Risk Is Our Domain"

Email:	an...@de...
Office:	+27 (11) 328 1256
Mobile:	+27 (83) 414 5785
Fax:	+27 (11) 442 4456

=20
------------------------------------------------------------------------=
-
This e-mail is intended only for the use of the individual or entity =
named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the =
intended
recipient, you are hereby notified that any dissemination, distribution =
or
copying of this e-mail is strictly prohibited. Opinions, conclusions =
and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor =
endorsed by
it.

[Quantlib-dev] MSVC Unresolved externals

[Andre L. <An...@de...>]

Hi,

I have a funny when building the SWIG wrapper on Win32 using the
straightforward 'python setup.py build':

The compile step goes well. When linking it gets a bunch (15) of unresolved
externals:

quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
__thiscall QuantLib::Period::Period(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > const &)"
(??0Period@QuantLib@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocat
or@D@2@@std@@@Z)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
__thiscall
QuantLib::CashFlows::FloatingRateCoupon::FloatingRateCoupon(double,class
CashFlows::Date const &,class CashFlows::Handle<class
QuantLib::Indexes::Xibor> const &,class CashFlows::Date const &,class
CashFlows::Date const &,int,double,class CashFlows::Date const &,class
CashFlows::Date const &)"
(??0FloatingRateCoupon@CashFlows@QuantLib@@QAE@NABVDate@2@ABV?$Handle@VXibor
@Indexes@QuantLib@@@2@00HN00@Z)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
__thiscall QuantLib::TermStructures::CompoundForward::CompoundForward(class
std::vector<class QuantLib::Date,class std::allocator<class QuantLib::Date>
> const &,class vector<class QuantLib::Date,class std::allocator<class
QuantLib::Date> >::vector<double,class std::allocator<double> > const
&,class TermStructures::Date const &,class TermStructures::Date const &,enum
TermStructures::Currency,class TermStructures::DayCounter const &,class
TermStructures::Calendar const &,enum
TermStructures::RollingConvention,int)"
(??0CompoundForward@TermStructures@QuantLib@@QAE@ABV?$vector@VDate@QuantLib@
@V?$allocator@VDate@QuantLib@@@std@@@std@@ABV?$vector@NV?$allocator@N@std@@@
4@ABVDate@2@2W4Currency@2@ABVDayCounter@2@ABVCalendar@2@W4RollingConvention@
2@H@Z)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
__thiscall QuantLib::TermStructures::DiscountCurve::DiscountCurve(class
TermStructures::Date const &,class std::vector<class QuantLib::Date,class
std::allocator<class QuantLib::Date> > const &,class vector<class
QuantLib::Date,class std::allocator<class QuantLib::Date>
>::vector<double,class std::allocator<double> > const &,enum
TermStructures::Currency,class TermStructures::DayCounter const &,class
TermStructures::Calendar const &,enum TermStructures::RollingConvention)"
(??0DiscountCurve@TermStructures@QuantLib@@QAE@ABVDate@2@ABV?$vector@VDate@Q
uantLib@@V?$allocator@VDate@QuantLib@@@std@@@std@@ABV?$vector@NV?$allocator@
N@std@@@5@W4Currency@2@ABVDayCounter@2@ABVCalendar@2@W4RollingConvention@2@@
Z)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
virtual double __thiscall
QuantLib::Pricers::SingleAssetOption::theta(void)const "
(?theta@SingleAssetOption@Pricers@QuantLib@@UBENXZ)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
__thiscall QuantLib::TermStructures::SwapRateHelper::SwapRateHelper(class
TermStructures::RelinkableHandle<class QuantLib::MarketElement> const
&,int,int,enum TermStructures::TimeUnit,class TermStructures::Calendar const
&,enum TermStructures::RollingConvention,int,bool,class
TermStructures::DayCounter const &,int)"
(??0SwapRateHelper@TermStructures@QuantLib@@QAE@ABV?$RelinkableHandle@VMarke
tElement@QuantLib@@@2@HHW4TimeUnit@2@ABVCalendar@2@W4RollingConvention@2@H_N
ABVDayCounter@2@H@Z)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
__thiscall
QuantLib::TermStructures::PiecewiseFlatForward::PiecewiseFlatForward(enum
TermStructures::Currency,class TermStructures::DayCounter const &,class
TermStructures::Date const &,class TermStructures::Date const &,class
std::vector<class QuantLib::Handle<class
QuantLib::TermStructures::RateHelper>,class std::allocator<class
QuantLib::Handle<class QuantLib::TermStructures::RateHelper> > > const
&,double)"
(??0PiecewiseFlatForward@TermStructures@QuantLib@@QAE@W4Currency@2@ABVDayCou
nter@2@ABVDate@2@2ABV?$vector@V?$Handle@VRateHelper@TermStructures@QuantLib@
@@QuantLib@@V?$allocator@V?$Handle@VRateHelper@TermStructures@QuantLib@@@Qua
ntLib@@@std@@@std@@N@Z)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
__thiscall QuantLib::Pricers::CliquetOption::CliquetOption(enum
Pricers::Option::Type,double,double,class std::vector<double,class
std::allocator<double> > const &,class std::vector<double,class
std::allocator<double> > const &,class std::vector<double,class
std::allocator<double> > const &,class std::vector<double,class
std::allocator<double> > const &)"
(??0CliquetOption@Pricers@QuantLib@@QAE@W4Type@Option@2@NNABV?$vector@NV?$al
locator@N@std@@@std@@111@Z)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
double __thiscall QuantLib::Pricers::CliquetOption::value(void)const "
(?value@CliquetOption@Pricers@QuantLib@@QBENXZ)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
double __thiscall QuantLib::Pricers::CliquetOption::delta(void)const "
(?delta@CliquetOption@Pricers@QuantLib@@QBENXZ)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
double __thiscall QuantLib::Pricers::CliquetOption::gamma(void)const "
(?gamma@CliquetOption@Pricers@QuantLib@@QBENXZ)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
double __thiscall QuantLib::Pricers::CliquetOption::theta(void)const "
(?theta@CliquetOption@Pricers@QuantLib@@QBENXZ)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
double __thiscall QuantLib::Pricers::CliquetOption::vega(void)const "
(?vega@CliquetOption@Pricers@QuantLib@@QBENXZ)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
double __thiscall QuantLib::Pricers::CliquetOption::rho(void)const "
(?rho@CliquetOption@Pricers@QuantLib@@QBENXZ)
quantlib_wrap.obj : error LNK2001: unresolved external symbol "public:
double __thiscall QuantLib::Pricers::CliquetOption::dividendRho(void)const "
(?dividendRho@CliquetOption@Pricers@QuantLib@@QBENXZ)
build\lib.win32-2.2\QuantLib\QuantLibc.pyd : fatal error LNK1120: 15
unresolved externals

If I then go and execute exactly the same link command (copy and pasted from
the shell into a .bat file), these unresolved externals mysteriously
dissapear and the .pyd is fully usable! 

Any help appreciated!

André Louw
Decillion Limited - "Your Risk Is Our Domain"

Email:	an...@de...
Office:	+27 (11) 328 1256
Mobile:	+27 (83) 414 5785
Fax:	+27 (11) 442 4456

 
-------------------------------------------------------------------------
This e-mail is intended only for the use of the individual or entity named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this e-mail is strictly prohibited. Opinions, conclusions and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor endorsed by
it.

Re: [Quantlib-dev] Forex framework

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

Hi Sad

you wrote:
>I would like to know if there is anything happening on the Forex side in
>QuantLib. I remember a discussion on quantlib-users about a Currency QuEP,
>anything new about it?
Joel Nelson wrote a draft that I just committed under the QuantLib-site 
CVS. Check it out. It's quep006. For me it would be OK to publish it on 
quantlib.org

Last time he wrote me:
>you see, the thing is, right now i can't publish it
>myself.  i only have web mail access right now so my
>possibilities are a bit limited.
>
>i do have another version with the money formatting
>information.  let me send it to you.  if you don't
>mind could you put it up on the site for me?
I'm not even sure I replied to his last email. Shame on me. Joel, if you 
have an updated version send it to me or Sad and we'll publish it ASAP.

ciao -- Nando

PS sharing with you my personal joy: last Wednesday my wife delivered our 
second child, Simone. 

Re: [Quantlib-dev] Unresolved external

[Luigi B. <bal...@ma...>]

Hi,

>When importing QuantLib in a Python2.2 session running under Linux I get the
>following error:
>
>ImportError: /usr/local/lib/libQuantLib.so.0: undefined symbol:
>__gxx_personality_v0
>
>Any ideas?

I think I remember seeing something like this when compiling with gcc 
rather that explicitly specifying g++. I don't know what changed, 
though. Maybe you have some environment variable such as "CC" set to 
gcc?

Bye,
	Luigi

-- 

[Quantlib-dev] Unresolved external

[Andre L. <An...@de...>]

Hi all,

When importing QuantLib in a Python2.2 session running under Linux I =
get the
following error:

Traceback (most recent call last):
  File "setup.py", line 331, in ?
    version          =3D "0.3.1a0-cvs")
  File "/var/tmp/python2-2.2-root/usr/lib/python2.2/distutils/core.py", =
line
138, in setup
  File "/var/tmp/python2-2.2-root/usr/lib/python2.2/distutils/dist.py", =
line
893, in run_commands
  File "/var/tmp/python2-2.2-root/usr/lib/python2.2/distutils/dist.py", =
line
913, in run_command
  File "setup.py", line 175, in run
    TEST.test()
  File "QuantLib/test/QuantLibTestSuite.py", line 26, in test
    import QuantLib
  File "build/lib.linux-i686-2.2/QuantLib/__init__.py", line 20, in ?
    from QuantLib import *
  File "build/lib.linux-i686-2.2/QuantLib/QuantLib.py", line 2, in ?
    import QuantLibc
ImportError: /usr/local/lib/libQuantLib.so.0: undefined symbol:
__gxx_personality_v0

Any ideas?

I have been using it extensively up until Friday. After a CVS co this =
popped
up all of a sudden?

Andr=E9 Louw
Decillion Limited - "Your Risk Is Our Domain"

Email:	an...@de...
Office:	+27 (11) 328 1256
Mobile:	+27 (83) 414 5785
Fax:	+27 (11) 442 4456

=20
------------------------------------------------------------------------=
-
This e-mail is intended only for the use of the individual or entity =
named
above and may contain information that is confidential and privileged,
proprietary to the company and protected by law. If you are not the =
intended
recipient, you are hereby notified that any dissemination, distribution =
or
copying of this e-mail is strictly prohibited. Opinions, conclusions =
and
other information in this message that do not relate to the official
business of our company shall be understood as neither given nor =
endorsed by
it.