Expression Syntax

Analytica expressions appear primarily in the Definition and Check attributes of variable objects.

Note that Analyica Typescript has a separate syntax from Analytica Expressions (see also Typescript Commands). Typescript is used in the Script attribute of Button and Picture nodes, from the Typescript window in Analytica, and from the CAEngine::SendCommand method in ADE. However, expressions can be evaluated from typescript as well with some caveats - see Scripting.

Function Calls

Analytica contains many built-in functions, and you can extend these with User-Defined Functions. The standard position-based syntax for the parameters of a function is:

F(A, B, C)

where the parameter values A, B, and C may themselves be expressions.

For most, but not all, built-in functions and all User-Defined Functions, you can also used a name-based syntax for parameters. These examples show four ways to call function Uniform with the same parameter values, using position-based syntax, name-based syntax, and a combination:

Uniform(1, 100, true)   --- position-based syntax
Uniform(min:1, max:100, integer: true)  --- name-based syntax
Uniform(Integer: true, min:1, max: 100)  --- name-based syntax
Uniform(1, 100, integer: true)  --- mixed syntax

Name-based syntax means you specify the parameter by name, followed by colon, followed by the a number or expression giving its value. When you specify parameters by name, you can list them in any order, as in the third example. Using mixed syntax, you can specify initial parameters by position, but after you specify a parameter by name, you must also specify all following parameters by name.

If a function expects a parameter to be an index or variable, you must give it the identifier of a variable or index. You can specify an index using the dot-operator syntax -- e.g. A.I. But, in these cases, you may not use arbitrary expressions, including function calls, as the value.

Functions evaluate ("call") their parameters in various ways, as specified by theparameter qualifiers, and on the evaluation mode when the function is evaluated.

Operator Precedence

Some operations in Analytica are parsed with a higher binding precedence than other operators. For example, exponentiation (^) binds more tightly than multiplication (*) and division (/), which binds more tightly than addition (+) and subtraction (-). Therefore, the following expression

1 / 2 * 3 - 4 / 5 ^ 6 + 7

would parse as

( ( 1 / 2 ) * 3 ) - ( 4 / ( 5 ^ 6 ) ) + 7

The following list shows the binding precedence of Analytica operators, with the highest precedence operators at the top. Those operators in the same bullet have the same level of precedence:

• Parentheses: ( ... )
• Function calls
• Not
• @I , \A, \[I]A, #R.
• A.I
• A[I=x]
• Attrib of Obj
• ^
• - (unary)
• *, /
• +, - (binary minus)
• m..n
• =, <=, >=, <, >, <>
• And, Or
• &
•  :=
• If..Then..Else, Ifall..Then..Else, IfOnly..Then..Else
• sequence of statements (;), comma separation of elements or parameters (,)

Comments

Comments can be embedded anywhere whitespace would be allowed within an expression. There are two recognized syntaxes for comments:

{ This is a comment }
/* This is a comment */ 

If you start a comment with {, then your comment cannot contain the } character within. Similarly, if you begin a comment with /*, the comment cannot contain the two character sequence */ inside. If you need to embed a comment within a comment (which sometimes is useful when temporarily commenting out a block of expression code that already contains comments), then you need to ensure that if the inner comment uses {...}, that the outer comment uses /*...*/, or vise versa.

Version Gated Comments

(new to 4.0)

A version-gated comment is a portion of an expression that is viewed as a comment in some releases of Analytica, but as an actual expression in other releases of Analytica. For example, suppose you have an algorithm that leverages features that are new to Analytica 4.0, but you still want the algorithm to be usable by users of Analytica 3.1, perhaps falling back to a less efficient algorithm or to reduced functionality. A version-gated comment provides one way to do this without risk of parse errors in the version that might not recognize the newer features.

Consider the following equivalent forms of version gated comments.

{!40000|expression}
{!40000-|expression}}

These indicate that in Analytica release 4.00.00 or after, the expression is to be interpreted, but in any release prior to Analytica 4.00.00, it should be treated as a comment.

The following version gated comment treats this as a comment in any release prior to 4.00.00 or after 4.01.00, but in releases 4.00.00 through 4.01.00, the expression is interpreted:

{!40000-40100|expression}

The following interprets the expression in any 4.0 or later release that is prior to or including 4.02.00, but treats it as a comment in any release after 4.02.00.

{!-40200|expression}

Important: All version-gated comments are treated as comment in Analytica releases 3.1 and earlier, regardless of what the version number indicates, since the version-gated comment feature was not introduced until Analyica 4.0.