|Please add categories to help Wikiversity participants find the resource or ask people to help.|
Design specification on building an open source infrastructure for financial visualization. Installation instructions for the demo are available
source code is located at 
Why open source? 
The wish - If we keep this closed source, we can make a lot of money and get a competitive advantage
The reality - Closed source implementation commit a company to make massive investments to keep a system running which duplicated functionality found elsewhere, often very badly.
Always ask, are we in the ..... business? Most finance companies are in the algorithm business and not in the GUI infrastructure/computer language/database maintainence/programming tool business.
You close it, you maintain it.
The Pieces 
- QuantLib - financial analysis
- VTK - 3-d graphical output
- Python TraitsUI - controller
- Nokia 800
Other traps 
- Letting infrastructure drive implementation rather than the other way around.
- Making the infrastructure too abstract
Design paradigm 
Start with specific needs. Find open source packages that almost fit those needs. Modify the open source packages so that they do.
Example Applications 
- Visualize volatility surface in conjunction with real data to see if how close the surface matches the data. Optimization will give you the closest parameter match, but without visualization techniques, you have no idea whether the match makes sense across the entire surface.
- Sanity checks. You've calculated the solution to a derivatives pricing problem. Does this solution make sense? Are there numerical issues (i.e. noisy output, singular points).
- Qualitative descriptions - How do you characterize the behavior of the derivative price or Greeks in words?
- Presentations to non-technical audiences. - Make points to people who are non-technical specialists.
Basic framework 
- model, view, controller
- model - QuantLib
- view - Mayavi2 + can possibly add 2-d plots with Chaco
- controller - Enthought Traits for parameter controller. Wiimote (?!!!) for visualization.
Scripting language (Python) for rapid application development + C++ for building blocks
Why Python - Because there is already support for scientific computing via numpy and scipy.
Toy application 
Calculate basket option values for min, max, average options while varying underlying. Use monte carlo for NPV calculations.
What's needed - Lot's of duct tape 
Pieces already there 
Connect QuantLib with python using SWIG wrapper generator
Connect QuantLib with MayaVi2 
Both are Python applications. Right now uses python for surface rendering
Pieces being developed (duct tape) 
Plotspace View 
Problem - mayavi2 was built for CFD and medical imaging. These have homogenous scales. But finance has hetrogenous scales. Need an API for converting "plot coordinates" to "world coordinates"
Problem - Equations take a long time to calculate. Need to put computational infrastructure to support multi-threading
Status - Minimal implementation there.
Traits controller 
Problem - Need to be able to edit the parameters of the model
Status - Try to figure out how to do this
Data Frame 
Problem - VTK and visualization systems were designed to handle either arrays or unstructured 3-d data (imaging and CFD background). But financial data is usually multi-dimensional time indexed data with attributes associated with columns and with the data as a whole.
Solution - Implement something like R data.frames
Status - Basic implementation there. Right now road block is implementing database joins. (Simple, just need the time to do it).
Note - The data frame unifies some of the basic tools in finance - The spreadsheet and the database
QuantLib surface interface 
Problem - Need standard interface to retrieve surface and volume data from QuantLib
Solution - Implement surface interface. Example of implementation of Surface interface would be time indexed curves.
Wiimote interface 
Problem - Control view more naturally than with mouse
Solution - Use wiimote - This is actually straight foward. Wiimote uses bluetooth and protocol has been reverse engineered. Hardware is cheap. Map wiimote calls to mouse actions in controlling mayavi
Impedence mismatches 
Classic problem with system integration are bad joints. Need to think about deep integration issues while we are in duct tape mode.
1) How do we integrate Traits event model with QuantLib event (observer model)?
2) How do we connect QuantLib arrays with numpy arrays?
3) What do we do about econometric time series analysis?
4) How do we connect the structured objects (i.e. surfaces) within QuantLib to the outside?
Why this needs to be open source 
No proprietary information. No complete application. Just lots and lots of duct tape.
Danger of proliferation of API's and implementation. You close it, you maintain it.