quantlib spreadsheet integration

[erik-44]

hello

i'd be interested in participating in the Quantlib project

i have 12 years of experience in banking IT, some projects i'm working on now include excel addins in C++, and market data feeds via a webserver (tomcat, perl, java).

my interest would be in integrating quantlib into a speadsheet application.  (the website mentions Gnumeric, has Openoffice.org Calc been considered?)

please let me know what i'd need to do to get involved.

many thanks
eric

[Jody Goldberg-2]

On Tue, Apr 06, 2004 at 11:30:11AM -0000, [hidden email] wrote:

>
> hello
>
> i'd be interested in participating in the Quantlib project
>
> i have 12 years of experience in banking IT, some projects i'm
> working on now include excel addins in C++, and market data feeds
> via a webserver (tomcat, perl, java).
>
> my interest would be in integrating quantlib into a speadsheet
> application.  (the website mentions Gnumeric, has Openoffice.org
> Calc been considered?)

If you have any interest in working on gnumeric wrappers I'd be able
to help.

Best Wishes
    Jody (Gnumeric Maintainer)

[Luigi Ballabio-2]

On 2004.04.06 13:30, [hidden email] wrote:
> i'd be interested in participating in the Quantlib project
>
> my interest would be in integrating quantlib into a speadsheet
> application.  (the website mentions Gnumeric, has Openoffice.org Calc
> been considered?)
>
> please let me know what i'd need to do to get involved.

Eric,
        I guess Calc isn't mentioned on the site out of sheer ignorance :)  
Also, these pages haven't been updated for quite a while...

As for spreadsheet integration, I'd get in touch with Nando (nando at  
ametrano dot net), which is developing the QuantLib/Excel thing. You  
could try and work out a suitable functional interface to the library,  
which you would export to your respective spreadsheets.

Later,
        Luigi

[erik-44]

On Tue, 2004-04-06 at 14:43, Jody Goldberg wrote:

> On Tue, Apr 06, 2004 at 11:30:11AM -0000, [hidden email] wrote:
> >
> > hello
> >
> > i'd be interested in participating in the Quantlib project
> >
> > i have 12 years of experience in banking IT, some projects i'm
> > working on now include excel addins in C++, and market data feeds
> > via a webserver (tomcat, perl, java).
> >
> > my interest would be in integrating quantlib into a speadsheet
> > application.  (the website mentions Gnumeric, has Openoffice.org
> > Calc been considered?)
>
> If you have any interest in working on gnumeric wrappers I'd be able
> to help.
>
> Best Wishes
>     Jody (Gnumeric Maintainer)

Hi Jody

Many thanks.  I think Openoffice suits my needs better so if nobody
objects I'll start with that but I'll definitely get in touch if any
Gnumeric work comes up.

Regards
Eric

[erik-44]

On Wed, 2004-04-07 at 09:21, Luigi Ballabio wrote:

> On 2004.04.06 13:30, [hidden email] wrote:
> > i'd be interested in participating in the Quantlib project
> >
> > my interest would be in integrating quantlib into a speadsheet
> > application.  (the website mentions Gnumeric, has Openoffice.org Calc
> > been considered?)
> >
> > please let me know what i'd need to do to get involved.
>
> Eric,
> I guess Calc isn't mentioned on the site out of sheer ignorance :)  
> Also, these pages haven't been updated for quite a while...

Fair enough.  Openoffice seems preferable for my purposes so
if there's no objection I'll start there.

> As for spreadsheet integration, I'd get in touch with Nando (nando at  
> ametrano dot net), which is developing the QuantLib/Excel thing. You  
> could try and work out a suitable functional interface to the library,  
> which you would export to your respective spreadsheets.

Sounds good, I'll drop Nando a line.

>
> Later,
> Luigi

Many thanks,
Eric

[Dirk Eddelbuettel]

