While the underlying concepts behind strings, string variables, and replacement variables have not changed since the first version of EViews, there were three important changes in the implementation of these concepts introduced in EViews 5. In addition, there has been an important change in the handling of boolean comparisons involving numeric NA values, and blank string values.

First, the use of contextual information to distinguish between the use of string and replacement variables has been eliminated.

Prior to EViews 5, the underlying notion that the expression “%X” refers exclusively to the string variable %X while the expression “{%X}” refers to the corresponding replacement variable was modified slightly to account for the context in which the expression was used. In particular, the string variable expression “%X” was treated as a string variable in cases where a string was expected, but was treated as a replacement variable in other settings.

For example, suppose that we have the string variables:

When used in settings where a string is expected, all versions of EViews treat %X and %Y as string variables. Thus, in table assignment, the command,

is equivalent to the expression,

However, when string variables were used in other settings, early versions of EViews used the context to determine that the string variable should be treated as a replacement variable; for example, the three commands

were all viewed as equivalent. Strictly speaking, the first command should have generated an error since string variable substitution would replace %Y with the double-quote delimited string “cons” and %X with the string “income”, as in

Instead, EViews determined that the only valid interpretation of %Y and %X in the first command was as replacement variables so EViews simply substituted the names for %Y and %X.

Similarly, the commands,

all yielded the same result, since %Y and %X were treated as replacement variables in the first line, not as string variables.

The contextual interpretation of string variables was convenient since, as seen from the examples above, it meant that users rarely needed to use braces around string variables. The EViews 5 introduction of alphanumeric series meant, however, that the existing interpretation of string variables was no longer tenable. The following example clearly shows the problem:

Note that in the final assignment statement, the command context alone is not sufficient to determine whether %X should refer to the string variable value “parent” or to the replacement variable PARENT, which is an Alpha series containing the string “mother”.

Consequently, in EViews 5 and later, users must now always use the expression “{%X}” to refer to the replacement variable corresponding to the value of %X. Thus, under the new interpretation, the final line in the example above resolves to

Under the EViews 4 interpretation of the final line, “%X” would have been treated as a replacement variable so that TEMP would contain the value “mother”.

To interpret the last line as a replacement variable in EViews 5 and later, you must now explicitly provide braces around the string variable

to resolve to the command

The second major change in EViews 5 is that text in a string expression is now treated as a literal string. The important implication of this rule is that string variable text is no longer substituted for inside a string expression.

Consider the assignment statements

In EViews 4 and earlier, the “%B” text in the string expression was treated as a string variable, not as literal text. Accordingly, the EViews 4 string variable %A contains the text “hi mom!”. One consequence of this approach is that there was no way to get the literal text of the form “%B” into a string using a program in EViews 4.

Beginning in EViews 5, the “%B” in the second string variable assignment is treated as literal text. The string variable %A will contain the text “hi %b”. Obtaining a %A that contains the EViews 4 result is straightforward. Simply move the first string variable %B outside of the string expression, and use the string concatenation operator:

assigns the text “hi mom!” to the string variable %A. This expression yields identical results in all versions of EViews.

In early versions of EViews, program statements could involve string comparisons. For example, you might use an if-statement to compare a string variable to a specific value, or you could use a string comparison to assign a boolean value to a cell in a matrix or to a numeric series. In all of these settings, the string comparisons were performed caselessly, so that the string “Abc” was viewed as equal to “ABC” and “abc”.

The introduction of mixed case alpha series in EViews 5 meant that caseless string comparisons could no longer be supported. Accordingly, the behavior has been changed so that all EViews 5 and later string comparisons are case-sensitive.

If you wish to perform caseless comparison in newer versions of EViews, you can use the @upper or @lower string functions, as in

or

Alternately, programs may be run in version 4 compatibility mode to enable caseless comparisons for element operations (see “Version 4 Compatibility Mode”). For example, the if-statement comparison:

will be performed caselessly in compatibility mode.

Note that compatibility mode does not apply to string comparisons that assign values into an entire EViews series. Thus, even in compatibility mode, the statement:

will be evaluated using case-sensitive comparisons for each value of ALPHASER.

Prior to EViews 5, NA values were always treated as ordinary values for purposes of numeric equality (“=”) and inequality (“<>”) testing. In addition, when performing string comparisons in earlier versions of EViews, empty strings were treated as ordinary blank strings and not as a missing value. In these versions of EViews, the comparison operators (“=” and “<>”) always returned a 0 or a 1.

In EViews 5 and later, the behavior of numeric and string inequality comparisons involving NA values or blank strings has been changed so that comparisons involving two variables propagate missing values. To support the earlier behavior, the @eqna and @neqna functions are provided so that users may perform comparisons without propagating missing values. Complete details on these rules are provided in “String Relational Operators” and in “Numeric Relational Operators”

Programs may be run in version 4 compatibility mode to enable the earlier behavior of comparisons for element operations. For example, the if-statement comparison:

will not propagate NA values in compatibility mode.

Note that compatibility mode does not apply to comparisons that assign values into an EViews numeric or alpha series. Thus, even in compatibility mode, the statement:

will propagate NA values from either X or Z into Y.

While the changes to the handling of string variables and element boolean comparisons are required for extending the programming language to handle the new features of the EViews 5 and later, we recognize that users may have a large library of existing programs which make use of the previous behavior.

Accordingly, EViews provides a version 4 compatibility mode in which you may run EViews programs using the previous context sensitive handling of string and substitution variables, the earlier rules for resolving string variables in string expressions, and the rules for caseless string comparison and propagation of missing values in element comparisons.

There are two ways to ensure that your program is run in version 4 compatibility mode. First, you may specify version 4 compatibility mode at the time the program is run. Compatibility may be set interactively from the Run Program dialog ( “Executing a Program”) by selecting the Version 4 compatible variable substitution and program boolean comparisons checkbox, or in a program using the “ver4” option (see run).

Alternatively, you may include “MODE VER4” statement in your program. See “Program Modes” for details.