Expressions are the muscles of your trading definitions. They provide:

• the value, conditional state, security or security list that is represented by a Named Term’s name
• the trade-sizing information used by your Trading Rules and the conditional criteria that triggers those rules.
• the means by which your List Selectors select shares for a strategy’s trading list
• the conditions under which a Trading Strategy is activated or deactivated

Four types of expression produce four types of result: a numeric or percentage value; a conditional state (i.e. true or false); a security; or a list of securities. Each of these types is fully covered in the Help topics on Value Expressions & Terms, Condition Expressions & Terms, Security Expressions & Terms, and Security List Expressions & Terms and List Selectors, respectively, These describe how sub-terms are formed and combined using operators. 

In the list of operators is always an option to ‘end expression’, ‘end condition’, ‘end selection’, etc. which terminates the addition of new terms to the expression and so ends the creation of the expression.

What you could find confusing is that you may be presented with another operator list (including the ‘end…’ option) on the next Wizard dialog, immediately after selecting the ‘end…’ option in the previous list. If you choose that ‘end…’ then, on the next Dialog, you may see another ‘end…’ in the operator list, and so on. What’s going on?

When this happens it means you’ve been creating a sub-expression, embedded within another expression. This nesting of expressions may go to any depth and each nested expression must be terminated by its own ‘end expression’ (or ‘end condition’ etc.) option. RuleTrader tries to help you out by delimiting sub-expressions, if possible, either with parentheses i.e. (….), or apostrophes i.e. ‘…’.

If the delimiters are there, use them as a guide when you’re trying to decide which ‘end…’ option relates to which level of nested expression. However, you can often avoid the problem entirely by breaking the overall expression into its individual parts using Named Terms to represent each nested expression.

If you’re entering a value or value construct (see Value Terms), then the DEfTWizard is likely to assume it’s but one term in a larger value expression, so will expect an ‘end expression’ at some point. Similarly if you are entering a comparison condition or a condition construct  (see Condition Terms), then its probably expected to be a single term in a condition expression that will need to be ended. The same is true for Security List and List Selector expressions (Security expressions don’t require operators, as they only ever need one term).

The diagram below illustrates some examples of nested expressions and the delimiters used to differentiate the sub-expression from the main expression. Lets break the first example down, so you can see what’s going on.

In this first example, there are actually three nested expressions. The innermost expression is the value expression that the evaluated security’s profit is compared against. Like most value expressions, it has no delimiters. It also contains only one term – the number zero. But it must still be terminated by entering ‘end expression’, to indicate you don’t want to add any more terms to the expression for the value to be compared against.

When you press Next the Wizard will move to the next dialog and will immediately offer you a list of condition operators, in case you want to extend the sub-condition expression with another conditional term. As we only want the one term – the evaluated security’s profit (£ final) is greater than 0 – we choose the ‘end condition’ option. In this case, because the sub-condition expression is part of the larger ‘condition has transitioned’ construct (see Condition Terms), which itself is the first term in the outermost condition expression, it delimits the sub-condition expression in ‘…’ to make this clear.

When we press Next again the Wizard will ask us to complete the ‘condition has transitioned’ construct, by choosing the direction of the condition state change we’re testing for and whether we want to test yesterday’s or today’s. Finally, we’ll be presented with a list of logical operators in case we want to extend the outermost condition expression. As we don’t, we choose the final ‘end condition’ option.

The next example shows a list ordering value expression embedded in an outer value expression that contains three terms and should be self-explanatory:

Look at how much easier and understandable it is, though, if a Named Term is used to replace the list ordering expression (the definitions of ‘Weight’ and ‘Sector List’ are omitted for clarity):