On Wed, Apr 07, 2004 at 09:25:10PM +0100, erik wrote:
> Many thanks.  I think Openoffice suits my needs better so if nobody
> objects I'll start with that but I'll definitely get in touch if any
> Gnumeric work comes up.

I am not in a position to object as you're the one doing the work, but I'd
suspect that Gnumeric may be easier to pull of as there is a smaller
codebase (guess on my end, that).  

Plus, there is the option of going from QL via Python to Gnumeric and back
which would be a) useful, and b) maybe easier to setup and debug as both QL
and Gnumeric already talk to Python.

Either way, would be cool to have this.  My $0.02 for Gnumeric, but your call.

Cheers, Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[erik-44]

On Wed, 2004-04-07 at 21:34, Dirk Eddelbuettel wrote:
> On Wed, Apr 07, 2004 at 09:25:10PM +0100, erik wrote:
> > Many thanks.  I think Openoffice suits my needs better so if nobody
> > objects I'll start with that but I'll definitely get in touch if any
> > Gnumeric work comes up.
>
> I am not in a position to object as you're the one doing the work,

I'm new here and happy to go with the flow!  All feedback is welcome.

> but I'd
> suspect that Gnumeric may be easier to pull of as there is a smaller
> codebase (guess on my end, that).  
>
> Plus, there is the option of going from QL via Python to Gnumeric and back
> which would be a) useful, and b) maybe easier to setup and debug as both QL
> and Gnumeric already talk to Python.

100% agreed... but I wouldn't list convenience of
implementation/debugging as top priorities.  At this point I'm only
committing to do a prototype but I'd like to design something which at
least has the potential to evolve into an industrial strength desktop
spreadsheet pricer.  My main arguments in favor of Openoffice over
Gnumeric would be:
- Design and performance - with an OpenOffice C++ Addin you write
classes which are derived directly from the classes used to build OO
itself, and your code goes into a lib which OO loads dynamically at
runtime.  I've done no benchmarking but intuition tells me this design
is faster and cleaner than Quantlib<->Python<->Gnumeric.
- OpenOffice (and StarOffice) has a larger potential userbase, as it
runs on Linux/Unix/Mac/Windows as opposed to just Gnu

> Either way, would be cool to have this.  My $0.02 for Gnumeric, but your call.

Thanks very much for getting back to me and I welcome any feedback on my
comments.

> Cheers, Dirk

Cheers, Eric

[Dirk Eddelbuettel]

On Thu, Apr 08, 2004 at 12:00:11AM +0100, erik wrote:

> 100% agreed... but I wouldn't list convenience of
> implementation/debugging as top priorities.  At this point I'm only
> committing to do a prototype but I'd like to design something which at
> least has the potential to evolve into an industrial strength desktop
> spreadsheet pricer.  My main arguments in favor of Openoffice over
> Gnumeric would be:
> - Design and performance - with an OpenOffice C++ Addin you write
> classes which are derived directly from the classes used to build OO
> itself, and your code goes into a lib which OO loads dynamically at
> runtime.  I've done no benchmarking but intuition tells me this design
> is faster and cleaner than Quantlib<->Python<->Gnumeric.

Sure, but you get the same with directly loadable C plugins for Gnumeric, so
this would be a draw.  From a practical standpoint, it may be easier to mix
C and C++ (i.e. call the QL C++ code via '#extern "C"' mechanism, which I
what I do to get QL into the R environment) than mixing two distinct C++
beasts. I may well be wrong here.

> - OpenOffice (and StarOffice) has a larger potential userbase, as it
> runs on Linux/Unix/Mac/Windows as opposed to just Gnu

Gnumeric is said to be available on windoze "soon".  Any timelines, Jody?

Cheers, Dirk

--
The relationship between the computed price and reality is as yet unknown.  
                                             -- From the pac(8) manual page

[erik-44]

On Thu, 2004-04-08 at 00:18, Dirk Eddelbuettel wrote:

> > - with an OpenOffice C++ Addin you write
> > classes which are derived directly from the classes used to build OO
> > itself, and your code goes into a lib which OO loads dynamically at
> > runtime.  I've done no benchmarking but intuition tells me this design
> > is faster and cleaner than Quantlib<->Python<->Gnumeric.
>
> Sure, but you get the same with directly loadable C plugins for Gnumeric, so
> this would be a draw.  

I didn't know about C plugins for Gnumeric, this sounds distinctly more
promising than Quantlib<->Python<->Gnumeric.  Is this interface
documented anywhere?

> From a practical standpoint, it may be easier to mix
> C and C++ (i.e. call the QL C++ code via '#extern "C"' mechanism, which I
> what I do to get QL into the R environment) than mixing two distinct C++
> beasts. I may well be wrong here.

Very tough to say how a Gnumeric C plugin would compare to an OpenOffice
C++ Addin.  It would depend heavily on the design of each,  on your
criteria... the first approach might be better at some things and the
second at others... there are a lot of variables.

[Jody Goldberg-2]

On Thu, Apr 08, 2004 at 12:00:11AM +0100, erik wrote:
> - Design and performance - with an OpenOffice C++ Addin you write
> classes which are derived directly from the classes used to build OO
> itself, and your code goes into a lib which OO loads dynamically at
> runtime.  I've done no benchmarking but intuition tells me this design
> is faster and cleaner than Quantlib<->Python<->Gnumeric.

That would be true if you had to go through Python to get to Gnumeric.
We support external plugins in python, but the mechanism is straight
C.  The vast majority of our 500 odd worksheet functions are in
plugins.

> - OpenOffice (and StarOffice) has a larger potential userbase, as it
true.

> runs on Linux/Unix/Mac/Windows as opposed to just Gnu
We are days from a win32 build :-)

One of the reasons I joined the Gnumeric project was the irritation
of deploying analytics as an MS Excel's XLL, or even in Applix.
Gnumeric's plugin interface was designed explicitly to simplify
things like this.

Best of luck in your work,
    Jody

[Jody Goldberg-2]

On Thu, Apr 08, 2004 at 01:01:19AM +0100, erik wrote:
>
> I didn't know about C plugins for Gnumeric, this sounds distinctly more
> promising than Quantlib<->Python<->Gnumeric.  Is this interface
> documented anywhere?

There is documentation in
    gnumeric/doc/developer/writing-functions.sgml

Unfortuantely the recent security breach on gnome.org has forced the
sys admin team to disable most of the gnumeric web site so I can't
give you a web link right now.  However, I should note that the
majority of or functions are in plugins, so there are lots of
examples.

Here's an example of a simple one in
    gnumeric/plugins/fn-info/functions.c

