quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Forex framework

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

Hi guys,
I would like to know if there is anything happening on the Forex side in=20
QuantLib. I remember a discussion on quantlib-users about a Currency QuEP=
,=20
anything new about it? The point is that I will need to price some (not t=
oo=20
exotic) forex options in the future, and this would be a key-point to "se=
ll"=20
QuantLib to my boss. If nothing is going on, should I write a QuEP and su=
bmit=20
it to the group? Any recommendation?
Sad

[Quantlib-dev] plan for soap extension

[Xiaowen W. <swa...@ya...>]

Hi everyone:
I've been thinking about the SOAP extension of
Quantlib. The following is my thoughts that I'd like
to discuss with you:

1) The target of QuantLib-SOAP is to provide
portafolio evaluation functionalities accessible via
standardized wire protocol(http,smtp etc). And to more
specific, it's a collection of stateless functions
remotely invocable(RPC instead of messenging style).

As put in some articles, there's so far no consensus
as to what the web service buzz really is. But one
thing seems to be sure is that it's not yet another
distributed object architecture like CORBA or RMI. As
a service provider, the simplest service that
QuantLib-SOAP extension can offer is a collection of
stateless functions, just like the stateless session
beans in the enterprise java bean(EJB) architecture.
And because QuantLib is mostly about portofolio
evaluation, stateless functions is OK for the initial
offering. As the extension becomes more mature,
stateful conversational functions (like stateful
session bean in EJB) can be added.

A note about the RPC .vs. messenging is necessary
here. I think RPC is sufficient for quantlib project
because I don't think there's a usage scenario that
involves more than 2 parties. It's a simple
communication of the request-response within bounded
time style. Asynchronous Messenging is the standard
communication style used in distributed computing
analysis because almost all those problems involve a
bunch of participants. And the most important, the
decision of RPC or Messenging is orthogonal to the
other parts of quantlib-soap extension.

2) QuantLib-SOAP requires a complete C++ binding for
FpML specification. 

Just like in CORBA we need to translate IDL into stub
classes for subclassing, in SOAP extension we need to
translate WSDL into stub classes for subclassing. The
service interface description(WSDL) is simply a
function signature description(if we adopt RPC style),
the messy part is the XML encoding of those complex
data structures in the parameters and return values.
FpML specifies the XML encoding of these data
structures, and thus we need a FpML elements <-> C++
objects binding scheme.

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.

One sidenote is that QuantLib-SOAP extension is be
different from the script language extensions like
Quantlib-Python etc. This is because SOAP uses wire
protocol to connect instructions in the distributed
address spaces, whereas SWIG connects instructions
within a single address space. The former requires
complete serialization/deserialization of complex data
structure whereas the latter can work around this by
resorting to the opaque object reference.

3) The extension needs some helper classes to
interface with the selected wire protocols to
participate in the RPC.

As in CORBA and IDL, the implementation stubs can be
automatically generated from WSDL. In implementing
these stubs, some helper classes are needed to take
care of the plumbing job.

In short, it's my opinion that the plan for
QuantLib-SOAP extension will be three steps:
1) Implement the automatic code generation for FpML
<-> C++ binding.
2) Select the collection of stateless portfolio
evaluation functions.
3) Implement the functions selected in 2). There're
many open source tools out there to help out in this
stage.

Stage 1 is essentially a lexical analysis and parsing
process. I think a lex file from DTD grammer is the
starting point.

Looking forward to your comments.

Cheers
Xiaowen

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

[Quantlib-dev] Formatting a very large double crashes my system

[Vadim O. <vo...@ar...>]

Formatting a very large double crashes my system (gcc3.0.4, RH7.2). Below is
the program.
This is probably a bug in sprintf, but I was not able to confirm. Am I the
only lucky one?

Thanks, Vadim

#include <ql/quantlib.hpp>

using namespace std;
using namespace QuantLib;

int main()
{
  double x = 7.75285e+306;

  cout << DoubleFormatter::toString(x) << endl;

  return 0;
}

