quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Bugs-1297396 ] DSW file does not work !

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

Bugs item #1297396, was opened at 2005-09-21 10:28
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1297396&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Luigi Ballabio (lballabio)
Summary: DSW file does not work !

Initial Comment:
When opening QuantLib-0.3.10 in MSVisual studio 6 with
the QuantLib.dsw file, it does not work : the dsw file
seems to be a simple txt file for msvstudio !

You can use prjconverter
http://www.arstdesign.com/articles/prjconverter_demo.zip
to convert the sln (.NET equivalent of the dsw file).

fca...@ya...





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

>Comment By: Luigi Ballabio (lballabio)
Date: 2005-10-06 13:44

Message:
Logged In: YES 
user_id=75450

I could not reproduce the issue. It is likely to be a
configuration problem on the user machine.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2005-09-21 10:46

Message:
Logged In: NO 

In the patch section you can find a zip file containg all
correct dsp/dsw

fca...@ya...


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

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

[Quantlib-dev] Fitting parameter for g2++

[Lars S. <sch...@ya...>]

First of all thank you for a great library.

 

Can some one walk me through a rough solution fixing the a, b and rho parameters when calibrating using the g2++ model?

The Simplex optimization does not find the expected solution for yen Swaption volatility surfaces.

 

% I tries to keep the constraints inside of my required range but this fails. It looks as if this is not picket up correctly in the optimizer when calibrating.

% optimizer does not deliver the expected values if keeping a, b and rho constant. So that would mean that I would have to add some kind of other optimization that does not use all 5 parameters but only 2 (sigma and eta)

 

What would be a suitable solution for this problem?

 

Regards

Lars Schouw


		
---------------------------------
Yahoo! for Good
 Click here to donate to the Hurricane Katrina relief effort. 

Re: [Quantlib-dev] Checked in quantlib-perl

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

On 5 October 2005 at 09:27, Luigi Ballabio wrote:
| 
| On 10/05/2005 04:22:15 AM, Dirk Eddelbuettel wrote:
| > 
| > Do you know who is behind the R interface for Swig?
| 
| Googling gives me <http://www.omegahat.org/RSWIG/>, but that's all.
| For what matters, there's still no R-related code in the official SWIG  
| repository.

Good man, thanks. Joseph had sent me this in private mail too.

Omegahat once was meant to be the extension / successor / ... to R, but is
these days mostly the repository for the various activities of Duncan. He is
insanely creative, but doesn't always drive things to their conclusion. His
code typically is a little harder to install etc pp. His Java and Python
binding are examples of that...  So his code could linger in this for a
while, or it could make a quantum leap and get into SWIG upstream. Hard to
tell. 

Something to keep an eye on, as opposed to holding one's breath, I suppose.

Cheers, Dirk

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

Re: [Quantlib-dev] Checked in quantlib-perl

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

On 10/05/2005 04:22:15 AM, Dirk Eddelbuettel wrote:
>=20
> Do you know who is behind the R interface for Swig?

Googling gives me <http://www.omegahat.org/RSWIG/>, but that's all.
For what matters, there's still no R-related code in the official SWIG =20
repository.

Luigi


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

There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the
other way is to make it so complicated that there are no obvious
deficiencies.
-- C. A. R. Hoare

[Quantlib-dev] Re: [Quantlib-users] Ideas for two new classes

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

Daniel J. Duffy wrote:

> I use the Bridge pattern for PDE concept (a PDE has many 
> implementations), and I use Template Method for FDM hierarchy. Betewen 
> PDE and FDM I use standardised interfaces.
>  
> Do Quantlibbers use UML to communicate design ideas, or how does it 
> work in this case?

There is a lot of UML in the quantlib web.  In this case, I wasn't 
thinking in terms of any basic change to the basic class hierarchy or 
structure.  Merely two fairly localized (but important changes).  One of 
the purposes of these two changes is to decouple the FDM code from the 
rest of the system more so and so that we can then think about more 
fundamental changes to the way that the FDM engines work.

The FDM hierarchy already uses the template pattern.  The problem is the 
that right now quantlib creates the FDM operators directly from the 
black scholes process.  This couples the FDM far too closely to 
Black-Scholes.

IMHO, the way that it should work is that the BS process creates a PDE 
object and this PDE object is what get finite differenced.  The other 
problem is that right now the FD pricing engines create a pricing curve 
which can be used to create a delta and a gamma curve, but all of that 
gets thrown away.  Having a sampled curve class will let the price curve 
available as a class which you can then process. 

One problem with the sampled curve class is that it is based on the 
quantlib Array class and Array is hard coded to use Real's.

As far as what the PDE object should look like....

I hear that someone wrote a book on "Financial Instrument Pricing Using 
C++" where he spends an several chapters on this topic.  Hmmmmm.... :-) 
:-) :-) :-)

>  
> Daniel
>
> ------------------------------------------------------------------------
> *From:* qua...@li... on behalf of Joseph 
> Wang
> *Sent:* Sat 01/10/2005 02:48
> *To:* qua...@li...; 
> qua...@li...
> *Subject:* [Quantlib-users] Ideas for two new classes
>
> math/SampledCurve - represents a curve which consists of n+1 arrays, one
> for the independent values and n dependent values.  Methods of this
> class will allow for interpolation and generating first and second
> derivative curves.
>
> PartialDifferentialEquation - represents a PDE
>
> The idea behind these new classes will be to clean up the finite
> differencing code a bit.  Instead of deal with raw arrays, the code will
> deal with SampledCurve's which will have facilities to allow
> interpolation, and the finite difference class will be able to pass the
> SampleCurve back up to the instrument where things can be done with it
> such as calculating delta curves and option curves.
>
> The idea behind a PDE class is to separate the processes from the finite
> differencing code.  For example the BlackScholes process will generate a
> PDE object and the fd code will generate the finite difference operators
> from the PDE object rather than the BlackScholes process itself.
>
> The idea behind this is to improve code clarity as well as to allow for
> PDE arithmetic.  Also, I suspect that there are some very clever things
> that one can do with Feymann-Kac once we have this in place.
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Quantlib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-dev] Re: [Quantlib-users] isTimeDependent ???

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

Maybe the way to have both "smart libaries" and "smart users" is to have 
a singleton factory class which takes an instrument and then set it with 
the best guess pricing engine.

For example

PricingEngineHelper::setToFiniteDifference(instrument)
setToBinomialTree
setToMonteCarlo



Luigi Ballabio wrote:

>
> On 10/01/2005 05:23:13 PM, Joseph Wang wrote:
>
>> I think this depends on user requirements.  There is a trade-off  
>> between keeping track of these things so that the library figures 
>> out  these things and letting the user use the library in ways that 
>> aren't  mathematically correct but gets you a quick and dirty answer.
>>
>> Where this bothered me was if you use the analytic pricing engines  
>> against instruments with changing interest rates, you will get the  
>> wrong answer.
>
>
> Not necessarily---for an European option, simply using the zero-yield  
> to maturity gives you the right price, not an approximation (the 
> actual  shape of the yield term structure doesn't matter, only its 
> integral.)
>
> The principle I would stick to is that users know better. I'm afraid  
> that trying to have the library do what it thinks the Right Thing 
> might  prevent users to do what they know to be the right thing.
>
> Later,
>     Luigi
>
>
> ----------------------------------------
>
> Hanlon's Razor:
>         Never attribute to malice that which is adequately explained
>         by stupidity.

Re: [Quantlib-dev] Checked in quantlib-perl

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

On 4 October 2005 at 00:09, Joseph Wang wrote:
| Luigi Ballabio wrote:
| 
| >
| > 1) there's a few SWIG warnings due to its not wrapping operator(). Is  
| > there any special way in Perl to call function objects, or should we  
| > just rename to methods such as "value"?
| >
| There doesn't seem to be any convention so we can probably invent one.  
| value seems alright.
| 
| > 2) With some guesswork, I modified the European option example so 
| > that  it uses the generated shadow classes rather than the low-level  
| > QuantLibc functions---I just committed it. But since I don't know 
| > Perl,  I couldn't figure out how to avoid having to write QuantLib::  
| > everywhere. may you have a look at it?
| 
| I know perl, but I'm trying to figure out SWIG :-(
| 
| The trouble is that in perl QuantLib and QuantLib::Date are both symbols 
| that have nothing to do with each other.  There may some clever SWIG way 
| of solving this, but it's not immediately obvious.
| 
| Linking in perl with quantlib was remarkable easy. 
| 
| Now for something really challenging.....
| 
| I see there are experimental SWIG interfaces for clisp and R.  Now 
| maxima works in clisp......

