Re: Some questions

[Sadruddin Rejeb-3]

Hi guys,
Remember the changes to the instrument and pricing engine stuff we talked
about a few weeks ago? Well, I finally have some time now to implement them
so I just want to make sure that nobody else has started doing the job.
Another thing, I noticed that a .NET module, which appears to
be a re-implementation of QuantLib in C#, has been created. I would like to
know what are the goals of this project and how the collaboration between the
two development efforts is going to work.
Thanks and best regards,
Sad

[Jens Thiel]

> Another thing, I noticed that a .NET module, which appears to
> be a re-implementation of QuantLib in C#, has been created. I
> would like to
> know what are the goals of this project and how the collaboration
> between the
> two development efforts is going to work.

I also have some time available now, and I started the .NET project last
week, and continued yesterday. I agreed with Nando to be ahead a week or so
before officially announcing the availability of the module.

Initially, QuantLib.NET will be a proof-of-concept, a replacement for our
existing COM wrappers around the C++ version, and a personal dive into .NET
technology and also the existing QuantLib.

I collected the following items as "goals" (see references at end):

 # deliver a working QuantLib implementation targeted to the
   CLR in platform-independent code

   - support CLRs on different platforms (eg mono[1], rotor[2][3])
   - maybe supply native optimizations after profiling since
     you can easily merge namespaces from multiple assemblies

 # Use C# instead of managed C++

   - a test implementation in managed C++ was not so "nice"
     (don't know if I should check this in)
   - I personally find C# more productive for .NET development
   - better .NET and VS.NET integration than C++
   - forced to write plattform-independent code
   - free implementations available from MS[4], mono[1] and
     rotor[3]. You can use Emacs+make or alternative free
     IDEs like SharpDevelop[5]

 # follow .NET guidelines for class libraries and integrate
   smoothly in the .NET world

   - bring in experiences from COM development
   - use common interfaces, events and delegates
   - allow to easily access data from different sources
   - supply parameterless ctors and factories for COM
     (also come doesn't like overloads)

 # Support COM interop to make QuantLib.NET available in eg.
   Excel (97+), Access (97+), VB6 and others

 # Intensive unit-testing and examples

 # For the future:

   - Generate web services and support XML


I can generally see some problems here

 # we have to give up templates for now (but generics
   will be available in a future .NET release (see
   papers at m$ research)

 # syncing C++ and .NET development will be the hardest
   part, but having unit tests can help a lot

 # performance; but we can substitute critical code
   with native implementations. We may also see improved
   JIT compilers in the future.


I think I will ask Nando to announce the .NET module at the beginning of
next week, but early feedback is always welcome! If there is sufficient
interest I'll also try to update the CVS more frequently (but don't
complain, it's currently mostly untested code...).

With the beginning of next week, current snapshots will be available for
download, so you can start using .NET instantly with eg. Excel.


Please post your questions or comments. I would also like to discuss some
architectural issues like mixing of managed/unmanaged code, since I am new
to .NET for myself.


Jens.

References (as usual, must be on one line)

[1] http://www.go-mono.com/
[2] http://www.oreillynet.com/pub/a/dotnet/2001/06/27/dotnet.html
[3]
http://msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/901/m
sdncompositedoc.xml
[4]
http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/000/976/m
sdncompositedoc.xml
[5] http://www.icsharpcode.net/OpenSource/SD/default.asp

[Ferdinando M. Ametrano-2]

Hi Sad

>Remember the changes to the instrument and pricing engine stuff we talked
>about a few weeks ago? Well, I finally have some time now to implement them
>so I just want to make sure that nobody else has started doing the job.
I am the only one working on them. Unfortunately I haven't had free time in
the last 3 weeks. I revised the european engine, and added generic
quanto/forward engine.
High priorities in my task list are (almost in order):
- create 2 different vol term structure classes: Black vol and Local vol,
the former simply being the market quoted vol (prices) surface, while the
latter should be the local vol used for the underlying stochastic process.
The latter is the one to be used by the pricing engines
- substitute doubles with term structures in engine's parameters where
appropriate, so to allow for time dependent parameters (e.g. time varying
vols and yields for asian options)
- use your Exercise class in the engines
- write a forward quanto engine combining the existing forward and quanto
engines
- write the Finite Difference engine for european/american option
- write the Monte Carlo engine for european options
- move as many Pricers as possible from the old Pricer framework to the
engine framework
- release QuantLib 0.4

I would be glad if you join me on these tasks. Please don't consider my
late reply as a sign of disinterest. BTW since my feedback time is getting
higher consider also working on your own branch if this allow you to write
faster without having to worry about my timely feedback

ciao -- Nando

[Ferdinando M. Ametrano-2]

Hi all

Sad wrote:
>Another thing, I noticed that a .NET module, which appears to
>be a re-implementation of QuantLib in C#, has been created. I
>would like to
>know what are the goals of this project and how the collaboration
>between the
>two development efforts is going to work.

and Jens replied:
>Initially, QuantLib.NET will be a proof-of-concept, a replacement for our
>existing COM wrappers around the C++ version, and a personal dive into .NET
>technology and also the existing QuantLib.
Well I think the majority here would be more confident to have wrappers of
the existing C++ code, but Jens pointed out his reasons for C# and I see no
problem in allowing QuantLib.NET as long as Jens is committed to it.

>  # Use C# instead of managed C++
>
>    - a test implementation in managed C++ was not so "nice"
>      (don't know if I should check this in)
I was surprised nobody asked you about this. Jens, could you elaborate more?

>  # syncing C++ and .NET development will be the hardest
>    part, but having unit tests can help a lot
if the development speed of QuantLib will be the same as in the last weeks
it won't be really a problem ;-)
Jokes aside, it will be really hard. We would need a C++ unit test
framework. any Boost user here?

>I think I will ask Nando to announce the .NET module at the beginning of
>next week, but early feedback is always welcome! If there is sufficient
>interest I'll also try to update the CVS more frequently (but don't
>complain, it's currently mostly untested code...).
Jens, please keep us updated

>With the beginning of next week, current snapshots will be available for
>download, so you can start using .NET instantly with eg. Excel.
please provide us a quick intro ...

ciao -- Nando