The feature that most sets TREE apart from any other trading software is the fundamental structure of the system. Careful, forward-looking design makes TREE extensible and adaptable in many ways. Here we describe some of the design principles that make this so.
One fundamental principle of TREE is hierarchical structure. TREE trading systems are constructed by assembling groups of reusable blocks, which the user selects and connects together in schematic block diagrams. A completed schematic can itself be used as a block in a larger schematic (see Figure 1). Many different standard block types are provided, with functions ranging from simple addition to complex signal-analysis algorithms ( Figure 2). The user can combine such blocks into composite blocks, building up even more complex behaviors --- which can then be manipulated as if they were elementary blocks. In this way, even extremely complicated trading systems can be constructed in an intellectually manageable fashion.
As an example of the power of this approach, it is possible to build, test, and refine several different trading strategies, such as a trend follower, a cyclic model, and a breakout model. Then these individual trading strategies can be combined into an ``asset allocation'' super-system, in which a higher structural level allocates varying levels of assets to the individual traders according to their recent performance. By combining a range of trading strategies, such a super-system can adapt to a wide range of market conditions. Yet the individual strategies can be built and tested independently, and even the outer control logic can be built without any specific assumptions about the member strategies. (For more details see Asset allocation.) Designing, testing, and understanding such a complex system would be far more difficult without the aid of hierarchical structure.
Another example: because a completed, executable trading system can be an element of a larger assemblage, the larger assemblage can control the execution of that trading system. In particular it can cause the trading system to be executed repeatedly over the same historical interval with different parameters. Thus, automatic parameter optimization can be done easily; so easily that it is not even a built-in system function, but something that one can assemble out of spare parts. A user-modifiable script determines which aspects of the tested system's performance are monitored, how the space of available parameter values is explored, and so forth. In most other trading software systems, parameter optimization is either not possible at all, or is a built-in function whose behavior is not open to user inspection and modification.
Because of the hierarchical structure, a user can work with TREE at several different levels of sophistication, gaining power and flexibility as he learns more about the system. Ways of using TREE include:
One reason that we chose Berkeley's Ptolemy software as the basis for TREE is that the core Ptolemy software supports multiple domains, or ``models of computation''. Although Ptolemy is built on the notion of hierarchical collections of blocks, it makes very few restrictions on the behavior of those blocks. To construct a set of blocks that can work with each other, one must define a communication protocol that the blocks agree on. The protocol does not say what the functions of the individual blocks are, it just establishes the ground rules that let the blocks cooperate. A protocol and a collection of blocks that obey it are called a domain. Ptolemy supports many different domains.
TREE itself provides a domain called TS (Timed Simulation) that is specialized for describing real-time trading systems. In TS, messages (called events) pass between blocks, following the schematic connection lines drawn by the user. A block ``fires'', or gets a chance to do something, whenever an event arrives at any of its input ports. During a firing it can choose to emit more events through its output ports, thus triggering other blocks. Each such chain of events is started by the arrival of new data from outside the system --- a new tick from a realtime datafeed in live trading, or the next price from a historical database when testing. To support historical testing, each event is labeled with a timestamp indicating the time at which it nominally happened. (During live trading, the timestamp marches in step with the true real time.) This protocol provides a very direct model of making calculations and trading decisions in real time, on the basis of data available up to the current moment. The system is designed so that during historical testing, blocks are not allowed to see database prices later than the current simulated instant; thus there is no possibility for ``looking into the future'' errors, which are easy to make and hard to detect in less carefully structured systems.
The Berkeley Ptolemy distribution includes several other domains that may also be useful for trading system development. One that is very different from TS is the FSM (Finite State Machine) domain: in this domain, each block represents a state of the system, and the interconnections between blocks represent possible transitions between states. Each state block can define the overall behavior of the system that occurs while that state is active. The FSM schematic defines the conditions that cause transitions between states.
A completed system can be built from subsystems that belong to different domains. (For example, when using FSM, the behavior of each individual state is often defined by a subsystem belonging to some other domain, since FSM itself can't express anything except state transition rules.) In this way it is possible to solve different parts of a large problem using notation and tools appropriate for each part.
Thus, as flexible and effective as TS domain is for TREE's purposes, it need not be our only toolbox. We expect that we will ultimately develop additional domains that address problem areas other than real-time trading. An example of a financial problem that doesn't fit the TS framework very well is searching through all available equities to select a stock portfolio meeting specified criteria. The passage of time isn't a critical aspect of this problem. Hence, while one could imagine developing a set of block types that are helpful for solving this class of problem, TS probably isn't the right communication protocol for them. A new domain specifically tailored for this class of problem would be a large project, but could be well worth the effort. (It's worth remarking that such a search domain might well be controlled by an outer TS schematic, which would re-execute the search domain subsystem at intervals reflecting how often the user wants to update the portfolio. The TS schematic would also keep track of trading profits and losses. In this way TS can be used to handle the things it's good at, without having to force all aspects of the system into the TS notation.)
While developing a new Ptolemy domain is not a small task, it is much easier than constructing an entirely new software system from scratch, because we can reuse a tremendous amount of Ptolemy infrastructure. We feel that so far the TREE project has barely scratched the surface of what can be achieved within the framework we have available.
Tycho, an ongoing research project within the Ptolemy group at Berkeley, is aimed at building user interface infrastructure that's as flexible and extensible as the core Ptolemy system. Their goal is to support multiple user interaction methods, with much the same philosophy as Ptolemy's support for multiple computational domains.
This project is new and far from complete --- indeed, the current Ptolemy block-diagram editor is ancient software that's not at all user-friendly by modern standards. But it will soon be replaced by a much better Tycho-based editor. SSS expects to be able to leverage the Tycho work to build all sorts of interactive displays, data visualization tools, and so forth with only modest effort. In fact Tycho should make it practical for users of TREE to construct customized display tools of their own.
The Ptolemy group at UC Berkeley has a Web page at http://ptolemy.eecs.berkeley.edu/. This is a good source for general information about Ptolemy and Tycho. Their page of info about other commercial uses of Ptolemy is particularly interesting as a hint of the potential flexibility of Ptolemy.
Overview documents available from Berkeley's website include:
Copyright 1997, Structured Software Systems, Inc.