static char const *help_isnumber = {
        N_("@FUNCTION=ISNUMBER\n"
           "@SYNTAX=ISNUMBER(value)\n"
           .... I'll abridge the help text in the interest of clarity

static GnmValue *
gnumeric_isnumber (FunctionEvalInfo *ei, GnmValue **argv)
{
        return value_new_bool (argv[0] != NULL &&
                (argv[0]->type == VALUE_INTEGER || argv[0]->type == VALUE_FLOAT));
}
 
An entry in the descriptor table
        { "isnumber", "B", N_("value"), &help_isnumber,
          gnumeric_isnumber, NULL, NULL, NULL, NULL,
          GNM_FUNC_SIMPLE, GNM_FUNC_IMPL_STATUS_COMPLETE, GNM_FUNC_TEST_STATUS_BASIC },

And an entry in the plugin's decriptor file 'plugin.xml.in'
    <function name="isnumber"/>

> Very tough to say how a Gnumeric C plugin would compare to an OpenOffice
> C++ Addin.  It would depend heavily on the design of each,  on your
> criteria... the first approach might be better at some things and the
> second at others... there are a lot of variables.

Definitely.  I suspect that Gnumeric will be significantly simpler
to use initialially, but OOo will have more power for manipulating
external objects like reports in wordprocessors via it's UNO
technology.   As you say it depends on your needs.  OOo is a suite
and has the capabilities that come with that, but my bet is that
Gnumeric is a better spreadsheet if you compare them head to head.

Then again, I'm biased.  I think my kids are cute too :-)

[erik-44]

On Thu, 2004-04-08 at 04:11, Jody Goldberg wrote:

I suspect that Gnumeric will be significantly simpler
> to use initialially, but OOo will have more power for manipulating
> external objects like reports in wordprocessors via it's UNO
> technology.   As you say it depends on your needs.  OOo is a suite
> and has the capabilities that come with that,

I'm not thinking so much of OOo as an office suite - things like
reports/wordprocessing would at best be nice-to-haves in a desktop
pricing environment.  Comparing Gnumeric to OOo Calc as a standalone
spreadsheet, I see the main points as -
1) supported platforms:
- OOo Calc - Linux/Unix/Mac/Windows
- Gnumeric - Gnome/Windows.
2) architecture/design:
- OOo Calc - C++ addins (implement bespoke classes which inherit jointly
from QL and UNO)
- Gnumeric - C-plugins (wrap QL classes in 'extern "C"')

> but my bet is that
> Gnumeric is a better spreadsheet if you compare them head to head.

That may well be true, and even if the point is open for debate, there
will always be users who prefer Gnumeric over OOo Calc.  The ideal would
be to support both platforms, and if the demand is there it will happen;
given limited resources my first choice would be OOo Calc based on the
considerations above.

I've succeeded in prototyping a QL Add-in for OOo Calc and this is now
functional for an American Option
(http://www.ehlers.plus.com/pricer/oocalcql.png).  I'm in the process of
porting QuantLibXL to OOo Calc and I'll post this code soon.  It's
turned out to be a simple exercise and I'm sure that someone familiar
with Gnumeric would be able to get a QL plugin online quickly.

> Then again, I'm biased.  I think my kids are cute too :-)

I'm sure they are, with no need for any bias on your part!

> Best of luck in your work,
>     Jody

Thanks very much, and I appreciate the feedback from you & Dirk.  I'm
open to change depending on what response the project gets, let's keep
in touch.

Best regards,
Eric

[Ferdinando Ametrano-3]

Hi all

sorry for being late in replying... QuantLib hottest week ever, isn't it?

QuantLib spreadsheet integration has always been an issue of high
importance to me. While the Excel integration was urgent because of the
Excel predominance in the financial arena I wouldn't rule out any
spreadsheet out there: Gnumeric, KSpread, OpenOffice, ecc.
I will be more than happy to provide help for any spreadsheet wrapper
project, including a dedicated CVS module in the QuantLib CVS repository
hosted by SourceForge.

Anyway I don't actual integration is the major issue: a "QuantLibFunctions"
interface design is the key and of course I think we should guarantee that
all spreadsheet interfaces share the same design. Unfortunately the
interface design of the current QuantLibXL module is quite poor.

The main issue we should tackle is the creation of a persistent object
handler which would allow to create objects (Yield Term Structures, Vol
Term Structures, Instruments, etc) with an associated label, so that the
user can refer to them in any spreadsheet with no need to re-build them in
every workbook. Without such a feature I forecast the nightmare of pricing
functions with many dozens of input arguments.

While crucial for the spreadsheet design the object handler might be
probably used by other application wrappers too: MatLab, Mathematica, R,
etc. Am I right?

Besides the object handler it would be nice if the function signatures
could be shared by all application wrappers (not just the spreadsheet) as
much as it is compatible with each application style.

In order to have a central code repository for this new QuantLibFunctions
library, the ql\function folder has been removed from the QuantLib library.
A separate library has been created under functions\ql\Functions where
further development will take place. I would suggest that anyone
considering a (spreadsheet) wrapper would check out the current QuantLib
CVS and start by wrapping the QuantLibFunctions library.

I look forward to comments and contributions.

ciao -- Nando

[Jody Goldberg-2]

On Tue, Apr 13, 2004 at 06:18:32PM +0200, Ferdinando Ametrano wrote:
>
> Anyway I don't actual integration is the major issue: a "QuantLibFunctions"
> interface design is the key
agreed.

> and of course I think we should guarantee that
> all spreadsheet interfaces share the same design. Unfortunately the
> interface design of the current QuantLibXL module is quite poor.
It did seem a bit haphazard.

> The main issue we should tackle is the creation of a persistent object
> handler which would allow to create objects (Yield Term Structures, Vol
> Term Structures, Instruments, etc) with an associated label, so that the
> user can refer to them in any spreadsheet with no need to re-build them in
> every workbook. Without such a feature I forecast the nightmare of pricing
> functions with many dozens of input arguments.

I'm not sure I agree.  Historicly I've seen that sort of
interoperability handled in the backend, persisting the
curves/surfaces to a db and reloading.  It would also create some
odd dependancies.
    - workbook1 holds the market data for curve id="FOOO"
    - workbook2 uses named curve "FOOO"
There's nothing that ties them together at the spreadsheet level,
and things would break if just workbook2 was reloaded.
 
Getting all the market data and associated instrument conventions
into the bootstrappers was always a sore spot for me.  Every trader
wanted their own magic quotes for things.

> While crucial for the spreadsheet design the object handler might be
> probably used by other application wrappers too: MatLab, Mathematica, R,
> etc. Am I right?

Agreed.

> Besides the object handler it would be nice if the function signatures
> could be shared by all application wrappers (not just the spreadsheet) as
> much as it is compatible with each application style.

That would certainly simplify things when persisting.  Exporting to
xls is complex enough without having to map function
arguments/names.  If we had to start considering OOo xls vs MS xls
because they had different QL functions life would get very messy
very fast.

While I'd love to contribute to the project, Gnumeric absorbs all
available free time.  Hopefully I can at least make a few
suggestions though :-)

