Trading simulators vary dramatically in such aspects of performance as speed, capacity, and power. Speed is important when there is a need to carry out many tests or perform complex optimizations, genetic or otherwise. It is also essential when developing systems on complete portfolios or using long, intraday data series involving thousands of trades and hundreds of thousands of data points. In some instances, speed may determine whether certain explorations can even be attempted. Some problems are simply not practical to study unless the analyses can be accomplished in a reasonable length of time. Simulator capacity involves problem size restrictions regarding the number of bars on which a simulation may be performed and the quantity of system code the simulator can handle. Finally, the power a simulator gives the user to express and test complex trading ideas, and to run tests and even system optimizations on complete portfolios, can be significant to the serious, professional trader. A fairly powerful simulator is required, for example, to run many of the trading models examined in this book.
Speed
The most significant determinant of simulation processing speed is the nature of the scripting or programming language used by the simulator, that is, whether the language is compiled or interpreted. Modern optimizing compilers for generic languages, such as Cf f, FORTRAN, and Pascal/Delphi, translate the userwritten source code into highly efficient machine code that the processor can execute directly at full bore; this makes simulator toolkits that use such languages and compilers remarkably fast. On the other hand, proprietary, interpreted languages, such as Microsoft’s Visual Basic for Applications and Omega’s Easy Language, must be translated and fed to the processor line by line. Simulators that employ interpreted languages can be quite sluggish, especially when executing complex or “loopy” source code. Just how much speed can be gained using a compiled language over an interpreted one? We have heard claims of systems running about 50 times faster since they were converted from proprietary languages to C+ + !
Capacity
While speed is primarily a function of language handling (interpreted versus compiled), capacity is mostly determined by whether 16-bit or 32-bit software is used. Older, 16-bit software is often subject to the dreaded 64K limit. In practical terms, this means that only about 15,000 bars of data (about 4 days of ticks, or 7 weeks of l-minute bars on the S&P 500) can be loaded for system testing. In addition, as the system code is embellished, expect to receive a message to the effect that the system is too large to verify. Modem C+ + or FORTRAN products, on the other hand, work with standard 32.bit C+ + or FORTRAN compilers. Consequently, they have a much greater problem size capacity: With continuous-contract data on a machine with sufficient memory, every single tick of the S&P 500 since its inception in 1983 can easily be loaded and studied! In addition, there are virtually no limits on the number of trades a system can take, or on the system’s size and complexity. All modern Cf +, FORTRAN, and Pascal/Delphi compilers are now full 32.bit programs that generate code for, and run under, 32-bit operating systems, such as Windows 95, Windows NT, or LINUXAJNIX. Any simulator that works with such a compiler should be able to handle large problems and enormous data sets with ease. Since most software packages are upgrading to 32-bit status, the issue of problem size capacity is rapidly becoming less significant than it once was.
Power
Differences in simulator power are attributable mostly to language and to design. Consider language first: In this case, it is not whether the language is compiled or interpreted, as was the case for speed, but rather its expressive power. Can the most elaborate and unusual trading ideas be expressed with precision and grace? In some languages they can; in others they cannot. It is unfortunate that the most powerful languages have steep learning curves. However, if one can climb the curve, a language like Cf + makes it possible to do almost anything imagina le. Your word processor, spreadsheet, web browser, and even operating system were all probably written in C++ or its predecessor, C. Languages like C++ and Object Pascal (the basis of Borland’s Delphi) are also extensible and can easily be customized for the purpose of trading system development by the use of appropriate libraries and add-on components. Visual Basic and Easy Language, although not as powerful as general-purpose, object-oriented languages like Cf + or Object Pascal, have gentler learning curves and are still quite capable as languages go. Much less powerful, and not really adequate for the advanced system developer, are the macro-like languages embedded in popular charting packages, e.g., Bquis International’s MetaStock. The rule of thumb is the more powerful the language, the more powerful the simulator.
Design issues are also a consideration in a simulator’s power. Extendability and modularity are especially important. Simulators that employ C+ + or Object Pascal (Borland’s Delphi) as their native language are incredibly extensible and can be highly modular, because such general-purpose, object-oriented languages are themselves highly extensible and modular; they were designed to be so from the ground up. Class libraries permit the definition of new data types and operators. Components can provide encapsulated functionality, such as charting and database management. Even old-fashioned function libraries (like the Numerical Algorithms Group library, the International Mathematics and Statistics Library and the Numerical Recipes library) are available to satisfy a variety of needs. Easy Language, too, is highly extensible and modular: Modules called User Functions can be created in Easy Language, and jimcrions written in other languages (including C+ +) can be called (if they are placed in a dynamic link library, or DLL). Macrolike languages, on the other hand, are not as flexible, greatly limiting their usefulness to the advanced system developer. In our view, the ability to access modules written in other languages is absolutely crucial: Different languages have different expressive foci, and even with a powerful language like C+ +, it sometimes makes sense to write one or more modules in another lan guage such as Prolog (a language designed for writing expert systems).
One additional design issue, unrelated to the language employed, is relevant when discussing simulator power: whether a simulator can work with whole portfolios as well as with individual tradables. Many products are not designed to perform simulations and optimizations on whole portfolios at once, although sometimes addons are available that make it possible to generate portfolio performance analyses after the fact. On the other hand, an appropriately designed simulator can make multiple- account or portfolio simulations and system optimizations straightforward
No comments:
Post a Comment