In my previous post, I said that C++, as a language choice for the implementation of an analytics library, is effectively mandated by the industry's expectations of high performance. In reality, well-written C++ can be very efficient, but it has to be well-written. The object model of C++ lets us cope with the ever increasing complexity of the calculations required to solve modern quantitative problems, through abstraction and all the other goodness that is object-oriented programming. So far so good.
The spanner in the works is thrown from the higher levels of the application stack - where is the analytics library called from? When embedded in an application, the answer could be C++, but could equally be Java or C# or similar. But on the desktop, in our industry, the answer is almost always "Microsoft Excel", although MATLAB and Python are also there.
The challenges arising from supporting application development on multiple platforms and in multiple languages and environments are non-trivial. Here is a sampling from the list: ABI (in)compatibility, regression testing, transparency and auditing, persistence, distributed computing, API extensibility and the provision of technical support. Over the next couple of posts I am going to examine the design requirements placed on an interface to a core analytics library implied by the need to solve all these problems.
But for now, back to Excel. Excel is not an object-oriented environment. It knows about grids of variants - a datatype that can essentially hold a number, a character string, a boolean (true/false) or be empty. It doesn't know and can't be told about any higher-level concept like "pricing model" or "term sheet", yet concepts such as these (as you shall see in later posts) are central to what's going on in the core library.
So what to do? Must we keep the objects internal, hiding them entirely? We'd then have to use an interface of (tables of) numbers, strings and bools, that asks for all the data required to perform a calculation up front and spits out the final result. This would be a pity, if so. Those concepts exist because they are useful and by hiding them we'd be losing out.
It turns out that we don't have to hide them, as long as we implement some form of handle mechanism. For example, we might require that when a new object is constructed, the user supplies a character string which is used to access the object and instruct other parts of the library to use it. In other words, the user would give objects names.
Not all objects would have names, only those exposed to the user. The fundamental structure to manage such names is a collection of maps of user handle (the name for the object) to internal handle (a smart pointer to the object). This idea is not new, but it is a necessary aspect of life for an object-oriented library called from Excel.
You can see an early example of this kind of idea in the ISDA CDS Standard Model.
