RE: it's been a while

[Bernd Johannes Wuebben-2]

Hi Nando,

        Thanks for your mail and good to hear from you again. Since we
talked last on the phone over a year ago I have been following qunatlib
development with great interest but loosely as I remain unfortunately
rather busy. As for the single factor interest model that you are
advertising, that's great! However, and this is just my opinion but I
certain it will shared by other market practitioners who have left
academia, option pricing and term structure models are great stuff
especially for people who are still in academia, however, from a
practical point of view, good, bond math, swap pricing, spline and swap
curve building capabilities, asset swap and ZVOL spreads calculators
etc. etc are so much more important. Once these things are properly
implemented with all the immeasurable head-aches that come from the
plentitude of market conventions and making sure they tie out with
established models in the market place (and be it just Bloomberg for the
bond math) playing and implementing term-structure model and building
reasonably good interest rate option pricers will almost seem like a
walk in the park. What I am trying to say here is, let's get the basics
right first, then go from there ... ;-)

        Writing _good_ Excel add-ins is a bit of an art and to some
extend a matter of trial and error as the Excel interface is horribly
documented and has bugs. Luckily no-one needs to suffer the endless
head-aches that come with figuring out how to build excel interfaces
anymore as all your prayers have come true with:

                        http://www.ifrance.com/xlw/

        I have been using that interface for various personal projects
and am quite satisfied with it. Check it out. I think there are still
some very minor bugs in the version you can download, but you will
easily find and fix them once you start working with it. Lastly, if you
feel more adventurous, check consider building a COM server object
(requiring Excel 2002) which allows you to beautifully pump data into
Excel which is particularly important for real time stuff, something
that is virtually impossible with a classical C++ add-in framework.

        Keep up the good work!

        Apropos, Dirk, did you work under Scott Pinkus in International
Markets at GS in Toronto in 1997?

Best,
Bernd Wuebben

> -----Original Message-----
> From: Ferdinando Ametrano [mailto:[hidden email]]
> Sent: Saturday, January 26, 2002 6:28 AM
> To: [hidden email]
> Subject: it's been a while
>
>
> Hi Bernd
>
> how are you?
> It's been a while since our last email.
> Hope all is well with you.
>
> I was wondering how do you feel about the QuantLib development. We're
> approaching 0.3.0 that will feature single factor interest
> rate models.
>
> In the following weeks I should start working on Excel
> add-in, even if I
> have no previous experience about it.
> I've considered working on SWIG to provide automated code
> generation for
> the Excel addin, but my limited C skills will prevent me from
> doing so,
> especially because I've been told SWIG API are very fluid at
> this time. I
> remember you once wrote about a similar goal and I'm
> wondering if you have
> suggestion or (even better) are willing to cooperate.
>
> ciao -- Nando
>

[Dirk Eddelbuettel]

On Sat, Jan 26, 2002 at 09:57:57AM -0500, Bernd Johannes Wuebben wrote:
[ snipping long paragraph on real world demands I tend to agree with]

> head-aches that come with figuring out how to build excel interfaces
> anymore as all your prayers have come true with:
>
> http://www.ifrance.com/xlw/

That URL times out a lot for me. Google has it cached, though.

> feel more adventurous, check consider building a COM server object
> (requiring Excel 2002) which allows you to beautifully pump data into

As a Unix user, I'd feel left behind. Wasn't there a loose consensus to drop
both Corba and COM and go with, say, SOAP, despite the performance hit.
Anyway, that's quite some way off.

Dirk

--
Good judgment comes from experience; experience comes from bad judgment.
                                                            -- F. Brooks

[Ferdinando M. Ametrano-2]

Hi Bernd,

thanks for forwarding my message to the quantlib-users list ;-)

>As for the single factor interest model that you are
>advertising, that's great! However, and this is just my opinion but I
>certain it will shared by other market practitioners who have left
>academia, option pricing and term structure models are great stuff
>especially for people who are still in academia, however, from a
>practical point of view, good, bond math, swap pricing, spline and swap
>curve building capabilities, asset swap and ZVOL spreads calculators
>etc. etc are so much more important.
I agree with you. As a matter of fact spline, swap curve building, and swap
pricing are already implemented in QuantLib.
Bond math is not available, mainly because we're still missing a bond class.
The reason is the core of the QuantLib developers are RiskMap employees,
RiskMap has a closed-source implementation of bond based on
QuantLib::CashFlow, nobody else volunteered to implement a Bond class.
As of February fist I will not work for RiskMap anymore, so depending on my
free time I might work on a bond class proposal.

Besides, bond math along with swap, swaption, cap, floor, asset swap were
the core of the work me and Luigi did in Caboto (the investment bank of
IntesaBCI): in a way I know we've been able to do that and I preferred to
work on MonteCarlo and Finite Difference instead, where I had plenty to learn.
This strategy also minimized any possible conflict of interest between the
work we did in Caboto and the work we're doing for QuantLib.
Now I think the time is right to implement this part: because of this I
felt very lucky when Sad Rejeb asked to do its Phd required internship
working on QuantLib, and I suggested him single factor interest rate
models, since bermudan (callable) swap are a key product for all Fixed
Income desk today

>  Once these things are properly implemented with all the immeasurable
> head-aches that come from the plentitude of market conventions and making
> sure they tie out with
>established models in the market place (and be it just Bloomberg for the
>bond math)
I've learned how hard this part is during my work in Caboto. Unfortunately
I haven't had a Bloomberg terminal in the last 2 years. My next job should
get me back to a Bloomberg terminal once again

>         Writing _good_ Excel add-ins is a bit of an art and to some
>extend a matter of trial and error as the Excel interface is horribly
>documented and has bugs. Luckily no-one needs to suffer the endless
>head-aches that come with figuring out how to build excel interfaces
>anymore as all your prayers have come true with:
>
>                         http://www.ifrance.com/xlw/
GREAT suggestion. I've started playing with it and I'm very satisfied.
I've been able to have a proof of concept for QuantLib-Excel in less then 2
hours.

>Lastly, if you feel more adventurous, check consider building a COM server
>object
>(requiring Excel 2002) which allows you to beautifully pump data into
>Excel which is particularly important for real time stuff, something
>that is virtually impossible with a classical C++ add-in framework.
I was asking around for suggestions and one of the key point was about the
need of having both QuantLib-Excel and QuantLib-COM.
Since COM would require Excel 2002, there might be a need for
QuantLib-Excel. Besides I have in mind some users who would be able to use
QuantLib-Excel but not QuantLib-COM especially if the latter would be
heavily object-oriented

