Читать книгу Modern Computational Finance - Antoine Savine - Страница 14

Our library, discussed in part I and 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.