quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] New process classes and the use within StochasticProcessArray...

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

Hi Luigi,

One further question regarding the new process framework...

Let's say one wanted to price a spread option via monte-carlo between 2 
differnet indexes so that the payoff is

max( (fixing_Index1 - fixing_Index2) - X, 0.0).

It looks like to me that the two interest rate processes (fixing_Index1 and 
fixing_Index2) along with the correlation between the two can be modelled 
via the StochasticProcessArray class and thus the spread option priced 
correctly via monte-carlo.

I guess you can even simulate the FX between the two (if the indexes 
represents rates in different currencies) and have three correlated 
processes.

Would you agree that under the new process framework, the set-up I have 
presented above is correct and would be priced correctly?

I'm not too sure whether the interest rate processes along with a 
correlation matrix is compatible with the StochasticProcessArray class. The 
interfaces suggest yes, but will the computed rates from the simulation 
account correctly for the correlation?

Toy out.

Re: [Quantlib-dev] QuantLib developement

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

Hi Luigi,

Is it possible to derive the G2Process and G2ForwardProcess classes from the 
XXX1D base class as you have done with the HullWhite versions?

Toy out.

>From: "Luigi Ballabio" <lui...@gm...>
>To: "TB...@ao..." <TB...@ao...>
>CC: qua...@li...,"Toyin Akin" 
><toy...@ho...>
>Subject: Re: [Quantlib-dev] QuantLib developement
>Date: Fri, 28 Apr 2006 13:11:02 +0200
>
>On 4/11/06, Luigi Ballabio <lui...@gm...> wrote:
>>I'll be committing shortly a contribution I received. It provides
>>processes based on Hull-White that can be used in a Monte Carlo model.
>>I'll let you know when they're available.
>
>Done. There are a few new processes in ql/Processes and a new engine
>in ql/PricingEngines/CapFloor that shows how to use them.
>
>Luigi
>
>
>-------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job 
>easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Always can use help

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

On 04/25/2006 06:54:49 AM, Joseph Wang wrote:
> I did a quick brain dump of some things that newbies can work on in:
>=20
> http://wiki.quantlib.org/twiki/bin/view/Quantlib/NewbieProjects
>=20
> That page is editable so that people can add on their own ideas.

Joe,
	apparently I can't login on the Wiki, neither with the guest =20
account nor with my registered one. Here are a couple of things you =20
might change:

- interested developers should post to the quantlib-dev list, not =20
quantlib-users.
- work on a QuantLib book has already started.

Later,
	Luigi


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

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

Re: [Quantlib-dev] QuantLib developement

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

On 4/11/06, Luigi Ballabio <lui...@gm...> wrote:
> I'll be committing shortly a contribution I received. It provides
> processes based on Hull-White that can be used in a Monte Carlo model.
> I'll let you know when they're available.

Done. There are a few new processes in ql/Processes and a new engine
in ql/PricingEngines/CapFloor that shows how to use them.

Luigi

Re: [Quantlib-dev] Applying to join the QuantLib project

[Allen K. <all...@ya...>]

Let me tidy up the code a bit. Then I'll just tar up the directory, write up the outstanding issues, and throw it out there for anyone who wants to work on it. I'll be more than happy to work on it also if someone can give me some [sic] pointers.
   
  Best,
  Allen
   
  

"Li, Qiuxiang" <qiu...@im...> wrote:
            Lugi,
   
  Thank you very much.
   
  I just downloaded the Quantlib source code and at this moment I am just reading the code.  
  I hope I can get familiar with the pack as soon as possible.
   
  Will see how confident I will be by then to write some pieces.  So I'll have to give up this opportunity 
  at this moment.
   
  I've sent Allen a separate email.
   
   
  Many thanks,
   
  Stephen/Qiuxiang
   
   

  ----- Original Message -----   From: "Luigi Ballabio" <lui...@gm...>
  To: "Allen Kuo" <all...@ya...>
  Cc: <qua...@li...>; <qiu...@im...>
  Sent: Thursday, April 27, 2006 8:34 AM
  Subject: Re: [Quantlib-dev] Applying to join the QuantLib project

  


On 04/27/2006 06:43:12 AM, Allen Kuo wrote:
> Qiuxiang:
>   I have a framework for forwards in place and wrote a derived class
> for the bond forward/repo. Just haven't written a formal unit test
> (did some qualitative comparisons with some numbers posted on various
> websites like fincad and things look ok, but I don't know how to get
> beyond that- can't find any good, authoratative repo numbers). If
> you're interested in working on the unit test for this, as well as
> making sure the framework is generic enough, let me know. (The
> framework should handle stock, commodity, and bond forwards, but I
> haven't thought deeply about FRA's and IR futures...).

If Stephen/Qiuxiang is not interested, I am. But I'll let him have the  
first go if he is.

Later,
Luigi


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

When all else fails, pour a pint of Guinness in the gas tank,
advance the spark 20 degrees, cry "God Save the Queen!", and pull
the starter knob.
-- MG "Series MGA" Workshop Manual 

		
---------------------------------
Get amazing travel prices for air and hotel in one click on Yahoo! FareChase 

Re: [Quantlib-dev] Applying to join the QuantLib project

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

On 04/27/2006 06:43:12 AM, Allen Kuo wrote:
> Qiuxiang:
>   I have a framework for forwards in place and wrote a derived class
> for the bond forward/repo. Just haven't written a formal unit test
> (did some qualitative comparisons with some numbers posted on various
> websites like fincad and things look ok, but I don't know how to get
> beyond that- can't find any good, authoratative repo numbers). If
> you're interested in working on the unit test for this, as well as
> making sure the framework is generic enough, let me know. (The
> framework should handle stock, commodity, and bond forwards, but I
> haven't thought deeply about FRA's and IR futures...).

If Stephen/Qiuxiang is not interested, I am. But I'll let him have the =20
first go if he is.

Later,
	Luigi


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

When all else fails, pour a pint of Guinness in the gas tank,
advance the spark 20 degrees, cry "God Save the Queen!", and pull
the starter knob.
-- MG "Series MGA" Workshop Manual

Re: [Quantlib-dev] Applying to join the QuantLib project

[Allen K. <all...@ya...>]

Qiuxiang:
   
  According to:
   
  http://quantlib.org/reference/overview.html
   
  forwards are on the todo list.
   
  I have a framework for forwards in place and wrote a derived class for the bond forward/repo. Just haven't written a formal unit test (did some qualitative comparisons with some numbers posted on various websites like fincad and things look ok, but I don't know how to get beyond that- can't find any good, authoratative repo numbers). If you're interested in working on the unit test for this, as well as making sure the framework is generic enough, let me know. (The framework should handle stock, commodity, and bond forwards, but I haven't thought deeply about FRA's and IR futures...).
   
  Allen
   
   
   
   
  Message: 7
Date: Wed, 26 Apr 2006 18:22:43 +0200
From: Luigi Ballabio <lui...@gm...>
Subject: Re: [Quantlib-dev] Applying to join the QuantLib project
To: "Li, Qiuxiang" <qiu...@im...>
Cc: qua...@li...


On 04/23/2006 11:32:49 PM, Li, Qiuxiang wrote:
> As I am very interested in the QuantLib project, I am wondering
> whether I can particiapte the group to write some code.  As I have 
=20
> limited finance knowledge (reading Options, Futures, and Other =20
> Derivatives by John Hull though), I'll have to start from some
> easy assignments.

Stephen,
 thanks for the offer. The introductory developer page at < =20
http://quantlib.org/newdeveloper.shtml> contains links to a couple of 
=20
to-do lists. Have you had a look at those?

Later,
 Luigi


		
---------------------------------
Blab-away for as little as 1¢/min. Make  PC-to-Phone Calls using Yahoo! Messenger with Voice.

Re: [Quantlib-dev] Applying to join the QuantLib project

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

On 04/23/2006 11:32:49 PM, Li, Qiuxiang wrote:
> As I am very interested in the QuantLib project, I am wondering
> whether I can particiapte the group to write some code.  As I have =20
> limited finance knowledge (reading Options, Futures, and Other =20
> Derivatives by John Hull though), I'll have to start from some
> easy assignments.

Stephen,
	thanks for the offer. The introductory developer page at < =20
http://quantlib.org/newdeveloper.shtml> contains links to a couple of =20
to-do lists. Have you had a look at those?

Later,
	Luigi


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

Dealing with failure is easy: work hard to improve. Success is also
easy to handle: you've solved the wrong problem. Work hard to improve.
-- Alan Perlis

Re: [Quantlib-dev] Contributing to the project

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

On 04/22/2006 10:43:08 PM, Pedro de Noronha Nassif wrote:
> I quickly went through your to-do list and as a starting point, doing
> the greeks in the your montecarlo framework tempts me.

Pedro,
	looks great---thanks for the offer. Why don't you write a few =20
lines so that we can start discussing the implementation?

Later,
	Luigi


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

Do the right thing. It will gratify some people and astonish the rest.
-- Mark Twain

[Quantlib-dev] Fwd: ObjectHandler Boost Link

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

Hello,

This message relates to the CVS development environment and was
intended for quantlib-dev not quantlib-users.  Apologies for the
confusion.

Regards,
Eric

---------- Forwarded message ----------
From: eric ehlers <eri...@gm...>
Date: Apr 26, 2006 10:55 AM
Subject: ObjectHandler Boost Link
To: Quantlib-users <qua...@li...>


Hi All,

ObjectHandler now links to boost i.e. rather than relying solely on
the boost header files you need to compile boost.  So far I've tested
this only for Windows/boost 1.33.1.

At present you need only the regex lib so to save time you can build
boost with just that e.g.

bjam "-sTOOLS=3Dxxx" "--with-regex" stage

where XXX =3D vc-7_1 or vc-8_0

Regards,
Eric

[Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL

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

Hi All,

For the handle retrieval I committed a revised change which I hope
will suit everybody.  Existing behavior is the same, except:
- garbage collection is always on
- in addition to being able to retrieve an object via
"my_object_~xxxxx" you can now retrieve it via "my_object"
- as always, retrieving an object via a string rather than a reference
breaks dependency tracking, as per Toyin's request this caveat will
now be documented in *BOLD*

Any problems please let me know.

Regards,
Eric

Re: [Quantlib-dev] Implementing high-low volatility model

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

Hi Joseph

while I don't have any special contribution on your design I just
wonder why you are considering the effort of adding this framework to
QuantLib. Isn't R a better alternative for this kind of work?

QuantLib focus has always been on derivatives, and while econometric
estimations are often used as input in derivatives models, the two
domains are almost well defined...

ciao -- Nando

On 4/25/06, Joseph Wang <jo...@gn...> wrote:
> I'm in the process of trying to implement a class that does a Garman-Klas=
s
> estimation of volatility based on high-low data.
>
> Right now what I have in mind is a class called IntervalQuote(?) that con=
tains
> open, close, high, low information, and this will be used with the TimeSe=
ries
> template to produce
>
> TimeSeries<IntervalQuote>
>
> which will be the input into the calculation classes.  There will be a he=
lper
> class that creates TimeSeries<IntervalQuote> from a vector of dates, open=
,
> close, high, and low data.
>
> It seems that one should break up the VolatilityModel into two parts.  On=
e
> part is LocalEstimator (?), the second part combinings the daily estimati=
on
> into a time series using constant combining or GARCH, which would be
> subclasses of EstimationCombiner (?)
>
> Since the LocalEstimator will need different types of inputs, there may b=
e a
> need to create a trait.
>
> Thoughts?  I'm especially interested in feedback as to getting the naming
> conventions right.
>
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] Implementing high-low volatility model

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

I'm in the process of trying to implement a class that does a Garman-Klass 
estimation of volatility based on high-low data.

Right now what I have in mind is a class called IntervalQuote(?) that contains 
open, close, high, low information, and this will be used with the TimeSeries 
template to produce

TimeSeries<IntervalQuote>

which will be the input into the calculation classes.  There will be a helper 
class that creates TimeSeries<IntervalQuote> from a vector of dates, open, 
close, high, and low data.

It seems that one should break up the VolatilityModel into two parts.  One 
part is LocalEstimator (?), the second part combinings the daily estimation 
into a time series using constant combining or GARCH, which would be 
subclasses of EstimationCombiner (?)

Since the LocalEstimator will need different types of inputs, there may be a 
need to create a trait.

Thoughts?  I'm especially interested in feedback as to getting the naming 
conventions right.

[Quantlib-dev] Always can use help

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

I did a quick brain dump of some things that newbies can work on in:

http://wiki.quantlib.org/twiki/bin/view/Quantlib/NewbieProjects

That page is editable so that people can add on their own ideas.

In particular, adding a new pricing engine and/or writing a unit tests is a 
way that someone without much experience in the code can start and get 
something quickly useful done without too much time commitment.  Once you are 
in the code, you'll probably find more things that you'd like to work on.

Some of the things I put on the list aren't coding related.  

Generally, the development mode is to find something that you are interested 
in or that you need done for internal use, and then let people know that you 
are working on it so that people aren't reinventing the wheel.

Let me know if you need any help in getting started.

Re: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL

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

Hi,

Your scenario of yieldCurve updating... Not bad.

I didn't realise that you had an Excel environment where the construction of 
the yieldcurve takes place at such a granular level, thus allowing the 
updating of the curve without the reconstruction of it. Most implementations 
I have seen just recreates the curve and has one function that takes all 
market inputs (ie - FinancialCad, MBRM etc...)

Okay I agree that you need the user key for this scenario. But I'd certainly 
place the issues that you have mentioned regarding the risks of using just 
the user key within your documentation
(in BOLD!!!). This would be for advanced users of Excel who know all about 
Excel's calculation dependencies.

>Since Excel 2003, changes in A1 would still force a recalc of A2.
>When the inputs to A1 change, Excel is smart enough to realize that
>the dependents of A1 need to be recalculated, even though the physical
>contents of A1 are unchanged.
>
>That's with cell references.  The problem arises when you retrieve an
>object via a raw string "my_object".  In this case you have no
>guarantee that you're getting the latest version of "my_object".

I would put this in the doc also.

Toy out.


>From: "eric ehlers" <eri...@gm...>
>To: "Toyin Akin" <toy...@ho...>
>CC: qua...@li...
>Subject: Re: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL
>Date: Mon, 24 Apr 2006 13:08:37 +0200
>
>Hi Toy,
>
>From your message it's not clear to me whether you're responding to my
>original proposal (20 April) or the revised one (24 April).
>
>Let me reiterate that under the revised proposal, the existing
>behavior of OH would be retained.  The user would additionally have
>the option of retrieving objects via handle stubs.
>
>On 4/24/06, Toyin Akin <toy...@ho...> wrote:
> > I don't like the idea of the user being able to use the stub key if a 
>unique
> > key is generated for him/her and this new key provides no chances of
> > mispricing on the sheet (assuming that all input parameters are correct 
>and
> > the user knows the instrument they are pricing).
>
>Under the revised proposal, OH supports retrieval of objects both by
>the handle stub ("my_object") and the full handle
>("my_object~_xxxxx").  Normally objects would be retrieved by their
>full handle but if required the user has the option of retrieving an
>object by its stub - in which case the user must respect the caveat
>that Excel no longer forces the object to be refreshed before it is
>referenced.
>
>If you feel that allowing this alternative behavior is dangerous then
>we could consider making the behavior configurable - you could build
>OH such that retrieval of objects via the handle stub is not supported
>(i.e. preserve the current behavior).
>
> > As your library grows and many more objects are added, using the stub 
>only
> > approach makes it difficult to track unique objects.
>
>Under the proposed approach OH throws an exception if a user attempts
>to retrieve an object via its handle stub and two objects exists with
>the same stub.
>
> > Why not stick with the "my_object~_xxxxx" key?
>
>For normal use yes.
>
>We have a special case where we'd like to support retrieval of objects
>via the stub.  Consider three sheets which
>1) instantiate some rate helper objects (qlDepositRateHelper)
>2) update the rates in real time (qlSetQuote)
>3) bootstrap the yield curve (qlPiecewiseFlatForward)
>
>Now imagine that we have multiple versions of #2 depending on where we
>want to source the rates feed.  When we bootstrap the yield curve, we
>don't want to bother about which sheet is updating the rates.  Here's
>what we do:
>
>- Load sheet #1, refresh it, and close it.
>- The OH repository is now initialized with a collection of rate
>helper objects ("ON", "1W", "1M", etc.)
>- The sheet which created these objects (#1) is closed, so the objects
>will not be reconstructed again
>- Load sheets #2 and #3.  The curve is bootstrapped, the rates are
>updated in real time, and the state of the curve changes accordingly
>(thanks to QL's behind-the-scenes use of the Observer/Observable
>pattern)
>- Note that no further deconstruction/reconstruction of objects is
>taking place - we are merely changing the state of the rate helper and
>yield curve objects, which were constructed once
>
>If we have to use full handles, then sheet #3 needs to know which
>version of sheet #2 is in use.  This could change from one session to
>the next.  Maintaining this link is not impossible but we find it more
>convenient to allow objects to be referenced via handle stubs.  Sheets
>#2 and #3 simply trust that rate helper objects ("ON", "1W", "1M",
>etc.) exist without needing to know their full handles.  Therefore
>sheet #3 doesn't need to link to sheet #2 and we can switch to a
>different version of sheet #2 without editing sheet #3.
>
> > Also using the stub key only where the object may have already have been
> > created (a yieldcurve and a book object with the same name) would cause
> > errors on the spreadsheet that will be very difficult to track down.
> >
> > The result will simply display #value, but for the user, how do you 
>debug
> > this?
> >
> > Visiting dependant cells may not help, because the previous object with 
>the
> > same name may have been created within another pricing calculation
> > (worksheet/workbook same Excel session).
>
>Suppose the user tries to create two objects, and supplies the same
>stub, "my_object", to both constructors.  This will succeed, exactly
>as it does today - the first object will be created e.g. as
>"my_object~_00001" and the second as "my_object~_00002".If the user
>requests "my_object~_00001" or "my_object~_00002" he gets the correct
>object back.  If he requests "my_object", OH sees that two objects
>exist with that handle stub and throws an exception.
>
> > What are the main issues in not using the computed key?
>
>As discussed - normally we use the computed key.  But when we want to
>reference an object and don't want to keep track of where in the Excel
>session it resides - we reference it via the handle stub.
>
> > Also, the "stub" key is static and Excel will not detect a change within
> > it's calculation dependency list. One will have to resort to a global 
>(F9)
> > spreadsheet computation in order to ensure any new changes to the key is
> > picked up (that's assuming the previously created object is not part of 
>this
> > updating too!!)
>
>I was under the same impression, until Plamen clarified things for me.
>
>Consider two cells, A1 which constructs an object, and A2 which
>references the object in A1.
>
>Under the design proposed on 20 April, A1 would hold value "my_object".
>
>Since Excel 2003, changes in A1 would still force a recalc of A2.
>When the inputs to A1 change, Excel is smart enough to realize that
>the dependents of A1 need to be recalculated, even though the physical
>contents of A1 are unchanged.
>
>That's with cell references.  The problem arises when you retrieve an
>object via a raw string "my_object".  In this case you have no
>guarantee that you're getting the latest version of "my_object".
>
>Anyway under the revised design, the existing behavior of OH is
>preserved, and cell A1 contains "my_object~_xxxxx".  Normally A2 holds
>a reference to A1.  But in the special case described above we also
>have the option for A2 to refer to the raw string ""my_object".  In
>this case the user must ensure that a refresh of A1 is followed by a
>refresh of A2.  As mentioned in our environment we accomplish this by
>putting A1 on a separate sheet and closing the sheet after the object
>is instantiated.
>
> > Just my 2 cents worth...
>
>I very much welcome your feedback.
>
>Regards,
>Eric

Re: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL

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

Hi Toy,

From your message it's not clear to me whether you're responding to my
original proposal (20 April) or the revised one (24 April).

Let me reiterate that under the revised proposal, the existing
behavior of OH would be retained.  The user would additionally have
the option of retrieving objects via handle stubs.

On 4/24/06, Toyin Akin <toy...@ho...> wrote:
> I don't like the idea of the user being able to use the stub key if a uni=
que
> key is generated for him/her and this new key provides no chances of
> mispricing on the sheet (assuming that all input parameters are correct a=
nd
> the user knows the instrument they are pricing).

Under the revised proposal, OH supports retrieval of objects both by
the handle stub ("my_object") and the full handle
("my_object~_xxxxx").  Normally objects would be retrieved by their
full handle but if required the user has the option of retrieving an
object by its stub - in which case the user must respect the caveat
that Excel no longer forces the object to be refreshed before it is
referenced.

If you feel that allowing this alternative behavior is dangerous then
we could consider making the behavior configurable - you could build
OH such that retrieval of objects via the handle stub is not supported
(i.e. preserve the current behavior).

> As your library grows and many more objects are added, using the stub onl=
y
> approach makes it difficult to track unique objects.

Under the proposed approach OH throws an exception if a user attempts
to retrieve an object via its handle stub and two objects exists with
the same stub.

> Why not stick with the "my_object~_xxxxx" key?

For normal use yes.

We have a special case where we'd like to support retrieval of objects
via the stub.  Consider three sheets which
1) instantiate some rate helper objects (qlDepositRateHelper)
2) update the rates in real time (qlSetQuote)
3) bootstrap the yield curve (qlPiecewiseFlatForward)

Now imagine that we have multiple versions of #2 depending on where we
want to source the rates feed.  When we bootstrap the yield curve, we
don't want to bother about which sheet is updating the rates.  Here's
what we do:

- Load sheet #1, refresh it, and close it.
- The OH repository is now initialized with a collection of rate
helper objects ("ON", "1W", "1M", etc.)
- The sheet which created these objects (#1) is closed, so the objects
will not be reconstructed again
- Load sheets #2 and #3.  The curve is bootstrapped, the rates are
updated in real time, and the state of the curve changes accordingly
(thanks to QL's behind-the-scenes use of the Observer/Observable
pattern)
- Note that no further deconstruction/reconstruction of objects is
taking place - we are merely changing the state of the rate helper and
yield curve objects, which were constructed once

If we have to use full handles, then sheet #3 needs to know which
version of sheet #2 is in use.  This could change from one session to
the next.  Maintaining this link is not impossible but we find it more
convenient to allow objects to be referenced via handle stubs.  Sheets
#2 and #3 simply trust that rate helper objects ("ON", "1W", "1M",
etc.) exist without needing to know their full handles.  Therefore
sheet #3 doesn't need to link to sheet #2 and we can switch to a
different version of sheet #2 without editing sheet #3.

> Also using the stub key only where the object may have already have been
> created (a yieldcurve and a book object with the same name) would cause
> errors on the spreadsheet that will be very difficult to track down.
>
> The result will simply display #value, but for the user, how do you debug
> this?
>
> Visiting dependant cells may not help, because the previous object with t=
he
> same name may have been created within another pricing calculation
> (worksheet/workbook same Excel session).

Suppose the user tries to create two objects, and supplies the same
stub, "my_object", to both constructors.  This will succeed, exactly
as it does today - the first object will be created e.g. as
"my_object~_00001" and the second as "my_object~_00002".If the user
requests "my_object~_00001" or "my_object~_00002" he gets the correct
object back.  If he requests "my_object", OH sees that two objects
exist with that handle stub and throws an exception.

> What are the main issues in not using the computed key?

As discussed - normally we use the computed key.  But when we want to
reference an object and don't want to keep track of where in the Excel
session it resides - we reference it via the handle stub.

> Also, the "stub" key is static and Excel will not detect a change within
> it's calculation dependency list. One will have to resort to a global (F9=
)
> spreadsheet computation in order to ensure any new changes to the key is
> picked up (that's assuming the previously created object is not part of t=
his
> updating too!!)

I was under the same impression, until Plamen clarified things for me.

Consider two cells, A1 which constructs an object, and A2 which
references the object in A1.

Under the design proposed on 20 April, A1 would hold value "my_object".

Since Excel 2003, changes in A1 would still force a recalc of A2.=20
When the inputs to A1 change, Excel is smart enough to realize that
the dependents of A1 need to be recalculated, even though the physical
contents of A1 are unchanged.

That's with cell references.  The problem arises when you retrieve an
object via a raw string "my_object".  In this case you have no
guarantee that you're getting the latest version of "my_object".

Anyway under the revised design, the existing behavior of OH is
preserved, and cell A1 contains "my_object~_xxxxx".  Normally A2 holds
a reference to A1.  But in the special case described above we also
have the option for A2 to refer to the raw string ""my_object".  In
this case the user must ensure that a refresh of A1 is followed by a
refresh of A2.  As mentioned in our environment we accomplish this by
putting A1 on a separate sheet and closing the sheet after the object
is instantiated.

> Just my 2 cents worth...

I very much welcome your feedback.

Regards,
Eric

RE: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL

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

Hi Eric,

I don't like the idea of the user being able to use the stub key if a unique 
key is generated for him/her and this new key provides no chances of 
mispricing on the sheet (assuming that all input parameters are correct and 
the user knows the instrument they are pricing).

As your library grows and many more objects are added, using the stub only 
approach makes it difficult to track unique objects.

Why not stick with the "my_object~_xxxxx" key?

Also using the stub key only where the object may have already have been 
created (a yieldcurve and a book object with the same name) would cause 
errors on the spreadsheet that will be very difficult to track down.

The result will simply display #value, but for the user, how do you debug 
this?

Visiting dependant cells may not help, because the previous object with the 
same name may have been created within another pricing calculation 
(worksheet/workbook same Excel session).

What are the main issues in not using the computed key?

Also, the "stub" key is static and Excel will not detect a change within 
it's calculation dependency list. One will have to resort to a global (F9) 
spreadsheet computation in order to ensure any new changes to the key is 
picked up (that's assuming the previously created object is not part of this 
updating too!!)

Just my 2 cents worth...

Toy out.


>From: "eric ehlers" <eri...@gm...>
>To: "QuantLib developers" <qua...@li...>
>Subject: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL
>Date: Mon, 24 Apr 2006 08:54:40 +0200
>
>Hello,
>
>Plamen pointed out to me that the change below breaks dependency
>tracking where the user supplies the handle as a literal string
>(rather than a cell reference).  So I rolled back that change,
>apologies for the confusion.
>
>I propose instead a solution which preserves existing behavior while
>additionally allowing the user to refer to objects by the handle stub:
>
>- user creates object and supplies stub "my_object"
>- OH suffixes stub with unique key returning "my_object~_xxxxx" to calling 
>cell
>- user may later ask for either "my_object" or "my_object~_xxxxx" and
>OH is intelligent enough to always retrieve "my_object~_xxxxx"
>
>If the user refers to an object by its stub then dependency tracking
>is not enforced and the user is responsible for ensuring that the
>referenced object is refreshed before it is requested.
>
>Also the handle stub is not guaranteed to be unique.  When the user
>refers to an object by the stub then OH checks whether multiple
>objects exist with the same identifier and if so an exception is
>thrown.
>
>Please get back to me with any thoughts or concerns.  I hope to
>proceed shortly with the implementation.
>
>Regards,
>Eric
>
>On 4/20/06, eric ehlers <eri...@gm...> wrote:
> > Hi All
> >
> > Problems have arisen with the ObjectHandler feature of decorating
> > object handles e.g. "my_object" -> "my_object_~xxxxx" and in CVS I've
> > disabled this feature.  Garbage collection continues to function as
> > before but the user is now responsible for guaranteeing that his
> > handles are unique.
> >
> > If this causes problems please let me know.  Please see below if you
> > require further detail.
> >
> > Many Thanks,
> > Eric
> >
> >
> > The user supplies a stub "my_object" and gets back "my_object_~xxxxx"
> > where xxxxx is a unique key used to link back to the calling cell for
> > purposes of garbage collection.    xxxxx gets incremented every time
> > the object is reconstructed.
> >
> > Suppose the user wants to pass that object to another function. If he
> > just references the cell containing the object e.g. A3 then all is
> > well.  But suppose a reference to the calling cell isn't convenient.
> > The user knows he called his object "my_object" and wants to use that
> > handle but can't because the object is now called "my_object_~xxxxx".
> >
> > The example presented to me is where we might use one of several
> > different workbooks to create rate helpers e.g. "1W", "1M", ... We
> > want to bootstrap the yield curve without worrying about which book
> > was used to create the helpers so we want to refer to the rate helpers
> > by their raw handles not by referencing the cell in which the rate
> > helper object resides.
> >
> > In CVS I've commented out the old behavior and replaced it with a
> > tentative implementation of the new approach.  The "~xxxxx" is
> > retained internally for garbage collection which continues to function
> > as before but the user doesn't see this and is now responsible for
> > ensuring that his handles are unique (as has always been the case when
> > GC is disabled).  Longer term I would make some further refinements to
> > the new code I just want to make sure this change won't cause problems
> > for anyone.
>
>
>-------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job 
>easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL

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

Hello,

Plamen pointed out to me that the change below breaks dependency
tracking where the user supplies the handle as a literal string
(rather than a cell reference).  So I rolled back that change,
apologies for the confusion.

I propose instead a solution which preserves existing behavior while
additionally allowing the user to refer to objects by the handle stub:

- user creates object and supplies stub "my_object"
- OH suffixes stub with unique key returning "my_object~_xxxxx" to calling =
cell
- user may later ask for either "my_object" or "my_object~_xxxxx" and
OH is intelligent enough to always retrieve "my_object~_xxxxx"

If the user refers to an object by its stub then dependency tracking
is not enforced and the user is responsible for ensuring that the
referenced object is refreshed before it is requested.

Also the handle stub is not guaranteed to be unique.  When the user
refers to an object by the stub then OH checks whether multiple
objects exist with the same identifier and if so an exception is
thrown.

Please get back to me with any thoughts or concerns.  I hope to
proceed shortly with the implementation.

Regards,
Eric

On 4/20/06, eric ehlers <eri...@gm...> wrote:
> Hi All
>
> Problems have arisen with the ObjectHandler feature of decorating
> object handles e.g. "my_object" -> "my_object_~xxxxx" and in CVS I've
> disabled this feature.  Garbage collection continues to function as
> before but the user is now responsible for guaranteeing that his
> handles are unique.
>
> If this causes problems please let me know.  Please see below if you
> require further detail.
>
> Many Thanks,
> Eric
>
>
> The user supplies a stub "my_object" and gets back "my_object_~xxxxx"
> where xxxxx is a unique key used to link back to the calling cell for
> purposes of garbage collection.    xxxxx gets incremented every time
> the object is reconstructed.
>
> Suppose the user wants to pass that object to another function. If he
> just references the cell containing the object e.g. A3 then all is
> well.  But suppose a reference to the calling cell isn't convenient.
> The user knows he called his object "my_object" and wants to use that
> handle but can't because the object is now called "my_object_~xxxxx".
>
> The example presented to me is where we might use one of several
> different workbooks to create rate helpers e.g. "1W", "1M", ... We
> want to bootstrap the yield curve without worrying about which book
> was used to create the helpers so we want to refer to the rate helpers
> by their raw handles not by referencing the cell in which the rate
> helper object resides.
>
> In CVS I've commented out the old behavior and replaced it with a
> tentative implementation of the new approach.  The "~xxxxx" is
> retained internally for garbage collection which continues to function
> as before but the user doesn't see this and is now responsible for
> ensuring that his handles are unique (as has always been the case when
> GC is disabled).  Longer term I would make some further refinements to
> the new code I just want to make sure this change won't cause problems
> for anyone.

[Quantlib-dev] Applying to join the QuantLib project

[Li, Q. <qiu...@im...>]

Dear Administrator,


I am a PhD student doing computational biology at Imperial College =
London and=20
I obtained a BEng and an MSc, both in computer science.


As I am very interested in the QuantLib project, I am wondering whether =
I can particiapte=20
the group to write some code.  As I have limited finance knowledge =
(reading Options,
Futures, and Other Derivatives by John Hull though), I'll have to start =
from some
easy assignments.  Basically my interests include but not limited to the =
following categories:


Monte Carlo, Credit derivatives, and Pricing engines.


Thank you very much for your consideration and I look forward to =
receiving from you.



Sincerely,


Stephen

>>>>>>>>>>>>>>>>>>>>>>>>>>>.
Developers willing to contribute to the QuantLib project may contact the =
QuantLib developers' mailing list (<quantlib-dev at =
lists.sourceforge.net>) and describe their experience and interests. You =
might want to specify an area of the library you are particularly =
interested to, or which would be most useful to you. Asking the =
administrators to choose a task for you is ok, but it might take time to =
get an answer and it increases the odds that the chosen task will bore =
you or otherwise discourage you from completing it.

[Quantlib-dev] Contributing to the project

[Pedro de N. N. <nas...@ya...>]

Hi there,

 

Let me briefly introduce myself: my name is Pedro Nassif, I am a
4-year-C++-experienced computer engineer + MBA working at a software
provider called SOPHIS (www.sophis.net) in the finance industry. My company
sells portfolio and risk management systems for banks and hedge funds. The
product has a toolkit framework by which users are able to extend the
application via C++ API. I am a consultant on that specific field: among
other things, I customize the application via C++, creating new pricing
models for instruments in a variety of asset classes, new risk
scenarios/stress tests and so on.

 

I read about Quantlib project on the net and in addition to finding it a
terrific idea, I feel like being able to contribute to it with my modest
experience and expertise.

I am particularly interested in fixed income and credit derivatives domains
even though my company is stronger in the equity derivative side.

I quickly went through your to-do list and as a starting point, doing the
greeks in the your montecarlo framework tempts me. 

 

Please let me know your thoughts,

 

Kind regards,

Pedro Nassif

 

 

[Quantlib-dev] Re: Quantlib-dev digest, Vol 1 #441 - 2 msgs

[<TB...@ao...>]

Hi Luigi,
 
1) Discrete Dividends in Binomial tree
Please see below e-mail from Professor Hull who wrote the Hull/White book  on 
Options, Futures and other Derivatives on his views below on how discrete  
dividends should be handled.  This means that what we had previously during  
early days of development of Convertible Bonds engine was correct.
 
My preferred approach  is to model the stock price less the PV of the 
dividends and then add dividends  in. This is described in my book. It has the 
advantage of being consistent with  the way European options are valued using 
Black-Scholes and is widely used in  practice. 
John  Hull 
2)  Monte Carlo Simulation of Hull White process for the  MBS pricing engine, 
I have a few ideas I would experiment with till your  contribution arrives. 
Regards
 
Theo
 

[Quantlib-dev] Decoration of Handles in ObjectHandlerXL

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

