February 1, 2008
So I’ve had a little play with Resolver One, now that it’s out of beta and at 1.0. To give a somewhat simplistic view, it’s an Excel clone implemented in IronPython. Where it scores big over Excel is in exposing its internals, specifically the calc model and worksheet in one seamless view. In Excel, we have several different APIs for injecting our own logic into a spreadsheet: Excel’s own internal C API for coding XLLs, VBA and COM. Those APIs allow us to express worksheet functionality in C, VB and any COM language. Resolver gives us one seamless view of its internals in our favourite programming language: Python. Simple example here.
This is attractive for those of us already using Python for front office systems. I’m not sure how much it will appeal to others though…
September 28, 2007
Excel is unavoidable for anyone working in front office trading systems. Front office support teams often bemoan the hassle of supporting myriad sheets, all a spaghetti mixture of various internal and external plugins and trader coded VB. Whole lines of business get built on spreadsheets, and replacing them with robust apps soaks up many developer years.
But spreadsheets will always be on the trading floor, no matter how hard IT may try to eliminate them. The reason is simple: Excel is the traders’ preferred development platform. Yet at the same time, it’s a general purpose tool, quite ill suited for trading apps. I’ve long thought that a determined start up could make a killing by building a better spreadsheet for the trading floor.
Being a long time Pythonista, and just recently dipping my toes in the water with IronPython for desktop etrading apps, I was excited to discover Resolver Systems. The Resolver is an IronPython .Net based spreadsheet that supports injection of Python scripts. I hope the Resolver guys are thinking about multi threading and serverisation as well as integration with existing .Net based Excel addins. Multi threading and server side capability would allow serverisation of trader coded pricing, and support for existing .Net addins would enable Resolver sheets to plug into market data infrastructures etc.
Good luck to the Resolver guys ! I’m very happy to see a promising startup furthering the cause of Python on the trading floor.
March 25, 2007
So if you’re building an XLL in VC8, and you’re using a .def file to specify the exported symbols, make sure you give the linker a /DEF:myaddin.xll switch. Unlike the VC6 linker, VC8 doesn’t automatically pick up the .def. Took me a good few hours to figure that, using depends and filemon to look for missing dependencies etc. All the time depends was telling me that my XLL was exporting no symbols, but I couldn’t see it, so fixated was I on more subtle possible problems.
September 26, 2006
Sparklines is a visualisation technique I’ve been following for a while – so I read this with interest. And then something else on cmiles blog caught my eye: a link to Juice Analytics. They have a nice blog on Excel hacks, which mentions a toolkit that gives you sparklines in Excel. Not the same Juice as founded by Charles Ferguson who wrote High Stakes – probably the best book I’ve read on founding a software start up.
September 22, 2006
Thanks to Vince for this Matlab/Python/R crib sheet. It’s good to see the three way equivalence, especially since I’m an old hand with Python and an R newbie. Matlab is the tool of choice on our trading floor for traders who’ve hit the buffers with Excel.
August 1, 2006
Just got an email from MS referring me to the presentations from last Tuesday’s Office 2007 presentation at the Credit Suisse offices. Paul Foster’s session on Excel Services is worth checking out…
August 1, 2006
I’m doing some data analysis at the moment, and I’ve gone through some toolsets in search of a combination that will give me power, expressiveness and charting capability. The raw data comes out of our trading system’s RDB. I started off with SQL queries, but soon found the slowness of complex queries and the arcana of SQL was holding me back. So I exported the data as CSV and set to work with Excel. I made some more progress, but didn’t want to resort to VBA for the ad hoc slice and dice coding. So then I switched to processing my 300Mb CSV with Python. Progress was good for a couple of days, but then my script started to get hairier. The data extraction and cleansing logic was all mixed up with the analysis logic. And I still didn’t have any good charts. Back to the drawing board. I vaguely remembered folk on Victor Niederhoffer’s mailing list discussing R. I checked out the programming recommendations on the great man’s site. So I downloaded R, and after 30 minutes playing, I’m very impressed. Scripting, powerful maths, built in vector and matrix data types, and flexible charting all rolled together. I’ll be asking around on the floor to see if any of our traders are using R…
July 28, 2006
A couple of emails with Paul have reassured me that live pricing sheets driven by real time market data and hosted by Excel services will be possible. The solution is to code an RTD server that uses Excel’s web services API to kick off a recalc that will pull in the new data. Hope the managed code required by Excel Services doesn’t introduce too much latency.
July 27, 2006
I went to the Office 2007 event at Credit Suisse on Tuesday night. Jim Burns, CTO financial services Microsoft UK opened the event. A CSFBer called Leslie spoke for a few minutes. He announced he worked for R&D in CSFB, that they identified emerging trends for the next 3 to 5 years, and that virtualisation and MS Office 2007′s distributed work features were the coming things. Then Ian Moulster, Product Manager for the Dev & Platform Group in MS UK spoke briefly. Then finally, we got the meat in the sandwich, an hour long presentation by Paul Foster, Developer Evangelist on Excel Services and InfoPath.
Excel Services is based on Sharepoint, which seems to provide some app server like hosting of the all new Excel Server calculation engine. Excel Server hosted worksheets can be rendered in a browser, and support interaction using AJAX techniques. Excel Server hosted worksheets can be invoked programmatically from a client using a web services API too. Paul alluded to XLLs a couple of times. I asked him about them afterwards. From the Excel 12 blog, it looks like C/C++ XLLs on a client Excel will be similar. However, a server side XLL, running under Excel services, must be managed code, though unmanaged code can be wrapped. When I asked Paul about injection of real time data into a server side worksheet, he indicated that my DDE based technique wouldn’t work for Excel services, as Windows permissioning would disallow it. And now the cumgranosalis blog tells us that RTD doesn’t really work for Excel services.
Why is this a problem ? It’s not unknown for traders to implement ad hoc pricing engines in Excel. I’ve worked on an Excel based system that autoquoted exchange traded option strategies. The recalcs were driven by a real time feed of futures prices – the future being the underlying for the options. We injected the futures price with DDE. It’s looking like it won’t be possible to implement this kind of system with Excel services, which is a great pity.
June 15, 2006
I’ve mentioned before how precious screen real estate is on the trading floor. One of the things traders alway have running is their Bloomberg terminal. Unlike us coders, they won’t have web, email and chat clients consuming that precious screen space. Bloomberg does email and chat anyway. Consequently, when a trader wants to publish some stuff to their colleagues on the floor, they’ll want to publish it on Bloomberg. That stuff may be some indicative quotes or valuations.
Alongside their Bloomberg, traders will always have Excel running. So we support their publication requirements with an XLL that can send an Excel worksheet to a Bloomberg GPGX page. That’s a GPGX, not a GDCO, which is for executable quotes. One click of a button and the trader’s free formatted sheet is out there on Bloomberg. Result: happy trader.
One consequence of this is that as an org, we are ever more locked into those Bloomberg fees: a grand a month for a terminal.