[Jody Goldberg-2]

On Sun, Apr 11, 2004 at 12:52:09PM +0100, erik wrote:
> 1) supported platforms:
> - OOo Calc - Linux/Unix/Mac/Windows
> - Gnumeric - Gnome/Windows.
  - Gnumeric - Linux/Unix/Windows.

The only real difference here is Mac.

> 2) architecture/design:
> - OOo Calc - C++ addins (implement bespoke classes which inherit jointly
> from QL and UNO)
> - Gnumeric - C-plugins (wrap QL classes in 'extern "C"')

true
I'm not sure that is a huge simplification, but I'll agree that it
is a difference.

> > but my bet is that
> > Gnumeric is a better spreadsheet if you compare them head to head.
>
> That may well be true, and even if the point is open for debate, there
> will always be users who prefer Gnumeric over OOo Calc.  The ideal would
> be to support both platforms, and if the demand is there it will happen;
> given limited resources my first choice would be OOo Calc based on the
> considerations above.

Agreed.  As posted elsewhere the key goal should be defining a
worksheet interface.  The actual wrappers aren't hugely difficult.

[mrtreibe]

On Apr 13, 2004, at 4:12 PM, Jody Goldberg wrote:

> On Sun, Apr 11, 2004 at 12:52:09PM +0100, erik wrote:
>> 1) supported platforms:
>> - OOo Calc - Linux/Unix/Mac/Windows
>> - Gnumeric - Gnome/Windows.
>   - Gnumeric - Linux/Unix/Windows.
>
> The only real difference here is Mac.
>

Actually both OOo Calc and Gnumeric are available through X11 on the
Mac.  I believe that OOo is available from their website and Gnumeric
is available through fink (1.0.13 in stable and 1.2.5 in unstable).  
OOo won't have native Quartz and Aqua versions until (according to
their mac port website) late 2005/early 2006.

