Posted by
Bojan Nikolic on
Jan 24, 2011; 8:19am
URL: http://quantlib.414.s1.nabble.com/QuantLib-Forum-tp12384p12389.html
Hi Eric,
Eric Ehlers <
[hidden email]> 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------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev