bermudan swaption, simplex

[Roland Lichters]

Hi,
I am trying to run the bermudan swaption example, but the Hull White numerical calibration hangs. I hope not to bother you with a very stupid beginner's (I am!) mistake. But I think this is because the Simplex::minimize() which is used in the example does not check end criteria, i.e. "bool end = false" never changes and the loop continues while end == false.
Would you please have a look at this?
Indeed impressed by your work!
Roland
______________________________________________________________________________
Viren? Wir wissen nicht was Ihr Arzt empfiehlt. Wir empfehlen den
Virencheck fur Ihre E-Mail-Anhange! http://freemail.web.de/features/?mc=021159

[Chak Jack Wong]

Hi,
I would like to know if anyone has tried to make a automatic wrapper for excel addins?
I am using XLW now with string representation of object on spreadsheet.
Exporting functions to Excel is pretty tedious requiring a fair amount of handcoding.
I looked at Jens-Thiel's excel-addin through IDL, but we don't use IDL.
I am wondering if anyone has tried generating excel addin directly from C++ header files with doxygen comments (or java doc or some other special marking ).

maybe SWIG for excel?

Jack

[Luigi Ballabio-2]

At 11:15 PM 2/4/03 +0100, [hidden email] wrote:
>I am trying to run the bermudan swaption example, but the Hull White
>numerical calibration hangs.

Roland,
         are you sure it actually hangs? On my box, the analytic
calibration is almost instantaneous, while the numerical calibration takes
over 10 minutes to complete---which might as well give the impression of
hanging (and suggests choosing the analytic calibration for actual work :)
Could you try and let it run during a lunch break or something?

Oh, and thanks for the kind words...

Later,
         Luigi

[Jens Thiel]

Hi Jack,

> I would like to know if anyone has tried to make a automatic
> wrapper for excel addins?

I do not know about such a beast. libXLL was the best solution I could
personally came up with, also it has still lots of limitations.

> I looked at Jens-Thiel's excel-addin through IDL, but we don't use IDL.

So I can assume you also do not use COM as well?

> maybe SWIG for excel?

Have you thought about making the python interpreter an excel-addin? That
would allow to pass code to be interpreted at run-time. Not a very clean
solution, I think.

There are COM wrappers for Python, but I have no idea how this would work
with the generated SWIG bindings.

Another option to be considered is improving QL.NET's COM support, and use
the interop features of the .NET framework. AFAIK will the next Excel
support .NET directly, so you have the best upgrade path possible.

> I am using XLW now with string representation of object on spreadsheet.

Are you using some kind of "stringified monikers" for object references, or
do you serialize and store the objects "by value"?


Jens.

[Luigi Ballabio-2]

At 09:32 AM 2/5/03 +0000, Chak Jack Wong wrote:
>I am wondering if anyone has tried generating excel addin directly from
>C++ header files.
>
>maybe SWIG for excel?

Jack,
         I'm not aware of any generator of this kind. Also, I'm kind of
skeptical about the possibility of generating *object* wrappers
automatically since the paradigms don't match---Excel is a functional language.
The way to go would be the one Nando pursued, i.e., adding a functional
layer over the objects (see ql/Functions, even though I'm not sure they
really belong there) and wrapping the functions. This could be done
automatically if a generator were available, or at least, the tedium could
be reduced by using the machinery Nando put together in QuantLibXL. But in
my opinion, the creation of the functional layer requires more intelligence
than a program can be expected to show.

Bye,
         Luigi

[Ferdinando M. Ametrano-2]

Hi all

looks like the Excel add-in is the hot topic today ;-)

Andreas Lorenz wrote:
>I had a look at the QuantlibXL add-in and saw that it has not been updated
>for nearly 10 months now. Is there any further development going on?
QuantLibXL features a poor interface that I put together quick and dirty
just to solve a problem I had at work.
I planned at the time to invest more time for the Excel add-in project and
got involved with Jerome Lecompte (the xlw author). Unfortunately things
changed and I've been not active on that project anymore, even if I am
really interested.

Chak.K.Wong wrote:
>I am using XLW now with string representation of object on spreadsheet.
>Exporting functions to Excel is pretty tedious requiring a fair amount of
>handcoding.
>I looked at Jens-Thiel's excel-addin through IDL, but we don't use IDL.
If I'm not wrong Jens' libXLL has included xlw code base, so it should be
an equal or better choice vs xlw.
All things being equal I was thinking about moving QuantLibXL to libXLL.

Chak.K.Wong:
>I would like to know if anyone has tried to make a automatic wrapper for
>excel addins?
>[...]
>I am wondering if anyone has tried generating excel addin directly from
>C++ header files with doxygen comments (or java doc or some other special
>marking ).
>[...]
>maybe SWIG for excel?
this would be my dream, but Luigi has always been skeptical.

Luigi Ballabio wrote:
>I'm not aware of any generator of this kind. Also, I'm kind of skeptical
>about the possibility of generating *object* wrappers automatically since
>the paradigms
>  don't match---Excel is a functional language.

Luigi Ballabio wrote:
>The way to go would be the one Nando pursued, i.e., adding a functional
>layer over the objects (see ql/Functions, even though I'm not sure they
>really belong there) and wrapping the functions. This could be done
>automatically if a generator were available, or at least, the tedium could
>be reduced by using the machinery Nando put together in QuantLibXL.
This functional layer might be useful to other extensions too. Gnumeric
comes to my mind.
Jody: do you have any suggestion on this? How could we try to spark a
cooperative work for a common Gnumeric/Excel add-in?
I do know that QuantLib-Python can be already used in Gnumeric, but one
could prefer a native addin for a number of reasons.

Luigi Ballabio wrote:
>  But in my opinion, the creation of the functional layer requires more
> intelligence than a program can be expected to show.
thanks for the encouragement ;-)

Jens Thiel wrote:
>Another option to be considered is improving QL.NET's COM support, and use
>the interop features of the .NET framework. AFAIK will the next Excel
>support .NET directly, so you have the best upgrade path possible.
I'm sure this is a very good approach, one that should be pursued even if
we pick up other alternatives for Excel. Of course you will be exposing to
Excel the C# version of QuantLib instead of the C++ version: I'm not
discussing personal language preferences here, but someone might want to
use C++ over C#


------------
ciao -- Nando

[Luigi Ballabio-2]

At 10:59 AM 2/5/03 +0100, Jens Thiel wrote:
> > maybe SWIG for excel?
>
>Have you thought about making the python interpreter an excel-addin? That
>would allow to pass code to be interpreted at run-time. Not a very clean
>solution, I think.

Well, it works for Gnumeric :)

>There are COM wrappers for Python, but I have no idea how this would work
>with the generated SWIG bindings.

Not as smooth as one would like---there's some work to do in order to make
the bindings available through COM.

Last I knew, some people was working on adding a C# module to SWIG. But
there's no ETA that I know of, and if one's going this way, then he's
better off using QuantLib.NET...

Bye,
         Luigi

[Luigi Ballabio-2]

At 11:23 AM 2/5/03 +0100, Ferdinando Ametrano wrote:
>Luigi wrote
>>the numerical calibration takes over 10 minutes to complete---which might
>>as well give the impression of hanging (and suggests choosing the
>>analytic calibration for actual work :)
>I am under the impression that the numerical calibration has not been so
>slow in the past. Am I wrong? [Didn't bother to check it with older
>releases yet]

Sad did some work on the framework which made it more robust and fixed a
few bugs. Some part of the increased time is a price we have to pay, I
guess. But I'm not sure that at least part of it could not be
reduced---maybe switching from polymorphism to templates, or trying to
optimize some code. It would be nice to see some profiling... Sad? Any
insights?

Bye,
         Luigi

[Luigi Ballabio-2]

