Blog

A recent article in Risk magazine did a great job of pointing out one of the cases where new regulations, with the flick of a pen, are causing widespread market change, many times with unintended consequences. One of these recent proposals coming out of regions of Europe is the introduction of a new interest rate curve construction methodology to be used at pension funds that affects the longest

While an "XML-in XML-out single pipe" approach has several advantages that make it a good choice for a core library, it is not the way most of us like to code. We don't want to create and parse XML every time we make a call. So we should write something to do that for us. Our ideal representation of a function call depends on where we are working. In Excel it is functions in an XLL, registered

In my last post I described an XML-in XML-out API with just one function in it, called call_function. I also gave a list of engineering challenges that need to be met if we are to leverage the full power of object-oriented design in analytics systems. Let's go through each in turn and throw couple more in for good measure, seeing how a call_function approach to a core library API addresses these

In an earlier post in this series, I listed a few problems which go with the territory of building cross-platform object-oriented libraries in general, and some with C++ in particular. Here they are again: ABI (in)compatibility, regression testing, transparency and auditing, persistence, distributed/multi-process computing, API extensibility and the provision of technical support. In my previous

Supercomputers today don't have fast processors, they have many processors. Any modern high-performance system must address the problem of distributing its calculations over multiple cores within a machine and across multiple machines across a network. The transport of simple data types (numbers, character strings, Booleans etc) is trivial. But when objects are used to represent real life (and