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

Valuation and pre‐processing are two ways in which we visit scripts. Other types of visits include queries, which provide information related to the cash flows, for instance the identification of non‐linearities; or transformations, like the aggregation and compression of schedules of cash‐flow; or decorations, which complement the description of the cash‐flows with the payoff of some value adjustment, as explained in part V. And there are many, many others. There is a visitor for everything.

Visitors are all the objects, like the evaluator and the pre‐processors, that traverse scripts and conduct calculations or actions when visiting its different pieces, while maintaining an internal state. Their internal state is what makes visitors so powerful. It is through their state that visitors accumulate and process information while traversing scripts. Internal state does not mean that visitors cannot be invoked concurrently. In fact, parallel scripting is easily implemented with multiple visitor instances working in parallel in multiple concurrent threads. The scripting library is thread safe as long as common‐sense rules are respected; for example, do not perform parallel work with the same instance of a visitor class.

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 ⁸ 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.