Do you know who is behind the R interface for Swig? I haven't heard anything
about that from the R upstream folks (but am of course not privy to all their
conversations either).

Dirk

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

[Quantlib-dev] Question on Caps/Floors pricing on InArrear cashflows.

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

Hi all,

Within Quantlib you can create an array of cashflows which can then be 
passed into the CapFloor constructor.

My question is whether the pricing logic within the CapFloor class is 
correct for InArrear cashflows?

The CapFloor class takes as it's exercise date for all the 
caplet's/floorlet's the fixing date of the coupon.

Under a UpFrontIndexedCoupon this would be settleDays before the start date 
of the period.
Under an Inarrearindexedcoupon this would be settleDays before the end date 
of the period.

Thus when pricing a caplet/floorlet which is based on an 
Inarrearindexedcoupon, should the
exercise date still be settleDays before the start date of the period?

My guess is that the exercise date should be settleDays before the start 
date of the period.

Best Regards,
Toyin Akin.

Re: [Quantlib-dev] Checked in quantlib-perl

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

Luigi Ballabio wrote:

>
> 1) there's a few SWIG warnings due to its not wrapping operator(). Is  
> there any special way in Perl to call function objects, or should we  
> just rename to methods such as "value"?
>
There doesn't seem to be any convention so we can probably invent one.  
value seems alright.

> 2) With some guesswork, I modified the European option example so 
> that  it uses the generated shadow classes rather than the low-level  
> QuantLibc functions---I just committed it. But since I don't know 
> Perl,  I couldn't figure out how to avoid having to write QuantLib::  
> everywhere. may you have a look at it?

I know perl, but I'm trying to figure out SWIG :-(

The trouble is that in perl QuantLib and QuantLib::Date are both symbols 
that have nothing to do with each other.  There may some clever SWIG way 
of solving this, but it's not immediately obvious.

Linking in perl with quantlib was remarkable easy. 

Now for something really challenging.....

I see there are experimental SWIG interfaces for clisp and R.  Now 
maxima works in clisp......


>
> Later,
>     Luigi
>
> ----------------------------------------
>
> Call on God, but row away from the rocks.
> -- Indian proverb

[Quantlib-dev] Branch and tarballs for 0.3.11 release

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

Hi all,
	I just created a CVS branch for the 0.3.11 release; the tag is =20
'R000311f0-branch'. The branch is only open for bug fixes; new features =20
should be committed on the trunk instead and will enter 0.3.12.

Preliminary tarballs are also available at =20
<http://quantlib.org/prerelease/>.

Please export or download the source and check whether you experience =20
any errors.

Thanks,
	Luigi

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

It is better to know some of the questions than all of the answers.
-- James Thurber

[Quantlib-dev] Re: [Quantlib-users] isTimeDependent ???

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

On 10/01/2005 05:23:13 PM, Joseph Wang wrote:
> I think this depends on user requirements.  There is a trade-off =20
> between keeping track of these things so that the library figures out =20
> these things and letting the user use the library in ways that aren't =20
> mathematically correct but gets you a quick and dirty answer.
>=20
> Where this bothered me was if you use the analytic pricing engines =20
> against instruments with changing interest rates, you will get the =20
> wrong answer.

Not necessarily---for an European option, simply using the zero-yield =20
to maturity gives you the right price, not an approximation (the actual =20
shape of the yield term structure doesn't matter, only its integral.)

The principle I would stick to is that users know better. I'm afraid =20
that trying to have the library do what it thinks the Right Thing might =20
prevent users to do what they know to be the right thing.

Later,
	Luigi


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

Hanlon's Razor:
         Never attribute to malice that which is adequately explained
         by stupidity.

[Quantlib-dev] RE: [Quantlib-users] Ideas for two new classes

[Daniel J. D. <dd...@da...>]

I use the Bridge pattern for PDE concept (a PDE has many =
implementations), and I use Template Method for FDM hierarchy. Betewen =
PDE and FDM I use standardised interfaces.
=20
Do Quantlibbers use UML to communicate design ideas, or how does it work =
in this case?
=20
Daniel

________________________________

From: qua...@li... on behalf of Joseph =
Wang
Sent: Sat 01/10/2005 02:48
To: qua...@li...; =
qua...@li...
Subject: [Quantlib-users] Ideas for two new classes



math/SampledCurve - represents a curve which consists of n+1 arrays, one
for the independent values and n dependent values.  Methods of this
class will allow for interpolation and generating first and second
derivative curves.

PartialDifferentialEquation - represents a PDE

The idea behind these new classes will be to clean up the finite
differencing code a bit.  Instead of deal with raw arrays, the code will
deal with SampledCurve's which will have facilities to allow
interpolation, and the finite difference class will be able to pass the
SampleCurve back up to the instrument where things can be done with it
such as calculating delta curves and option curves.

The idea behind a PDE class is to separate the processes from the finite
differencing code.  For example the BlackScholes process will generate a
PDE object and the fd code will generate the finite difference operators
from the PDE object rather than the BlackScholes process itself.

The idea behind this is to improve code clarity as well as to allow for
PDE arithmetic.  Also, I suspect that there are some very clever things
that one can do with Feymann-Kac once we have this in place.






-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, =
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Quantlib-users mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-dev] QL 0.3.10 packaged without *.mak files

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

On Sep 30, 2005, at 6:07 PM, Seth Stafford wrote:

> Has anyone else noticed that the platform independent source for =
0.3.10
>  was packaged without the *.mak files?=A0

Seth,
	you might be our only Borland user...  0.3.10 didn't compile =
cleanly=20
with the Borland free compiler (by the way, is that the one you're=20
using or the commercial one?) and as I hadn't had any news of anyone=20
using it and the release process was taking too much time already, i=20
dropped the makefiles. I'll resurrect them for 0.3.11.

Luigi

[Quantlib-dev] RE: [Quantlib-users] isTimeDependent ???

[Daniel J. D. <dd...@da...>]

Bridge pattern?
=20

________________________________

From: qua...@li... on behalf of Joseph =
Wang
Sent: Fri 30/09/2005 16:18
To: qua...@li...; =
qua...@li...
Subject: [Quantlib-users] isTimeDependent ???



What do people think about adding an "isTimeDependent()" method to
things like TermStructure?  This would be defaulted to "true" as a
virtual function which subclasses could then set to false.

The reason for this is that then the pricing engines could really make
use of this information to decide whether or not to optimize a
calculation.  For finite difference methods this could be a huge time
saver, and simplify the code considerably.

The way that it would work is that the finite difference engine would
find out whether the calcuation matrix is time dependent or not, the
calculation matrix would find out from the process, the process would
find out from the interest and volatility term structures.

Thoughts?








-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, =
discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Quantlib-users mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-dev] Checked in quantlib-perl

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

On Oct 1, 2005, at 2:56 AM, Joseph Wang wrote:

> I've checked in code into QuantLib-SWIG to integrate perl with 
> quantlib through SWIG as well as a sample test program that calculates 
> European option values.  Seems to work.....

Joe,
	do you think it is ready for release? I've been thinking of creating a 
branch for the 0.3.11 release, but I can wait a bit if you still have 
to work on it.

Luigi

[Quantlib-dev] CDO and copula valuation

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

Just curious if anyone out there is working on any public code involving 
CDO and copula models.

[Quantlib-dev] RE: [Quantlib-users] isTimeDependent ???

[Daniel J. D. <dd...@da...>]

Joseph,
=20
I think this depends on user requirements.  There is a trade-off between
keeping track of these things so that the library figures out these
things and letting the user use the library in ways that aren't
mathematically correct but gets you a quick and dirty answer.

