Antoine Savine - Modern Computational Finance

To make visits possible, we make our scripts visitable . This means that we parse them into a data structure that is designed to be traversed in flexible ways. That data structure is the expression tree discussed in detail, in words and code, in chapter 2. Trees and visitors are the main building blocks of our scripting library.

One key benefit of the visitor pattern is that it facilitates the support of processes that we haven't even thought of yet. Our visitor‐based design caters for needs that will emerge in the future, and enables future development.

For example, we in 2016 worked out an algorithm to automatically smooth all the discontinuities in a transaction in order to stabilize its risk management. This algorithm is based on fuzzy logic and described in detail in part IV. It so happens that an implementation of this algorithm requires the determination of the value domain of all the conditional cash‐flows, which means, for every condition of the type , or 8 involved in a script, what is the set of all possible values for at that point? We designed a visitor to figure that out: the DomainProcessor in scriptingDomainProc.h.

As another example, we were able to significantly improve the performance of LSM regressions for large xVA calculations by pre‐computing the entire dependency graph of the many thousands of variables involved in the aggregated script for a large netting set. That allowed us to selectively evaluate, during pre‐simulations, only those events that affected the target variable, saving many unnecessary evaluations. And it was relatively straightforward to design a visitor to produce that complete dependency graph.

The visitor‐based design provides a framework for the seamless development of any kind of visitor, now and in the future. The visitor‐based class designed in section 3.1 takes care of the traversal and visit logic so that a concrete visitor is developed simply by specifying what it does when it visits different nodes in the tree. For instance, the variable indexer developed in section 3.3 takes less than ten lines of code despite the apparent complexity of its work. This visitor effectively counts the variables in a script and matches them to an index in an array.

Our library, discussed in part Iand provided in our source repository, is designed to facilitate the visit of scripted cash‐flows with a convenient internal representation of scripts and a framework for visiting these representations. It revolves around two concepts:

1 Expression trees are our internal representation of the scripts in visitable data structures, produced from text scripts through parsing.

2 Visitors are the objects that traverse the expression trees, maintaining their own state during traversal, extracting information, performing calculations, or even modifying the trees along the way.

Expression trees are covered in chapter 2. Visitors are covered in chapter 3, including the evaluator in section 3.6 and some important pre‐processors in 3.3 and 3.4. Parsing, which turns scripts into expression trees, is covered in the appendix to part I.

We develop our scripting library in self‐contained C++. Other implementations attempted to reuse existing programming languages, like Python, Visual Basic, or C#, to code payoffs instead. In this context, the model, typically written in C++, would generate scenarios and delegate the evaluation of payoffs in given scenarios to code written by users in a simpler language. This is attractive at first sight: it saves developers the trouble of implementing a scripting library, and users the trouble of learning it. It offers the power and versatility of a general purpose programming language for the computation of payoffs, providing maximum flexibility in return for a somewhat increased operational risk. The main problem, however, is that it only works for valuation. Python scripts don't describe cash flows; they evaluate payoffs. From the point of view of the C++ code, they are black box functions that can only be executed, not visited. They cannot be pre‐processed, queried, or transformed. Such a framework may have merit for the risk management of exotics (if performance and operational risk are not an issue), but it is not suitable for our purpose. This is actually the exact opposite of our design, whose purpose is to provide a representation of cash‐flows that is transparent to all kinds of visitors across a system.

We also made the choice to develop a self‐contained implementation in standard C++11. We find it unnecessary to recourse to third‐party libraries to parse, represent, or visit scripts. Self‐contained code offers better control over the algorithms and makes it easier to maintain and extend the code without having to rely on another party. Further, automatic adjoint differentiation (AAD), a technique used to obtain derivative sensitivities with amazing speed, is best implemented when the source code is available. This in itself is reason enough to refrain from using third‐party black boxes. Furthermore, once the fundamental designs and algorithms are well understood, it is natural and relatively painless to produce elegant, efficient, self‐contained C++ code, especially with the modern facilities offered by C++11. In particular, we demonstrate in the appendix to section I that the parser (part of the code that turns text scripts into expression trees) is implemented in standard C++ without major difficulty or the recourse to a third‐party library. The source code is provided in our repository.

AAD is covered in detail in our publication [27], together with professional C++ code.

Scripting languages are designed to facilitate the description of any derivatives transaction, and, indeed, all transactions must be scripted to benefit from a common representation within a derivatives system. That means that the pricing, booking, and otherwise manipulation of every transaction, down to vanilla swaps and European options, is conducted with scripts. Traders typically manipulate hundreds to thousands of vanilla swaps or European options every day. Although modern scripting is accessible and user‐friendly, it is still much easier, faster, and less error prone to fill a few fields on a form, like start and end dates, and a fixed coupon for a swap, than to write a script like:

For those frequently traded products, it is practical to use templates , implemented on spreadsheets or higher level languages, that generate the script automatically out of a small number of inputs.