In RiskMap we already use the whole QuantLib-Python as a COM via the
win32all module. My colleagues reached the conclusion that C++ COM should
be the way to go instead.
Unfortunately I have no expertise on COM, so I'm gathering informations and
I hope someone will volunteer (isn't this a job for you Adolfo? ;-)

To summarize what I've found so far on Excel/add-in/COM/C++:
- http://www.ifrance.com/xlw/
- Microsoft Excel 97 Developer's Kit (available online, in MSDEV and as book)
- HOWTO: Build an Add-in (XLL) for Excel Using Visual C++ (Q178474)
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q178474
- Comaddin.exe Office 2000 COM Add-In Written in Visual C++ (Q230689)
  http://support.microsoft.com/default.aspx?scid=kb;EN-US;q230689
- HOWTO: Build an Office 2000 COM Add-In in Visual Basic (Q238228)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q238228

other resources, anyone?

ciao -- Nando

[Ferdinando M. Ametrano-2]

At 07:13 PM 1/27/02 -0600, Dirk Eddelbuettel wrote:
> >                       http://www.ifrance.com/xlw/
>
>That URL times out a lot for me. Google has it cached, though.
it works for me with both IE6 and Netscape 6.2

> > feel more adventurous, check consider building a COM server object
> > (requiring Excel 2002) which allows you to beautifully pump data into
>
>As a Unix user, I'd feel left behind.
I would say left ahead ... the point is I will need to use QuantLib in
Excel. Not happy about that but my new job will require it, at least to
some extent

>  Wasn't there a loose consensus to drop
>both Corba and COM and go with, say, SOAP, despite the performance hit.
we were talking about CORBA and SOAP. I'm interested in both technologies,
but given that time is a limited resource ...
[BTW Joel how is going with the CORBA currency?]

In RiskMap we developed CORBA solutions, both in C++ and Python, based
respectively on QuantLib and QuantLib-Python. We've used OmniORB (open source).
On the top of the CORBA layer there are SOAP (Python), servlet (Java), and
COM (C++) solutions.
Python has a few SOAP modules, Java has native support for CORBA, the
COM-CORBA bridge has been quite difficult to implement.
I'm pretty sure Enrico, Adolfo, and Luigi would be glad to have some
feedback/contribution from this list on the design of such a machinery.
Wouldn't you guys? ;-)

ciao -- Nando

[Ben-163]

I would definetly be interested in starting work on a bond class.....
Especially if someone would be interested in vetting my work as i go
along!! I know quite a bit about bonds (www.benwootton.co.uk is my site)
and have been coding in c++ for 4 or 5 years - im going to post some of my
programs on my site later this week....

Would you want it to work similiar to the option class - ie a seperate
pricing engine?

It is also interesting to hear what everyone does when not working for
Quantlib, what does everyone else do for a job?!

Also can I ask if anyone knows anything about Deutsche Bank - ie which
areas they are strong in etc.  A friend of mine has an intereview with
their fixed income division tomorrow but is having a hard time finding
info.... Hope you dont mind me asking!

Quantlib Excel is also an excellent idea BTW...!

Regards
Ben



On Mon, 28 Jan 2002, Ferdinando Ametrano wrote:

> Hi Bernd,
>
> thanks for forwarding my message to the quantlib-users list ;-)
>
> >As for the single factor interest model that you are
> >advertising, that's great! However, and this is just my opinion but I
> >certain it will shared by other market practitioners who have left
> >academia, option pricing and term structure models are great stuff
> >especially for people who are still in academia, however, from a
> >practical point of view, good, bond math, swap pricing, spline and swap
> >curve building capabilities, asset swap and ZVOL spreads calculators
> >etc. etc are so much more important.
> I agree with you. As a matter of fact spline, swap curve building, and swap
> pricing are already implemented in QuantLib.
> Bond math is not available, mainly because we're still missing a bond class.
> The reason is the core of the QuantLib developers are RiskMap employees,
> RiskMap has a closed-source implementation of bond based on
> QuantLib::CashFlow, nobody else volunteered to implement a Bond class.
> As of February fist I will not work for RiskMap anymore, so depending on my
> free time I might work on a bond class proposal.
>
> Besides, bond math along with swap, swaption, cap, floor, asset swap were
> the core of the work me and Luigi did in Caboto (the investment bank of
> IntesaBCI): in a way I know we've been able to do that and I preferred to
> work on MonteCarlo and Finite Difference instead, where I had plenty to learn.
> This strategy also minimized any possible conflict of interest between the
> work we did in Caboto and the work we're doing for QuantLib.
> Now I think the time is right to implement this part: because of this I
> felt very lucky when Sad Rejeb asked to do its Phd required internship
> working on QuantLib, and I suggested him single factor interest rate
> models, since bermudan (callable) swap are a key product for all Fixed
> Income desk today
>
> >  Once these things are properly implemented with all the immeasurable
> > head-aches that come from the plentitude of market conventions and making
> > sure they tie out with
> >established models in the market place (and be it just Bloomberg for the
> >bond math)
> I've learned how hard this part is during my work in Caboto. Unfortunately
> I haven't had a Bloomberg terminal in the last 2 years. My next job should
> get me back to a Bloomberg terminal once again
>
> >         Writing _good_ Excel add-ins is a bit of an art and to some
> >extend a matter of trial and error as the Excel interface is horribly
> >documented and has bugs. Luckily no-one needs to suffer the endless
> >head-aches that come with figuring out how to build excel interfaces
> >anymore as all your prayers have come true with:
> >
> >                         http://www.ifrance.com/xlw/
> GREAT suggestion. I've started playing with it and I'm very satisfied.
> I've been able to have a proof of concept for QuantLib-Excel in less then 2
> hours.
>
> >Lastly, if you feel more adventurous, check consider building a COM server
> >object
> >(requiring Excel 2002) which allows you to beautifully pump data into
> >Excel which is particularly important for real time stuff, something
> >that is virtually impossible with a classical C++ add-in framework.
> I was asking around for suggestions and one of the key point was about the
> need of having both QuantLib-Excel and QuantLib-COM.
> Since COM would require Excel 2002, there might be a need for
> QuantLib-Excel. Besides I have in mind some users who would be able to use
> QuantLib-Excel but not QuantLib-COM especially if the latter would be
> heavily object-oriented
>
> In RiskMap we already use the whole QuantLib-Python as a COM via the
> win32all module. My colleagues reached the conclusion that C++ COM should
> be the way to go instead.
> Unfortunately I have no expertise on COM, so I'm gathering informations and
> I hope someone will volunteer (isn't this a job for you Adolfo? ;-)
>
> To summarize what I've found so far on Excel/add-in/COM/C++:
> - http://www.ifrance.com/xlw/
> - Microsoft Excel 97 Developer's Kit (available online, in MSDEV and as book)
> - HOWTO: Build an Add-in (XLL) for Excel Using Visual C++ (Q178474)
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q178474
> - Comaddin.exe Office 2000 COM Add-In Written in Visual C++ (Q230689)
>   http://support.microsoft.com/default.aspx?scid=kb;EN-US;q230689
> - HOWTO: Build an Office 2000 COM Add-In in Visual Basic (Q238228)
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q238228
>
> other resources, anyone?
>
> ciao -- Nando
>
>
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

--
Ben
[hidden email]

[Luigi Ballabio-4]

At 09:22 AM 1/28/02 +0000, Ben wrote:
>I would definetly be interested in starting work on a bond class.....
>Especially if someone would be interested in vetting my work as i go
>along!! I know quite a bit about bonds (www.benwootton.co.uk is my site)
>and have been coding in c++ for 4 or 5 years - im going to post some of my
>programs on my site later this week....
>
>Would you want it to work similiar to the option class - ie a seperate
>pricing engine?

I would make the base Bond class similar to QuantLib::Instruments::Swap,
only with just one leg. Also, you should take care of the fact that bonds
usually have a different number of settlement days than deposits and swaps
(and therefore the term structure bootstrapped on them) so that discount
factors should be corrected accordingly.
Once the base class is done, most concrete bonds are to it what SimpleSwap
is to Swap---just derived classes which take care of building their coupons
and delegate the discounting to the base class.
Also, I would implement IRR, duration and such not as Bond methods, but
rather as functions on generic Coupon sequences, as in:
template <class Iter>
Rate IRR(const Iter& begin, const Iter& end);

Well, I guess I said too much already <wink>

Bye,
         Luigi