=20

DD yes, I know the problem. In this case a nice solution is =
aesthetically please but for performance reasons a less general solution =
has to be acceptd.



For example, one thing that bothers me is that we have an american
engine and a european engine.=20
=20
DD with FDM? or in general?
One way is to use the penalty method PDE (for euro, penalty is zero).
The only difference is the constraint condition?
=20
It would seem to me that you'd define
american and european in the instrument and then have the pricing
engines figure out how to price them.  Where this would break is if you
have a situation in which you have an american option and for whatever
reason want to use a european pricing engine against it.

DD This situation should not be alllowed of course. An idea is the =
Abstract Factory pattern so that we can create consistent product =
families, e.g. Euro option object ONLY with a a Euro engine. Should be =
transparent to the client.
Also, the Template Method pattern is a possibility (default is Euro and =
define your own s/w hooks)

Where this bothered me was if you use the analytic pricing engines
against instruments with changing interest rates, you will get the wrong
answer.  The idea behind having an isTimeDependent flag is to at least
warn the user that they are going to get the wrong answer.  On the other
hand, if it is common practice to use engines in a way that doesn't give
you the exact answer, then maybe this would cause more problems than it
is worth.

DD do you have a UML class diagram for this configuration? Then one can =
see the design blueprint. This is always the first thing I think about =
before coding.
=20
Remarks: Using flags is tricky, and not OO. I am not saying it is bad. =
What I am saying is that there is a lonely pattern trying to escape.
=20
Hope this is of some use.
=20
Daniel

=20
________________________________

From: Joseph Wang [mailto:jo...@co...]
Sent: Sat 01/10/2005 17:23
To: Daniel J. Duffy
Cc: qua...@li...; =
qua...@li...
Subject: Re: [Quantlib-users] isTimeDependent ???



I think this depends on user requirements.  There is a trade-off between
keeping track of these things so that the library figures out these
things and letting the user use the library in ways that aren't
mathematically correct but gets you a quick and dirty answer.

For example, one thing that bothers me is that we have an american
engine and a european engine.  It would seem to me that you'd define
american and european in the instrument and then have the pricing
engines figure out how to price them.  Where this would break is if you
have a situation in which you have an american option and for whatever
reason want to use a european pricing engine against it.

Where this bothered me was if you use the analytic pricing engines
against instruments with changing interest rates, you will get the wrong
answer.  The idea behind having an isTimeDependent flag is to at least
warn the user that they are going to get the wrong answer.  On the other
hand, if it is common practice to use engines in a way that doesn't give
you the exact answer, then maybe this would cause more problems than it
is worth.


Daniel J. Duffy wrote:

> Bridge pattern?
>=20
>
> =
------------------------------------------------------------------------
> *From:* qua...@li... on behalf of Joseph
> Wang
> *Sent:* Fri 30/09/2005 16:18
> *To:* qua...@li...;
> qua...@li...
> *Subject:* [Quantlib-users] isTimeDependent ???
>
> What do people think about adding an "isTimeDependent()" method to
> things like TermStructure?  This would be defaulted to "true" as a
> virtual function which subclasses could then set to false.
>
> The reason for this is that then the pricing engines could really make
> use of this information to decide whether or not to optimize a
> calculation.  For finite difference methods this could be a huge time
> saver, and simplify the code considerably.
>
> The way that it would work is that the finite difference engine would
> find out whether the calcuation matrix is time dependent or not, the
> calculation matrix would find out from the process, the process would
> find out from the interest and volatility term structures.
>
> Thoughts?
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, =
discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Quantlib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-dev] Re: [Quantlib-users] isTimeDependent ???

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

I think this depends on user requirements.  There is a trade-off between 
keeping track of these things so that the library figures out these 
things and letting the user use the library in ways that aren't 
mathematically correct but gets you a quick and dirty answer.

For example, one thing that bothers me is that we have an american 
engine and a european engine.  It would seem to me that you'd define 
american and european in the instrument and then have the pricing 
engines figure out how to price them.  Where this would break is if you 
have a situation in which you have an american option and for whatever 
reason want to use a european pricing engine against it.