Hi All

Problems have arisen with the ObjectHandler feature of decorating
object handles e.g. "my_object" -> "my_object_~xxxxx" and in CVS I've
disabled this feature.  Garbage collection continues to function as
before but the user is now responsible for guaranteeing that his
handles are unique.

If this causes problems please let me know.  Please see below if you
require further detail.

Many Thanks,
Eric


The user supplies a stub "my_object" and gets back "my_object_~xxxxx"
where xxxxx is a unique key used to link back to the calling cell for
purposes of garbage collection.    xxxxx gets incremented every time
the object is reconstructed.

Suppose the user wants to pass that object to another function. If he
just references the cell containing the object e.g. A3 then all is
well.  But suppose a reference to the calling cell isn't convenient.
The user knows he called his object "my_object" and wants to use that
handle but can't because the object is now called "my_object_~xxxxx".

The example presented to me is where we might use one of several
different workbooks to create rate helpers e.g. "1W", "1M", ... We
want to bootstrap the yield curve without worrying about which book
was used to create the helpers so we want to refer to the rate helpers
by their raw handles not by referencing the cell in which the rate
helper object resides.

In CVS I've commented out the old behavior and replaced it with a
tentative implementation of the new approach.  The "~xxxxx" is
retained internally for garbage collection which continues to function
as before but the user doesn't see this and is now responsible for
ensuring that his handles are unique (as has always been the case when
GC is disabled).  Longer term I would make some further refinements to
the new code I just want to make sure this change won't cause problems
for anyone.



It's been pointed out to me that there's a problem with
ObjectHandler's feature of taking a user-supplied handle e.g.
"my_object" and decorating it to "my_object_~xxxxx" to force
uniqueness and faciliate garbage collection.

I propose to suppress this decoration,

Some further detail below.

Thanks,
Eric

[Quantlib-dev] [ quantlib-Bugs-1472546 ] Mac OS X 10.4. Configure fails

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

Bugs item #1472546, was opened at 2006-04-18 14:25
Message generated for change (Comment added) made by j_sargent_99
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1472546&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac OS X 10.4. Configure fails

Initial Comment:
I have installed boost libs in /usr/local/include and usr/local/bin dirs,
however running ./configure gives configure: error: Boost development 
files not found and quits. 

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

Comment By: jsargent (j_sargent_99)
Date: 2006-04-19 21:22

Message:
Logged In: YES 
user_id=1264893

I experienced something similar.  When I built and installed boost (in /Users/
myName/dev/include), it creates an enclosing folder for the version of boost 
that was built, i.e. the header files end up in /Users/myName/dev/include/
boost-1_34/boost/.

For QuantLib to build I had to use the configure options to explicitly locate 
the boost install like so:
./configure --with-boost-include=/Users/myName/dev/include/boost-1_34 
--with-boost-lib=/Users/myName/dev/lib

There may be a more elegant way to resolve it, but everything built and ran 
fine after that.

Jeff



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

Comment By: Luigi Ballabio (lballabio)
Date: 2006-04-19 04:47

Message:
Logged In: YES 
user_id=75450

Please look at config.log and post the relevant error messages.

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

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

Re: [Quantlib-dev] Quanto LMM QuantLib developement

[Klaus S. <kla...@fr...>]

Hi Toy,

An interesting solution would be to simulate the multi currency LMM as 
proposed by e.g. Fries by using a composite stochastic process consisting of 
a Black Scholes process for FX, a plain "home" LMM interest rate and a 
foreign LMM interest rate having the "quanto adjustment"...plus a bunch of 
new correlations between the three processes (calibrated using historical 
correlations?)

cheers
 Klaus

On Tuesday 11 April 2006 1:58 pm, Toyin Akin wrote:
> Hi Klaus,
>
> Thanks for the pdf file.
>
> Looks like it's not going to be as easy as I thought.
>
> What would you suggest would be the best method of integration of Quanto
> rates into the LMM model given that we already have a BlackScholesProcess
> object within quantLib.
>
> Toy out.
>
> From: Klaus Spanderen <kla...@fr...>
>
> >Reply-To: kla...@fr...
> >To: "Toyin Akin" <toy...@ho...>
> >CC: qua...@li...
> >Subject: Re: [Quantlib-dev] QuantLib developement
> >Date: Mon, 10 Apr 2006 08:36:23 +0200
> >
> >Hi Toy,
> >
> >I found the following slides on LMM and quanto structures quite good
> >
> >http://www.christian-fries.de/finmath/PDF/
> >CrossCurrencyLIBORModels-MarkovFunctionalModel_Koeln2004.pdf
> >
> >cheers
> >  Klaus
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Quantlib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] [ quantlib-Bugs-1472546 ] Mac OS X 10.4. Configure fails

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac OS X 10.4. Configure fails

Initial Comment:
I have installed boost libs in /usr/local/include and usr/local/bin dirs,
however running ./configure gives configure: error: Boost development 
files not found and quits. 

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2006-04-19 11:47

Message:
Logged In: YES 
user_id=75450

Please look at config.log and post the relevant error messages.

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

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