-------------------------------------------------- 
DISCLAIMER 
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or
confidential information.  If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution or
copying of this e-mail, and any attachments thereto, is strictly prohibited.
If you have received this e-mail in error, please immediately notify me and
permanently delete the original and any copy of any e-mail and any printout
thereof. 

E-mail transmission cannot be guaranteed to be secure or error-free.  The
sender therefore does not accept liability for any errors or omissions in
the contents of this message which arise as a result of e-mail transmission.

NOTICE REGARDING PRIVACY AND CONFIDENTIALITY 

Knight Trading Group may, at its discretion, monitor and review the content
of all e-mail communications. 

Re: [Quantlib-dev] Re: Bug#146071: quantlib-ruby_0.3.0-1(hppa/unstable): need -ffunction-sections on hppa

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

On Tue, May 07, 2002 at 12:53:53PM +0100, Luigi Ballabio wrote:
> At 10:53 PM 5/6/02 -0500, Dirk Eddelbuettel wrote:
> >Ok, now that I got ql-ruby built, here is the first failure report on
> >non-i386.
> 
> Dirk,
>         does the main QuantLib package run "make check" after building?
> If it did, I suspect we would have failures from it as well...

Yes, but errors are ignored by my choice:

test-stamp: build-stamp
	-$(MAKE) check
    	touch test-stamp
		     
The '-' makes make roll over errors and continue.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] Re: Bug#146071: quantlib-ruby_0.3.0-1(hppa/unstable): need -ffunction-sections on hppa

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

At 10:53 PM 5/6/02 -0500, Dirk Eddelbuettel wrote:
>Ok, now that I got ql-ruby built, here is the first failure report on
>non-i386.

Dirk,
         does the main QuantLib package run "make check" after building?
If it did, I suspect we would have failures from it as well...

Bye,
         Luigi

[Quantlib-dev] Re: Bug#146071: quantlib-ruby_0.3.0-1(hppa/unstable): need -ffunction-sections on hppa

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

Ok, now that I got ql-ruby built, here is the first failure report on
non-i386.

Dirk

----- Forwarded message from lam...@hp... -----

Envelope-to: ed...@ed...
Delivery-date: Mon, 06 May 2002 22:03:15 -0500
Subject: Bug#146071: quantlib-ruby_0.3.0-1(hppa/unstable): need -ffunction-sections on hppa
Reply-To: lam...@hp..., 14...@bu...
From: lam...@hp...
To: su...@bu...

Package: quantlib-ruby
Version: 0.3.0-1
Severity: important

There was an error while trying to autobuild your package:

> Automatic build of quantlib-ruby_0.3.0-1 on sarti by sbuild/hppa 1.169
> Build started at 20020507-0347

[...]

> ** Using build dependencies supplied by package:
> Build-Depends: debhelper (>= 3.0.0), ruby (>= 1.6.7), ruby-dev (>= 1.6.7), libquantlib0-dev (>= 0.3.0), g++ [!ia64], g++-3.0 [ia64], gcc [!ia64], gcc-3.0 [ia64]

[...]

> g++ -shared  -L/usr/lib  -o QuantLibc.so quantlib_wrap.o -L. -lruby -lc -lQuantLib
> /usr/bin/ld: quantlib_wrap.o(.text+0x3ef08): cannot reach 0000002e__ZN8QuantLib17FiniteDifferences23firstDerivativeAtCenterERKNS_5ArrayES3_+0, recompile with -ffunction-sections

[...]

> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> make[1]: *** [QuantLibc.so] Error 1
> make[1]: Leaving directory `/build/buildd/quantlib-ruby-0.3.0'
> ./QuantLibc.so -> debian/quantlib-ruby/usr/lib/ruby/1.6/hppa-linux/QuantLibc.so
> /usr/lib/ruby/1.6/ftools.rb:13:in `size': No such file or directory - "./QuantLibc.so" (Errno::ENOENT)
> 	from /usr/lib/ruby/1.6/ftools.rb:13:in `syscopy'
> 	from /usr/lib/ruby/1.6/ftools.rb:46:in `copy'
> 	from /usr/lib/ruby/1.6/ftools.rb:147:in `install'
> 	from setup.rb:222
> 	from setup.rb:203:in `call'
> 	from setup.rb:96:in `execute'
> 	from setup.rb:237
> Installing QuantLib-Ruby...
> make: *** [install-stamp] Error 1

A full build log can be found at:
http://buildd.debian.org/build.php?arch=hppa&pkg=quantlib-ruby&ver=0.3.0-1



----- End forwarded message -----

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] Re: QuantLib 0.3.0 uploaded

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

On Mon, May 06, 2002 at 10:48:28AM +0100, Luigi Ballabio wrote:
> At 08:31 AM 5/5/02 -0500, Dirk Eddelbuettel wrote:
> >Ruby doesn't build, neither with g++ nor g++-3.0. Copious warnings on 
> >either
> >build attempt.
> 
> Hi Dirk,
>         any details? Do you have a link to the log?

No. Take any Debian "testing" aka Debian 3.0.0 aka woody machine; it should
behave like mine.  I'll attach a tar.gz of the debian/ dir from my box.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

Re: [Quantlib-dev] Re: QuantLib 0.3.0 uploaded

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

At 08:31 AM 5/5/02 -0500, Dirk Eddelbuettel wrote:
>Ruby doesn't build, neither with g++ nor g++-3.0. Copious warnings on either
>build attempt.

Hi Dirk,
         any details? Do you have a link to the log?

Thanks,
         Luigi

[Quantlib-dev] Re: QuantLib 0.3.0 uploaded

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

On Fri, May 03, 2002 at 05:49:16PM +0200, Ferdinando Ametrano wrote:
> the 0.3.0 files have been uploaded to sourceforge. The release is still 
> hidden and it may take a couple of hours to have all the mirrors to sync, 
> but you can preview the release at:
> http://quantlib.org/nextrelease.html
> 
> Dirk would you take care of the Debian packages, please.

Done for QL, QL-Python and the Ref.Manual.

Ruby doesn't build, neither with g++ nor g++-3.0. Copious warnings on either
build attempt. 

I am thinking about having the exiting package withdrawn from the Debian
mirrors as I don't have time to deal with its problem and rather concentrate
on QL, QL-Python and my little RQuantLib.

> I'm going to make the release public next monday

Ok. Thanks for the heads-up. That worked well with the weekend in-between.

Dirk

-- 
Good judgement comes from experience; experience comes from bad judgement. 
							    -- Fred Brooks

[Quantlib-dev] QuantLib 0.3.0 uploaded

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

Hi all

the 0.3.0 files have been uploaded to sourceforge. The release is still 
hidden and it may take a couple of hours to have all the mirrors to sync, 
but you can preview the release at:
http://quantlib.org/nextrelease.html

Dirk would you take care of the Debian packages, please.

I'm going to make the release public next monday

ciao -- Nando

Re: [Quantlib-dev] CompoundForward

[Marco M. <Mar...@ri...>]

Hi,
I totally agree with Luigi.

         Marco

At 08:03 PM 4/30/02 +0100, Luigi Ballabio wrote:

>Hi,
>         I'm fine with the layered structure, but this is a case in which 
> I do think that there's way too many constructors. Make them factory 
> functions instead, distincts from the term structure classes---this way 
> you can also reuse them for different term structures. Or full-featured 
> factories.
>Observability of market elements should enter the equation, too, although 
>I'm not going to give it much thought at 8 pm :)
>
>Bye,
>         Luigi
>
>At 06:41 PM 4/30/02 +0200, Ferdinando Ametrano wrote:
>>At 01:25 PM 4/25/2002 +0200, Andre Louw wrote:
>>>I have a bit of a problem with the name compoundforward, essentially it
>>>bootstraps a strip of forwards of some compounding freq to a strip of
>>>discountfactors. These df's it then uses to get back to zeros and
>>>instantaneous forwards, so it seems it is more in the line of a
>>>DiscountStructure?
>>>In fact I have gone as far as inheriting from DiscountStructure and passing
>>>the implementation of zeroYield and forward to it. Haven't checked in yet,
>>>would like to hear yr comments first?
>>I think it could/should be just another constructor of the DiscountCurve 
>>class.
>>
>>The TermStructure framework as I see it:
>>
>>1st layer) QuantLib::TermStructure is the general interface
>>
>>2nd layer) QuantLib::ZeroYieldStructure, QuantLib::DiscountStructure, 
>>QuantLib::ForwardRateStructure are generic parameterizations of the 
>>TermStructure in term of zero, discount, instantaneous forward 
>>respectively. If someone needs a parameterization in term of discrete 
>>forwards this could be the appropriate layer.
>>
>>3rd layer) Here you are inside the QuantLib::TermStructures namespace. 
>>This is the layer where you provide a functional form to your 
>>TermStructure, e.g. piece-wise constant instantaneous forwards for 
>>QuantLib::TermStructures::PiecewiseFlatForward, loglinear interpolated 
>>discounts for QuantLib::TermStructures::DiscountCurve, etc.
>>Please note that in these two examples the functional forms are 
>>completely equivalent, but one could think of cubic spline interpolated 
>>zeros, etc.
>>For sake of clarity I would even derive PiecewiseFlatForward from 
>>QuantLib::ForwardRateStructure (now it derives from 
>>QuantLib::TermStructure), just to stress that it is a third conceptual layer.
>>Every class in the third layer could (should?) easily provide 3 
>>constructors based on a grid of discounts, zeros, forwards respectively, 
>>whatever their parameterization and functional form are
>>
>>In this framework CompoundForward could become just a specialized 
>>constructor using discrete forwards of QuantLib::TermStructures::DiscountCurve
>>
>>What do you think about this framework?
>>
>>ciao -- Nando
>>
>>
>>_______________________________________________
>>Quantlib-dev mailing list
>>Qua...@li...
>>https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] hello

[Marco M. <Mar...@ri...>]

Welcome Aboard Xiaowen,

At 09:24 AM 4/30/02 -0700, Xiaowen Wang wrote:
>I'm currently a Ph.D. student with the area in
>CFD(computational fluid dynamics). So I'm very
>comfortable with the PDE and finite difference stuff.
>I'm OK with Monte Carlo. The financial interfaces to
>these
>math are strange to me, and I'm reading Shreve's book
>to catch up.

Those people from CFD are the best;-). I have the same background and,
belive me, it's a piece of cake to make the leap into the quants world.
You forgot to mention an important detail:
   which University are you from?

ciao,
       Marco

Re: [Quantlib-dev] hello

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

At 9:24 AM -0700 4/30/02, Xiaowen Wang wrote:
>My primary interest in this project is for the SOAP
>extension and it's one of the listed items I
>volunteered to Ferdinando. I'll send another email
>when time's right to discuss my thought on SOAP
>extension with you guys.

Hi all,
	I remember we had a discussion in which we kind of decided to 
dump CORBA as the protocol of choice and favor SOAP instead. I'm 
perfectly fine with it.

What I don't remember is: did we go into the differences between SOAP 
and plain XML-RPC? And do we need to? I ask out of ignorance, being 
kind of ineducated in both and not knowing whether any of them is 
more widely adopted.

Keep-the-ball-rolling-ly yours,
				Luigi


-- 

Re: [Quantlib-dev] hello

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

At 11:50 AM +0200 5/1/02, Ferdinando Ametrano wrote:
>Please consider that I'm willing to set up a QuantLibSOAP module in our CVS.

I would call it QuantLib-SOAP (with the dash) for simmetry with the 
other extension modules.

Anal-retentively yours,
			Luigi

-- 

Re: [Quantlib-dev] hello

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

Hi Xiaowen

>I'll send another email
>when time's right to discuss my thought on SOAP
>extension with you guys.
Please consider that I'm willing to set up a QuantLibSOAP module in our CVS.

>The financial interfaces to these math are strange to me, and I'm reading 
>Shreve's book
>to catch up.
I would supplement Shreve's book with Hull and/or Wilmott.
Take a look at 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quantlib/QuantLib-site/books.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup

You might be also interested in FpML (http://www.fpml.org/), especially the 
FpML 2.0 Trial Recommendation and the FpML 3.0 Working Draft

ciao -- Nando

RE: [Quantlib-dev] Swap Ratehelper

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

At 07:08 PM 4/30/2002 +0100, Luigi Ballabio wrote:
>I'd like to think that at release 0.3.0 we are still free to change our 
>minds if we see a drawback in our earlier choices
Sure! On of the reason this dev list exists is to have here the guys who 
actually develop and use QuantLib. QuantLib must fit our needs, so as long 
as it's OK for us I wouldn't mind about generic potential complaints

>I would add a new constructor with the parameters in the right order and 
>maybe deprecate the old one in order to remove it in the next release. [...]
>Also, I would put the common initialization code in a private initialize() 
>method that both constructors would call, much like you did with the 
>CompoundForward constructors.
OK

>Anyway, mine is just one vote, and we are quite a few now.
but you know very well that not all votes are equally weighted, and your 
vote deserves quite a high weight ;-)

ciao -- Nando

Re: [Quantlib-dev] Swap Ratehelper

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

At 02:16 PM 4/30/02 +0200, Andre Louw wrote:
>I notice that SwapRateHelper gets constructed explicitly on Year bounds. I
>realize it's done this way because of  the market convention, but I would
>like the functionality of using non-market specified quotes to bootstrap
>off.
>
>Is there someone with a strong feeling against making it a bit more
>flexible, ie keep the current constructor but add a 'units_' member (which
>defaults to Years for the current constructor), which can be specified in a
>seperate constructor?

I don't have a strong feeling against adding units to the present 
constructor, either. It's not that big an inconvenience (and as for my 
personal taste, I prefer not to have multiple constructors with a lot of 
parameters---one never knows at a glance what one is instantiating)

Bye,
         Luigi

Re: [Quantlib-dev] CompoundForward

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

Hi,
         I'm fine with the layered structure, but this is a case in which I 
do think that there's way too many constructors. Make them factory 
functions instead, distincts from the term structure classes---this way you 
can also reuse them for different term structures. Or full-featured factories.
Observability of market elements should enter the equation, too, although 
I'm not going to give it much thought at 8 pm :)

Bye,
         Luigi

At 06:41 PM 4/30/02 +0200, Ferdinando Ametrano wrote:
>At 01:25 PM 4/25/2002 +0200, Andre Louw wrote:
>>I have a bit of a problem with the name compoundforward, essentially it
>>bootstraps a strip of forwards of some compounding freq to a strip of
>>discountfactors. These df's it then uses to get back to zeros and
>>instantaneous forwards, so it seems it is more in the line of a
>>DiscountStructure?
>>In fact I have gone as far as inheriting from DiscountStructure and passing
>>the implementation of zeroYield and forward to it. Haven't checked in yet,
>>would like to hear yr comments first?
>I think it could/should be just another constructor of the DiscountCurve 
>class.
>
>The TermStructure framework as I see it:
>
>1st layer) QuantLib::TermStructure is the general interface
>
>2nd layer) QuantLib::ZeroYieldStructure, QuantLib::DiscountStructure, 
>QuantLib::ForwardRateStructure are generic parameterizations of the 
>TermStructure in term of zero, discount, instantaneous forward 
>respectively. If someone needs a parameterization in term of discrete 
>forwards this could be the appropriate layer.
>
>3rd layer) Here you are inside the QuantLib::TermStructures namespace. 
>This is the layer where you provide a functional form to your 
>TermStructure, e.g. piece-wise constant instantaneous forwards for 
>QuantLib::TermStructures::PiecewiseFlatForward, loglinear interpolated 
>discounts for QuantLib::TermStructures::DiscountCurve, etc.
>Please note that in these two examples the functional forms are completely 
>equivalent, but one could think of cubic spline interpolated zeros, etc.
>For sake of clarity I would even derive PiecewiseFlatForward from 
>QuantLib::ForwardRateStructure (now it derives from 
>QuantLib::TermStructure), just to stress that it is a third conceptual layer.
>Every class in the third layer could (should?) easily provide 3 
>constructors based on a grid of discounts, zeros, forwards respectively, 
>whatever their parameterization and functional form are
>
>In this framework CompoundForward could become just a specialized 
>constructor using discrete forwards of QuantLib::TermStructures::DiscountCurve
>
>What do you think about this framework?
>
>ciao -- Nando
>
>
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

RE: [Quantlib-dev] Swap Ratehelper

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

At 03:54 PM 4/30/02 +0200, Andre Louw wrote:
>Luigi,
> > I don't have a strong feeling against adding units to the present
> > constructor, either. It's not that big an inconvenience
>
>Except for everybody using it currently?

This is true. However, it is also true that a) I'd like to think that at 
release 0.3.0 we are still free to change our minds if we see a drawback in 
our earlier choices, and b) last week we changed the TermStructure 
interface and the PiecewiseFlatForward constructor; users already have to 
change their scripts, and this change might be just another epsilon. Then 
again, I'm not suggesting this as the standard process.

>I suppose you can add the units to the end of the parm-list with an
>initialised value of 'Years', but that's not very neat, I would prefer to
>have it next to the number-of-units?
>What's the QuantLib dev community's general rule-of-thumb, I'm used to
>adding a new constructor (minimising the influence on existing codes)?

As for me, no rule-of-thumb valid for all cases. There are times when 
multiple constructors give me the feeling that a class is trying to do too 
much and should be refactored. However, this is not the case since it is 
just a matter of default arguments; I would add a new constructor with the 
parameters in the right order and maybe deprecate the old one in order to 
remove it in the next release. The latter would depend on this release 
being 0.3.0: were it closer to 1.0, I'd leave the old constructor alone.
Also, I would put the common initialization code in a private initialize() 
method that both constructors would call, much like you did with the 
CompoundForward constructors.

Anyway, mine is just one vote, and we are quite a few now.

Bye,
         Luigi

[Quantlib-dev] 0.3.0

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

Hi all

I've committed the updated ChangeLog.txt into the R000300f0-branch of 
QuantLib, QuantLib-Python and QuantLib-Ruby.
Next Thursday we will generate the files to be distributed. Before Thursday 
you might consider taking a look at the NEWS.TXT file and fix it when/if 
needed.

ciao -- Nando

Re: [Quantlib-dev] CompoundForward

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

At 01:25 PM 4/25/2002 +0200, Andre Louw wrote:
>I have a bit of a problem with the name compoundforward, essentially it
>bootstraps a strip of forwards of some compounding freq to a strip of
>discountfactors. These df's it then uses to get back to zeros and
>instantaneous forwards, so it seems it is more in the line of a
>DiscountStructure?
>In fact I have gone as far as inheriting from DiscountStructure and passing
>the implementation of zeroYield and forward to it. Haven't checked in yet,
>would like to hear yr comments first?
I think it could/should be just another constructor of the DiscountCurve class.

The TermStructure framework as I see it:

1st layer) QuantLib::TermStructure is the general interface

2nd layer) QuantLib::ZeroYieldStructure, QuantLib::DiscountStructure, 
QuantLib::ForwardRateStructure are generic parameterizations of the 
TermStructure in term of zero, discount, instantaneous forward 
respectively. If someone needs a parameterization in term of discrete 
forwards this could be the appropriate layer.

3rd layer) Here you are inside the QuantLib::TermStructures namespace. This 
is the layer where you provide a functional form to your TermStructure, 
e.g. piece-wise constant instantaneous forwards for 
QuantLib::TermStructures::PiecewiseFlatForward, loglinear interpolated 
discounts for QuantLib::TermStructures::DiscountCurve, etc.
Please note that in these two examples the functional forms are completely 
equivalent, but one could think of cubic spline interpolated zeros, etc.
For sake of clarity I would even derive PiecewiseFlatForward from 
QuantLib::ForwardRateStructure (now it derives from 
QuantLib::TermStructure), just to stress that it is a third conceptual layer.
Every class in the third layer could (should?) easily provide 3 
constructors based on a grid of discounts, zeros, forwards respectively, 
whatever their parameterization and functional form are

In this framework CompoundForward could become just a specialized 
constructor using discrete forwards of QuantLib::TermStructures::DiscountCurve

What do you think about this framework?

ciao -- Nando

[Quantlib-dev] hello

[Xiaowen W. <swa...@ya...>]

Hi everyone:
My name is Xiaowen Wang. I'm a new developer of
QuantLib. I'm glad to get involved in this project and
I'd like to take you a moment to introduce myself.

My primary interest in this project is for the SOAP
extension and it's one of the listed items I
volunteered to Ferdinando. I'll send another email
when time's right to discuss my thought on SOAP
extension with you guys. 

I'm currently a Ph.D. student with the area in
CFD(computational fluid dynamics). So I'm very
comfortable with the PDE and finite difference stuff.
I'm OK with Monte Carlo. The financial interfaces to
these 
math are strange to me, and I'm reading Shreve's book
to catch up. 

I'm very comfortable with C++, both OO style and
Generic programming style.

I think I'll first try to get familiar with the
financial interfaces, which are actually the only
things that need to be exported via web services as I
think, then I'll move on to the concrete development
work.

In the mean time, I'm very willing to help out on
other items if you need.

Thanks
Xiaowen

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Re: [Quantlib-dev] Indentation

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

At 06:58 PM 4/29/2002 +0200, Andre Louw wrote:
>I'm running into trouble when checking in or out from
>QuantLib's CVS.
>Any file that I worked on that somebody else worked on as well I get
>conflicts, 99% of the time because of
>indentation.
It's been probably my fault. Next time I will be more careful.

>I haven't really checked but I'm pretty sure there must be some automated
>way of getting this to work.
>IOW get a common .indent.pro on the CVS server, which all files are
>converted to when checked in,
>and a personal .indent.pro which is used when checking out.
To use 2 different .indent.pro on the CVS side and the developer side 
wouldn't mark all files as modified?

This said if we settle on one .indent.pro and automate the CVS I would go 
for it

ciao -- Nando

Re: [Quantlib-dev] Swap Ratehelper

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

At 02:16 PM 4/30/2002 +0200, you wrote:
>I notice that SwapRateHelper gets constructed explicitly on Year bounds. I
>realize it's done this way because of  the market convention, but I would
>like the functionality of using non-market specified quotes to bootstrap
>off.
>
>Is there someone with a strong feeling against making it a bit more
>flexible, ie keep the current constructor but add a 'units_' member (which
>defaults to Years for the current constructor), which can be specified in a
>seperate constructor?
for me it's OK, as long as it wraps Instruments::SimpleSwap and it is an 
additional constructor

ciao -- Nando

[Quantlib-dev] Swap Ratehelper

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

Hi,

I notice that SwapRateHelper gets constructed explicitly on Year bounds. I
realize it's done this way because of  the market convention, but I would
like the functionality of using non-market specified quotes to bootstrap
off.

Is there someone with a strong feeling against making it a bit more
flexible, ie keep the current constructor but add a 'units_' member (which
defaults to Years for the current constructor), which can be specified in a
seperate constructor?

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.