Where this bothered me was if you use the analytic pricing engines 
against instruments with changing interest rates, you will get the wrong 
answer.  The idea behind having an isTimeDependent flag is to at least 
warn the user that they are going to get the wrong answer.  On the other 
hand, if it is common practice to use engines in a way that doesn't give 
you the exact answer, then maybe this would cause more problems than it 
is worth.


Daniel J. Duffy wrote:

> Bridge pattern?
>  
>
> ------------------------------------------------------------------------
> *From:* qua...@li... on behalf of Joseph 
> Wang
> *Sent:* Fri 30/09/2005 16:18
> *To:* qua...@li...; 
> qua...@li...
> *Subject:* [Quantlib-users] isTimeDependent ???
>
> What do people think about adding an "isTimeDependent()" method to
> things like TermStructure?  This would be defaulted to "true" as a
> virtual function which subclasses could then set to false.
>
> The reason for this is that then the pricing engines could really make
> use of this information to decide whether or not to optimize a
> calculation.  For finite difference methods this could be a huge time
> saver, and simplify the code considerably.
>
> The way that it would work is that the finite difference engine would
> find out whether the calcuation matrix is time dependent or not, the
> calculation matrix would find out from the process, the process would
> find out from the interest and volatility term structures.
>
> Thoughts?
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Quantlib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-dev] Ideas for two new classes

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

math/SampledCurve - represents a curve which consists of n+1 arrays, one 
for the independent values and n dependent values.  Methods of this 
class will allow for interpolation and generating first and second 
derivative curves.

PartialDifferentialEquation - represents a PDE

The idea behind these new classes will be to clean up the finite 
differencing code a bit.  Instead of deal with raw arrays, the code will 
deal with SampledCurve's which will have facilities to allow 
interpolation, and the finite difference class will be able to pass the 
SampleCurve back up to the instrument where things can be done with it 
such as calculating delta curves and option curves.

The idea behind a PDE class is to separate the processes from the finite 
differencing code.  For example the BlackScholes process will generate a 
PDE object and the fd code will generate the finite difference operators 
from the PDE object rather than the BlackScholes process itself.

The idea behind this is to improve code clarity as well as to allow for 
PDE arithmetic.  Also, I suspect that there are some very clever things 
that one can do with Feymann-Kac once we have this in place.

[Quantlib-dev] Checked in quantlib-perl

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

I've checked in code into QuantLib-SWIG to integrate perl with quantlib 
through SWIG as well as a sample test program that calculates European 
option values.  Seems to work.....

[Quantlib-dev] QL 0.3.10 packaged without *.mak files

[Seth S. <set...@gm...>]

Has anyone else noticed that the platform independent source for 0.3.10
was packaged without the *.mak files? I worked around it by copying the
makefiles from 0.3.9, but I'm wondering if I'm missing any targets by doing
that?

Thanks,
-Seth Stafford

Re: [Quantlib-dev] isTimeDependent ???

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

On 09/30/2005 04:18:51 PM, Joseph Wang wrote:
> What do people think about adding an "isTimeDependent()" method to =20
> things like TermStructure?  This would be defaulted to "true" as a =20
> virtual function which subclasses could then set to false.
>=20
> The reason for this is that then the pricing engines could really =20
> make use of this information to decide whether or not to optimize a =20
> calculation.  For finite difference methods this could be a huge time =20
> saver, and simplify the code considerably.

I would leave that to the user. Namely, I would rather add an =20
isTimeDependent parameter to the engine constructor, defaulting to =20
false. If enabled, the engine would optimize the calculation. It seems =20
to me to have two advantages: 1) it doesn't try to be too smart, which =20
is often more difficult that it's worth; 2) it makes it possible to =20
optimize the calculation even when the term structures are not =20
constant; a user could take a time-dependent term structure, and still =20
decide that for a simple European option he can just use the zero-yield =20
to maturity.

Luigi


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

Newton's Law of Gravitation:
	What goes up must come down.  But don't expect it to come down
	where you can find it.  Murphy's Law applies to Newton's.

[Quantlib-dev] isTimeDependent ???

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

What do people think about adding an "isTimeDependent()" method to 
things like TermStructure?  This would be defaulted to "true" as a 
virtual function which subclasses could then set to false.

The reason for this is that then the pricing engines could really make 
use of this information to decide whether or not to optimize a 
calculation.  For finite difference methods this could be a huge time 
saver, and simplify the code considerably. 

The way that it would work is that the finite difference engine would 
find out whether the calcuation matrix is time dependent or not, the 
calculation matrix would find out from the process, the process would 
find out from the interest and volatility term structures.

Thoughts?

[Quantlib-dev] Perl SWIG and Chinese convertible bonds

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

I'm in the process of creating a SWIG perl interface.  I was wondering 
if someone is working on anything similar and if anyone has pointers for 
writing the setup script.

Incidentally, I think I've found something interesting with my 
mini-reasearch project with Chinese convertible bonds, which is what got 
me into Quantlib.

The standard Western way of modelling CB's is a bond with a call 
option.  However, I'm increasingly becoming convinced that one of the 
main functions of convertible bonds on Shanghai is to function as a 
stock + a put option.  This explains why the conversion price is set 
close to the stock price.  As for why someone would want to use a 
convertible bond as a put option rather than just issuing a put option, 
it might have something to do with the fact that it is 
difficult/impossible to issue a put option.

This nicely explains why people don't convert the bond immediately when 
the stock price rises above the conversion price.   If you do that you 
lose the value of the put option.  By contrast, I suspect that in 
Western CB's, the option value of the CB is unimportant.  The initial 
price of the stock is so much lower than the strike price, that the 
option value of the CB is unimportant.  If the stock rises to the point 
where conversion is a possibility, the bond is likely to be close to its 
expiration date which means that the option value of the CB is again 
unimportant.  Furthermore, the option value of the bond is probably 
insignficant in comparison with issues involving default.

There are three consequences of this.

1) this shows how the same principles can be applied differently in 
different markets, and the usefulness of having someone with area 
experience to do quant work (hint, hint, I'm looking for a job, hint, 
hint, nudge, nudge)

2) there is likely to be a wonderful arbitrage opportunity for someone 
who can trade CB's and A shares in Shanghai.  The graphs I've seen which 
compare the values of CB's and A shares are very noisy which means 
overshoot, which means a lot of arbitrage possibilities.

3) the paper that got me thinking about this argued that the odd 
behavior was due to inefficient markets.  If this train of thought is 
correct, then it turns out that the Shanghai market is actually acting 
very efficiently and rationally, which calls into question a lot of the 
other negativity concerning stock trading in Shanghai.

Anyway, I'll trying to put together some working code to calculate 
this.  The other project that I'm working on is trying to develop a 
quantitative model of the massive stock reform project that is going on 
in the PRC right now.

I should point out that the next few years should be a massive 
opportunity for Quantlib in the PRC, as they are finally cleaning up the 
securities system.  Over the next year, the National People's Congress 
is scheduled to pass some key legislation which changes the Contract 
Law, the Company Law, and the Bankruptcy Law to make asset backed 
securities possible.  Right now the laws make it difficult to transfer 
default rights from one person to another and this makes securitization 
of debt largely impossible.

Once you have debt securitization, there is likely to be an explosion in 
the issuance of asset backed securities with a consequential explosion 
on risk management derivatives based on asset backed securities.  All 
this suddenly thrust into an economy which does not have the software 
infrastructure to value these things.  Enter Quantlib.....

Re: [Quantlib-dev] Building QuantLib Head on Windows XP

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

On 09/28/2005 12:53:41 PM, John Nichol wrote:
> I am trying to build the current CVS Quantlib Head
>=20
> I am running
>=20
> autoconf
> configure --with-boost-lib=3D/cygdrive/p/boost_1_33_0/libs
> --with-boost-include=3D/cygdrive/p/boost_1_33_0/

autoconf is probably not enough.

You can try
./autogen.sh
./configure --your-options


Luigi

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

All generalizations are dangerous, even this one.
-- Alexandre Dumas