At 12:03 PM 2/5/03 +0100, Jens Thiel wrote:
> > Do you think this will work and can provide a general automatic wrapper
>for Excel?
>
>I could imagine that SWIG can be extended this way. C++ has been build on a
>functional language (cfront to c), Python and Perl are functional languages
>in their core. They all carry some kind of "this/self" ptr around, and
>attach functions to "this". A stringified "this" could be possible, and
>generating some mangled namespace_objecttype_methodname_overload functions
>that take this string as their first parameter as well.

Yes, this is what SWIG does already for Python---a string is passed to and
fro which encodes 'this', i.e., the address of the object.

>The problem I see here, is that a lot of code is going to be written in
>spreadsheet cells, which is very hard to maintain.

Which is the point I tried to make. My main concern with this
"functionified object interface" is usability. You'll need a cell to call
the constructor, and another to call the method you're interested in; and
you'll have to find a way to trigger recalculations, which might be hard to
maintain. For instance, if a market rate changes, any term structure using
it will be notified, as well as any swaps which are discounted on the
latter, so that the actual objects will be ready to recalculate their value
when they are asked for it. But they won't have a way to notify
Excel---they don't even *know* they're being used by Excel---so they will
*not* be asked for their new price, unless you keep track of all
dependencies on your spreadsheet...

Bye,
         Luigi

[Jens Thiel]

> maintain. For instance, if a market rate changes, any term
> structure using it will be notified [...]

Thats why XLL functions support a "volatile" marker, which is perfect for
mapping some "getter" code. The event handling and updating itself can still
be done in C++.

Jens.

[Chak Jack Wong]

The typical way I have seen to handle the recalculation is by returning a
name+recalcnumber as the object on the spreadsheet.
Whenever the function is called, a new recalc-number is generated.  Hence we
only need to use the Excel dependency mechanism.

It is rather crude, but it has been working quite alright for me.  I have seen
better mechanism that uses a handle to remember changes its value.


Luigi Ballabio wrote:

> At 12:03 PM 2/5/03 +0100, Jens Thiel wrote:
> > > Do you think this will work and can provide a general automatic wrapper
> >for Excel?
> >
> >I could imagine that SWIG can be extended this way. C++ has been build on a
> >functional language (cfront to c), Python and Perl are functional languages
> >in their core. They all carry some kind of "this/self" ptr around, and
> >attach functions to "this". A stringified "this" could be possible, and
> >generating some mangled namespace_objecttype_methodname_overload functions
> >that take this string as their first parameter as well.
>
> Yes, this is what SWIG does already for Python---a string is passed to and
> fro which encodes 'this', i.e., the address of the object.
>
> >The problem I see here, is that a lot of code is going to be written in
> >spreadsheet cells, which is very hard to maintain.
>
> Which is the point I tried to make. My main concern with this
> "functionified object interface" is usability. You'll need a cell to call
> the constructor, and another to call the method you're interested in; and
> you'll have to find a way to trigger recalculations, which might be hard to
> maintain. For instance, if a market rate changes, any term structure using
> it will be notified, as well as any swaps which are discounted on the
> latter, so that the actual objects will be ready to recalculate their value
> when they are asked for it. But they won't have a way to notify
> Excel---they don't even *know* they're being used by Excel---so they will
> *not* be asked for their new price, unless you keep track of all
> dependencies on your spreadsheet...
>
> Bye,
>          Luigi

--
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation.  Morgan Stanley
may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers.  This may refer to a
research analyst/research report. Unless indicated, these views are the author's
and may differ from those of Morgan Stanley research or others in the Firm. We
do not represent this is accurate or complete and we may not update this.  Past
performance is not indicative of future returns. For additional information,
research reports and important disclosures, contact me or see
https://secure.ms.com.  You should not use email to request, authorize or effect
the purchase or sale of any security or instrument, to send transfer
instructions, or to effect any other transactions.  We cannot guarantee that any
such requests received via email will be processed in a timely manner.  This
communication is solely for the addressee(s) and may contain confidential
information.  We do not waive confidentiality by mistransmission.  Contact me if
you do not wish to receive these communications.  In the UK, this communication
is directed in the UK to those persons who are market counterparties or
intermediate customers (as defined in the UK Financial Services Authority's
rules).