Re: [Quantlib-dev] QuantLib Forum

[Bojan N. <bo...@bn...>]

Hi Eric,

Eric Ehlers <eri...@na...> writes:

>>>> In fact thinking now about this, I see there could be a nice shortcut in
>>>> enabling this: write the Excel interface in Python. This would allow the
>>>> work to concentrate on the C++ -> Python SWIG wrapper, and Python
>>>> modules could then quite easily re-wrap this functionality for
>>>> Excel. This would also have the added advantage that a lot of
>>>> higher-level functionality could be in Python but still easily
>>>> accessible from Excel.  What do people think about this?
>>>
>>> I think the Excel-Python interface looks interesting and could have
>>> useful applications but it would not be my choice for the QuantLibXL
>>> architecture.  Excel's C API, while obscure, is mature and robust and
>>> remains the fastest way to access Excel's internals.
>>
>> I was thinking of actually using Python packaged into a DLL and
>> accessing directly Excel's C API. So you get the benefits of using
>> Python (and SWIG-ed QuantLib in this case) combined with the
>> traditional Excel C interface.
>>
>> Perhaps surprisingly, this works really quite well and enables direct
>> interaction with Python quite easily. We've used it in a project and it
>> worked very well. There is a little spin-off example at
>> http://www.bnikolic.co.uk/expy/. There is also another project with code
>> available at http://code.google.com/p/pyinex/downloads/list.
>
> I'll have a look at the examples as soon as I can.  For now let me
> request a quick clarification:  Under this proposed new design, would
> it be possible to invoke existing QLXL functionality on a machine
> where Python is not installed in any shape or form?

Yes, but only because the Python interpreter would be statically linked
into the add in.

> I would hesitate to move to any design where the answer to that
> question is no.  At present the crux of our architecture is:
>
>     QL -> XL API -> EXCEL
>
> Adding any other component into that mix would be guaranteed not to
> speed things up and I would certainly have reservations about having
> the Python interpreter on our critical path when calculating a price.

Well I was suggesting writing the XL API in Python, so yes, there would
be an additional overhead of a Python layer. In practice these overheads
are small and not noticeable unless one tries to do very fine-grained
calculations from Excel. I think this overhead would be more than offset
by the ability to remove certain portions of calculations entirely from
Excel and have them in the Python layer. 

Best,
Bojan

-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk