91
- Screen shots and drawing with captions.
- Prototypes (e.g., sample spreadsheets) with embedded documentation.
- Logic flow diagrams.
- Mathematical equations with legends.
● List discarded alternatives to chosen quantitative methods at the end, with only short
descriptions as to why they were discarded. We gain knowledge from failure and all
failures should be cataloged and stored, but the strategy description is not the place
for it. The readers are interested in what works, not in what does not.
● Avoid using the passive voice. In trading system descriptions, the passive voice
obscures who the actor is, which event caused what to occur, and when it happened.
● Avoid words like “ easily, ” “ obviously, ” or “ clearly, ” as in “ the rest of the calculation
follows easily. ” Also, avoid anthropomorphizing equations or computers, as in “ the
calculation acts up when... ” or “ the software thinks that .... ”
● Choose singular over plural number. For example, if you say that “ data sequences
induce time series analyses, ” it is not clear whether data and analyses are in one-to-one
correspondence, or the set of data collectively induces a set of analyses. “ Each sequence
of data induces an analysis of the time series ” avoids confusion.
● Use terms consistently. If you are trading bonds, use one term, say, bond. There is
no need to intermingle “ fixed income, ” “ instrument, ” or “ debt security, ” unless the
use of synonyms distinguishes unrelated concepts. For example, we use the syno-
nyms “ stage ” and “ step, ” and “ loop ” to identify specific phases of our methodology.
● For clarity, give unique, descriptive names to concepts.^7 For example, you may
name a certain model, say, an execution algorithm as something unique, like “ The
Extended VWAP Model. ” Using an acronym like “ XVWAPMod ” is confusing.
A good name gives team members a shorthand way to refer to a package of related
procedures and aids in reuse.
Some of the suggestions in this document are about good writing, and that might
seem secondary to the research. But documenting clearly helps teams think and plan
more clearly and often reveals flaws or ideas that had previously been invisible. Giving
examples also helps clarify concepts. Examples make concrete in the reader ’ s mind what
a specific technique does. A running example over the course of the description may help
illustrate how algorithms work and work in sequence.
Now, one may (and should be) concerned about getting hung up in the pursuit of
documentation instead of the pursuit of working trading systems. Documents can easily
become cumbersome in a highly dynamic, research-oriented field of new trading/invest-
ment system design. But, at the same time, teams should recognize that verbal communi-
cation is rarely consistent and that only written information is clear and constant.8.2. Logic Leaks
Logic rules give rise to leaks, and logic leaks can occur in any type of trading/invest-
ment system. To illustrate, however, we will use as an example a simple moving average
crossover system. According to our hypothetical system, when the fast moving average
crosses over the long moving average to the upside, this is a bullish signal. When the fast
moving average crosses over to the downside, this is a bearish signal. Now, let ’ s examine8.2. LOGIC LEAKS