Mark.

[erik-44]

On Tue, 2004-04-13 at 17:18, Ferdinando Ametrano wrote:

> I don't actual integration is the major issue: a "QuantLibFunctions"
> interface design is the key and of course I think we should guarantee that
> all spreadsheet interfaces share the same design.

Agreed, the addin implementations are relatively trivial and their
design is dictated by that of the interface.

> The main issue we should tackle is the creation of a persistent object
> handler which would allow to create objects (Yield Term Structures, Vol
> Term Structures, Instruments, etc) with an associated label, so that the
> user can refer to them in any spreadsheet with no need to re-build them in
> every workbook. Without such a feature I forecast the nightmare of pricing
> functions with many dozens of input arguments.

Yes.  QuantLibXL only exports a list of functions; a desktop pricing
spreadsheet would benefit from a consolidated interface to the
analytics, and support for persistent objects.

> I look forward to comments and contributions.

I'd be interested in wrapping QuantLibFunctions for Calc, I'd be happy
to help with an Excel Addin as well, the two APIs are similar and the
addins could use identical designs.

> ciao -- Nando

Regards
Eric

[Bob Lewis-2]

Gnumeric is the correct way to proceed. God luck

Bob Lewis
Senior Recruiter

MIS Consultants
55 Eglinton Ave East, Suite 701
Toronto, Ontario
M4P 1G8
Phone: [phone], Ext.243
Fax: [phone]


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Jody
Goldberg
Sent: Wednesday, April 07, 2004 11:20 PM
To: erik
Cc: Dirk Eddelbuettel; [hidden email]
Subject: Re: [Quantlib-users] quantlib spreadsheet integration

On Thu, Apr 08, 2004 at 01:01:19AM +0100, erik wrote:
>
> I didn't know about C plugins for Gnumeric, this sounds distinctly
more
> promising than Quantlib<->Python<->Gnumeric.  Is this interface
> documented anywhere?

There is documentation in
    gnumeric/doc/developer/writing-functions.sgml

Unfortuantely the recent security breach on gnome.org has forced the
sys admin team to disable most of the gnumeric web site so I can't
give you a web link right now.  However, I should note that the
majority of or functions are in plugins, so there are lots of
examples.

Here's an example of a simple one in
    gnumeric/plugins/fn-info/functions.c

static char const *help_isnumber = {
        N_("@FUNCTION=ISNUMBER\n"
           "@SYNTAX=ISNUMBER(value)\n"
           .... I'll abridge the help text in the interest of clarity

static GnmValue *
gnumeric_isnumber (FunctionEvalInfo *ei, GnmValue **argv)
{
        return value_new_bool (argv[0] != NULL &&
                (argv[0]->type == VALUE_INTEGER || argv[0]->type ==
VALUE_FLOAT));
}
 
An entry in the descriptor table
        { "isnumber", "B", N_("value"), &help_isnumber,
          gnumeric_isnumber, NULL, NULL, NULL, NULL,
          GNM_FUNC_SIMPLE, GNM_FUNC_IMPL_STATUS_COMPLETE,
GNM_FUNC_TEST_STATUS_BASIC },

And an entry in the plugin's decriptor file 'plugin.xml.in'
    <function name="isnumber"/>

> Very tough to say how a Gnumeric C plugin would compare to an
OpenOffice
> C++ Addin.  It would depend heavily on the design of each,  on your
> criteria... the first approach might be better at some things and the
> second at others... there are a lot of variables.

Definitely.  I suspect that Gnumeric will be significantly simpler
to use initialially, but OOo will have more power for manipulating
external objects like reports in wordprocessors via it's UNO
technology.   As you say it depends on your needs.  OOo is a suite
and has the capabilities that come with that, but my bet is that
Gnumeric is a better spreadsheet if you compare them head to head.

Then again, I'm biased.  I think my kids are cute too :-)


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users