Re: quantlib spreadsheet integration

Posted by Jody Goldberg-2 on
URL: http://quantlib.414.s1.nabble.com/quantlib-spreadsheet-integration-tp2880p2893.html

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 :-)