General

[matmjm]

Luigi,

It's not hard to move code from Java to C++ and conversely so if you find something in my code which you like please go ahead and take it.

It would certainly be good if our respective efforts could benefit from each other.

I have a fully developed Libor market model which I wrote in C++ and which I would be willing to contribute to your cause. I might be willing to put in some effort once I have overcome my resistance to go back to C++ agai.

So when you start working on this maybe focus your effort on interfacing with data source providers and definition of data structures for instruments
(caps, swaptions, these are needed for model calibration). Please let me also know who would be the person on your team working on this so I can get I touch with him.

Best of luck and congratulations for your effort,

Michael

[Michael Lewis-5]

Michael,

>It's not hard to move code from Java to C++

But if some subsystem is designed with 'generic'
(template) programming approach rather than a
traditional OO design, then moving from Java to C++
is likely to involve redesign and not just converting
the code.

In choice of language, interface might be important -
hence having a PERL/RUBY interface to Quantlib would
be great - even some XML definition and SOAP functions
would be good for cross platform. But, why would you
want to write the core of a pricing library in Java?
It seems pointless - since any practical use will
require performance that Java will not be able to
match when compared with the C++.

Rgds

Mike


--- [hidden email] wrote:

> Luigi,
>
> It's not hard to move code from Java to C++ and
> conversely so if you find something in my code which
> you like please go ahead and take it.
>
> It would certainly be good if our respective efforts
> could benefit from each other.
>
> I have a fully developed Libor market model which I
> wrote in C++ and which I would be willing to
> contribute to your cause. I might be willing to put
> in some effort once I have overcome my resistance to
> go back to C++ agai.
>
> So when you start working on this maybe focus your
> effort on interfacing with data source providers and
> definition of data structures for instruments
> (caps, swaptions, these are needed for model
> calibration). Please let me also know who would be
> the person on your team working on this so I can get
> I touch with him.
>
> Best of luck and congratulations for your effort,
>
> Michael
>
>
>
>

_______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for
> download mirrors. We supply
> the hardware. You get the recognition. Email Us:
> [hidden email]
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
>
https://lists.sourceforge.net/lists/listinfo/quantlib-users


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

[Luigi Ballabio-4]

At 03:03 AM 5/15/02 -0700, Michael Lewis wrote:
> >It's not hard to move code from Java to C++
>
>But if some subsystem is designed with 'generic'
>(template) programming approach rather than a
>traditional OO design, then moving from Java to C++
>is likely to involve redesign and not just converting
>the code.

I agree. Of course one can choose to use GJ
(http://www.research.avayalabs.com/user/wadler/pizza/gj/index.html)
or wait for Sun to add generics to Java. They are considering it, I think.


>In choice of language, interface might be important -
>hence having a PERL/RUBY interface to Quantlib would
>be great - even some XML definition and SOAP functions
>would be good for cross platform.

We do have a Ruby interface (and a Python one). You can download it from
http://www.quantlib.org/download.html
Perl is not there yet, mainly because I'm not personally interested in the
language (he reachs for its flame-proof jacket and runs for cover.)


>But, why would you want to write the core of a pricing library in Java?
>It seems pointless - since any practical use will require performance that
>Java will not be able to match when compared with the C++.

I'm not sure that it isn't feasible for *any* practical use (did I get the
double negative right?)
For instance, the performance gap could be amortized away if the user must
pass through other bottlenecks (database access times, 56k modems...)
before reaching the calculation core.
Or, one might be unlucky enough to have to interface the engine to Java
directly (I know it would be much better to do this through CORBA or SOAP
or something, but PHBs work in mysterious ways). Were this the case, the
run-time advantage of C++ could be dwarfed by the development-time
advantage of _not_ having to go though JNI---which, if you ask me, was
designed with the purpose to discourage its own use.
(he asks out of ignorance)
Also, what is the current status of Java-to-native compilers? gcj, for
instance?


This said, I will continue to develop in C++ :)

Bye for now,
                 Luigi