Blog

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

A family member recently asked me the specifics of a few different life insurance policies and it got me thinking about the metamorphosis the insurance industry has undergone globally the last few years and how it came about. It is really quite remarkable. We have gone from an insurance industry operating in the status quo of managing specific asset or liability allocation pieces in relative