Glossary

Glossary Last Modified: 8:25:22 PM 11/19/2008 GMT+10:00

.a: A field file extension indicating that the file's values are "actual" (according to the sources of daily historical pricing data), which typically means unadjusted, non-proprietary, and when applied to files containing share-related data, in units of single shares. The specific source used to construct the file is not necessarily uniform and may be subject to change between editions of backtest.exe and its database.
[a, b): The interval of market dates from a to b, including a but excluding b.
abs: A field function calculating absolute values of another field's values. Its syntax is as follows:

abs:<field_ref>

As shown, the function abs takes a field reference as its single argument. For each investment, the function abs takes the absolute value of its corresponding value in the field referenced by field_ref and assigns it to its corresponding value in the calling field.
absolute comparison: A per-investment comparison between a field's value and a comparison value on the basis of equality, unequality, less than, greater than, less than or equal or greater than or equal relations. Absolute comparisons, distinguished from relative comparisons, are so named because they can be made for a particular investment without reference to the field values for any other investment.
actual suspension: A gap or ending in a stock's pricing history resulting from a real event such as a delisting, corporate action, halting, etc. Actual suspensions are distinguished from nominal suspensions.
al: ('al') A comparison code signifying the selection of investments whose field value is greater than or equal to (at least) a comparison value. That is, the step condition

field<field_number>al[<comparison_value>|<param_ref>]

selects all eligible investments whose value in field<field_number> is at least comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested.
am: ('am') A comparison code signifying the selection of investments whose field value is less than or equal to (at most) a comparison value. That is, the step condition

field<field_number>am[<comparison_value>|<param_ref>]

selects all eligible investments whose value in field<field_number> is at most comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested.
Annualized Turnover: (Also AT.) For the portfolio corresponding to a given cycle of a given variant, the average turnover value taken over all of its trading dates within the interval [start, end), multiplied by 253/hold, where 253 is the average number of market days in a calendar year. An Annualized Turnover of 12, for example, indicates that all positions are liquidated an average of 12 times per year, or once a month.
aprc: (1) A field function retrieving each investment's actual price per share of underlying stock at the close of the current trading date. Its syntax is as follows:

aprc

As shown, this version of aprc takes no arguments. For each investment on market date d, aprc retrieves its applicable value in gtoa.a and multiplies this by its current g-price, assigning the result to the calling field. All eligible investments are guaranteed to have positive values in gtoa.a, and thus this version of aprc is guaranteed to produce positive values. Field values produced by this version of aprc are commensurable with any field file with extension .a and zero lag.

(2) A field function retrieving each investment's actual closing price per share of underlying stock a specified number of market dates previous to the current trading date. Its syntax is as follows:

aprc:<quote_lag>

As shown, this version of aprc takes a single non-parameterized argument, quote_lag. The value of this argument must be a non-negative integer at most 20. For each investment on market date d, aprc retrieves its value in gtoa.a applicable on d - quote_lag and multiplies this by its g-price on d - quote_lag, assigning the result to the calling field. That is, the values in field0 generated by the argument

field0=aprc:<quote_lag>are equivalent to the values in field2 generated by the following arguments:

field0=gtoa.a:<quote_lag> field1=gprc:<quote_lag> field2=product:field0,field1Investments that were not eligible on d - quote_lag are assigned field values of zero (since the default value for gtoa.a is zero). Field values produced by this version of aprc are commensurable with other field files with extension .a lagged by the same value as quote_lag. Finally, if quote_lag is zero, then aprc (2) is equivalent to aprc (1).

(3) A field function calculating, for each investment, an adjusted closing price per share of underlying stock, where the quotation date is a specified number of market dates previous to the current trading date and the shares are in units from a separately specified number of market dates previous to the current trading date. Its syntax is as follows:

aprc:<share_lag>,[<quote_lag>|<param_ref>]

As shown, this version of aprc takes two arguments, the first a non-parameterized argument, share_lag, and the second a parameterizable argument, <quote_lag>. The value of share_lag must be a non-negative integer at most 20, while the value of quote_lag may be any non-negative integer at most the retrospective limit. For each investment on market date d, aprc retrieves its value in gtoa.a applicable on d - share_lag and multiplies this by its g-price on d - quote_lag, assigning the result to the calling field. That is, the values in field0 generated by the argument

field0=aprc:<share_lag>,<quote_lag>
are equivalent to the values in field2 generated by the following arguments:

field0=gtoa.a:<share_lag> field1=gprc:<quote_lag> field2=product:field0,field1
Investments not eligible on d - share_lag are assigned field values of zero (since the default value for gtoa.a is zero). Field values produced by this version of aprc are commensurable with other fields with extension .a lagged by the same value as share_lag. Finally, if share_lag and quote_lag are equal, vprc (3) is equivalent to vprc (2), and if both share_lag and quote_lag are zero, then aprc (3) is equivalent to aprc (1).
AT: See Annualized Turnover.
av10.a: A field file containing average daily volume over the previous 10 consecutive market dates (including the current trading date) for each investment. Actual daily volumes (as expressed in number of shares, not hundreds or thousands of shares) are first converted to the same share units as those of the current trading date (thereby accounting for splits); they are then summed and divided by 10. Thus av10.a is commensurable with all other field files with extension .a, including other volume field files such as av21.a, and with the field function aprc.

Coverage of daily volumes for all three major exchanges (NYSE, Nasdaq, AMEX) does not begin within the current source of raw daily historical data until 19821101. Thus av10.a, which requires 10 market dates of volume history, is not available until 19821112. When a stock has fewer than 10 market dates of trading history, zero volumes are assumed during its pre-history. Use the field function dspo to filter out stocks with insufficient trading history if this default assumption is undesirable.
av21.a: A field file containing average daily volume over the previous 21 consecutive market dates (including the current trading date) for each investment. Actual daily volumes (as expressed in number of shares, not hundreds or thousands of shares) are first converted to the same share units as those of the current trading date (thereby accounting for splits); they are then summed and divided by 21. Thus av21.a is commensurable with all other field files with extension .a, including other volume field files such as av63.a, and with the field function aprc.

Coverage of daily volumes for all three major exchanges (NYSE, Nasdaq, AMEX) does not begin within the current source of raw daily historical data until 19821101. Thus av21.a, which requires 21 market dates of volume history, is not available until 19821130. When a stock has fewer than 21 market dates of trading history, zero volumes are assumed during its pre-history. Use the field function dspo to filter out stocks with insufficient trading history if this default assumption is undesirable.
av63.a: A field file containing average daily volume over the previous 63 consecutive market dates (including the current trading date) for each investment. Actual daily volumes (as expressed in number of shares, not hundreds or thousands of shares) are first converted to the same share units as those of the current trading date (thereby accounting for splits); they are then summed and divided by 63. Thus av63.a is commensurable with all other field files with extension .a, including other volume field files such as av21.a, and with the field function aprc.

Coverage of daily volumes for all three major exchanges (NYSE, Nasdaq, AMEX) does not begin within the current source of raw daily historical data until 19821101. Thus av63.a, which requires 63 market dates of volume history, is not available until 19830128. When a stock has fewer than 63 market dates of trading history, zero volumes are assumed during its pre-history. Use the field function dspo to filter out stocks with insufficient trading history if this default assumption is undesirable.
Avg: A column header abbreviation for "Average", used in sumfile for backtest.exe and blend.exe to identify columns containing averages over all cycles.
avg: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field; then, for each group, averages the members' values in another specified field; and finally, assigns to each investment the average for the group to which it belongs. Its syntax is as follows:

avg:<avg_field_ref>,[<group_field_ref>|1],<at_step_ref>

As shown, the function sum takes three arguments: the first of which a field reference, avg_field_ref; the second of which is either another field reference, group_field_ref, or the number 1; and the third of which, at_step_ref, is a step reference. The argument at_step_ref specifies that averages be calculated for all investments, and only among those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group then separately has its average computed over its members' values in the field referenced by avg_field_ref. Finally, the resulting average is assigned to the calling field for every investment within the group.
backtest command: An invocation of the program backtest.exe with the space-separated argument strings

[start=<yyyymmdd>]
[end=<yyyymmdd>]
[hold=<holding_period>]
[rebaln=<rebaln>]
[rskintvl=<risk_interval_length>]
[risk=<specifier_word>]
[friction=<friction_multiplier>]
[user=<user_dir>]
field0=[<field_filename>:<lag_days>|<field_function_call>]
[field<field_number>=[<field_filename>:<lag_days>|<field_function_call>]]...
step0=<step_condition>
[step<step_number>=<step_condition>]...
[htd=<htd_condition>]
[stopgain=[<gain_multiplier>|<param_ref>]]
[stoploss=[<loss_multiplier>|<param_ref>]]
[<user_defined_field_name>.u=field<field_number>]...
[paramfile=<parameter_filename>]
[sumfile=<summary_filename>]
[-shrink]
[-count]
[-portval]
[-nocache]

(Arguments have been placed on separate lines for readability.)

All characters in bold represent literal components of argument strings. Bracketed arguments or sub-strings are optional; options are separated by the '|' character. Carrots ('<' and '>') are used to enclose references to substitutable strings. No valid backtest command ever contains the characters '|', '[', ']', '<' or '>'.

As shown, at least one field argument and at least one step argument are required; all other arguments are optional.

yyyymmdd represents a market date.
holding_period represents a positive integer at most 254.
rebalan represents a positive integer.
risk_interval_length represents a positive integer.
specifier_word represents a string of risk specifiers.
friction_multiplier represents a positive decimal number at most 1.
user_dir represents the name of a subdirectory of the directory containing backtest.exe.
field_filename represents the name of a field file.
lag_days represents a non-negative integer.
field_function_call represents a string calling a field function.
step_condition represents a step condition.
htd_condition represents an HTD condition.
gain_multiplier represents a decimal number greater than 1.
loss_multiplier represents a positive decimal number less than 1.
user_defined_field_name represents a string containing lower-case letters, numerals and underscores.
parameter_filename represents the name of a space, comma or tab-separated tabular text file.
summary_filename represents the name of the CSV file to which results will be saved.

For the meaning of arguments, see the glossary entry for any bolded words in this entry's text.
backtest.exe: A Windows and Linux command-line backtest program written in C++ by myself, Robert Geary, for the purpose of bringing daily-start backtesting to fool.com's Mechanical Investing message board readers via the web-based user interfaces provided by others at hosting websites. See backtest command for command line usage.

Windows executables are compiled using Visual C++ 6.0 (VC6) and Linux executables are compiled using Intel's C++ Compiler for Linux (ICL). Both use their respective operating system's memory mapping capability for reading field files and gprc.dat in order to allow concurrent backtest processes to run without duplicating these files in memory.

While it is not absolutely necessary, it is strongly recommended that backtest.exe be run on a computer capable of holding gprc.dat and all field files in RAM simultaneously in order to prevent each execution of a backtest command from having to access the same files from the hard drive; this currently requires just over 1GB of free RAM, though this will increase as more field files are added. All increases in available memory up to this amount will yield significant performance improvements.
backward interpolation: Coming soon!
beta: A field function calculating each investment's beta over a specified sequence of return periods. Its syntax is as follows:

beta:[<lag_days>|<param_ref_1>],[<num_of_periods>|<param_ref_2>],[<period_length>|<param_ref_3>]

As shown, the function beta takes three arguments, each of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the values of num_of_periods and period_length must be positive integers, num_of_periods must be at least 2, and

lag_days + num_of_periods * period_length

must not exceed the retrospective limit. For each investment, the function beta calculates the slope of the regression line through the set of num_of_periods number of ordered pairs (TR_mkt, TR_invst), where TR_mkt represents a total return for the market (as represented by daily adjusted prices in inx.txt) over period_length number of market days, TR_invst represents a total return for the investment (obtained by dividing its appropriate closing g-prices) over period_length number of market days, and one pair is formed for each of the consecutive disjoint num_of_periods number of periods of period_length number of market days within the interval of (num_of_periods * period_length) number of market days ending lag_days number of market days prior to the current trading date. The resulting slope is assigned to the calling field.

For example, beta:3,52,5 calculates each investment's beta using its last 52 disjointly measured 5-day total returns versus those of the market, with the most recent 5-day total return measured through the close of the market date 3 prior to the current trading date.

Note that if lag_days is zero, then beta is measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place.

By default, a meaningful beta is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional beta computation, use the field function dsio or dspo.
Beta(): Coming soon!
blend command: An invocation of the program blend.exe with the space-separated argument strings

[start=<yyyymmdd>]
[end=<yyyymmdd>]
[rskintvl=<risk_interval_length>]
[friction=<friction_multiplier>]
<weight_1>:<c2_cache_filename_1>
[<weight_2>:<c2_cache_filename_2>]...
[sumfile=<summary_filename>]
[-portval]

(Arguments have been placed on separate lines for the sake of readability.)

All characters in bold represent literal components of argument strings. Bracketed arguments or sub-strings are optional; options are separated by the '|' character. Carrots ('<' and '>') are used to enclose references to substitutable strings. No valid blend command ever contains the characters '|', '[', ']', '<' or '>'.

As shown, blend.exe requires only one argument, which is of the form <weight_1>:<c2_cache_filename_1>.

yyyymmdd represents a market date.
risk_interval_length represents a positive integer.
weight_1, weight_2, ... refer to decimal representations of numbers used as weights for blended strategies.
c2_cache_filename_1, c2_cache_filename_2, ... represent c2 cache filenames.
friction_multiplier represents a positive decimal number at most 1.
summary_filename represents the name of the CSV file to which results will be saved.

For the meaning of arguments, see the glossary entry for any bolded words in this entry's text.
blend.exe: A Windows and Linux command-line program accompanying backtest.exe that generates a summary of results, including Annual Return and (optionally) Daily Portfolio Value, for portfolios consisting of weighted combinations (or "blends") of one or more strategy variants (or the "blended strategies") previously c2-cached by backtest.exe. See blend command for its syntax and cycle (3) for a description of how blends are calculated.

In addition to combining strategies, blend.exe can be applied to a single-strategy portfolio to get a more detailed alternative to the output of backtest.exe including daily portfolio values in spreadsheet format so that users can easily calculate their own summary statistics. However, blend.exe does not handle parameterized backtest commands, meaning blend.exe's summarizing capabilities do not replace those of backtest.exe.

Furthermore, blend.exe does not actually perform backtests; it merely reads the c2 cache files produced by backtest.exe and calculates returns and summary statistics. In fact, blend.exe was originally written for the sole purpose of demonstrating C++ code that reads c2 cache files, thereby enabling users to write their own programs that produce more detailed information on single-variant backtests than what is displayed in backtest.exe's sumfile. The source code for blend.exe is still available for that purpose.

Windows executables are compiled using Visual C++ 6.0 (VC6) and Linux executables are compiled using Intel's C++ Compiler for Linux (ICL).
bn: ('bn') A comparison code signifying the selection of the "bottom number" (specified by the comparison value) of eligible investments according to the referenced field. More precisely, the step condition

field<field_number>bn[<comparison_value>|<param_ref>]

signifies the selection of eligible investments whose value in field<field_number> is less than or equal to the value in the Nth position when field<field_number> is sorted in ascending order among eligible investments, where N is equal to comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested. If there are fewer than N eligible investments, then all eligible investments are selected. Note that if the field value in the Nth position is equal to the field values of other eligible investments, then all such tying investments (in addition to the first N investments) are selected by the step condition. Thus, for example, step0 in the backtest command

backtest field0=tim.v step0=field0bn10 field1=trm:10,126 step1=field1tn5selects a group of 10 investments whose value in tim.v:0 is 1 (the minimum value, indicating top Timeliness rank by Value Line), as well as all other investments whose value in tim.v:0 is 1 (there would be approximately 90 others). To break ties for a field with a tendency to produce ties, consider adding to or subtracting from it a sufficiently small multiple of another field using the field function linear; the added or subtracted field then roughly functions as a tie-breaker.

In a backtest command's final step, the comparison value, in addition to functioning as just described, specifies the maximum number of positions in a portfolio. On each trading date, positions designated for liquidation are replaced with investments selected by the final step in the order they appear (which is undefined in the case of ties) in an ascending sort by field<field_number>. If the final step selects an insufficient number of stock investments to bring the number of positions back up to the maximum following all required liquidations, then cash positions are opened instead by default; otherwise, if the command includes the -shrink switch, then the number of positions is reduced to the number held and purchased, with a cash position opened only if all positions are liquidated and the final step selects no stock investments. Investments are always purchased in equal dollar amounts, thereby rebalancing the portfolio among new positions.
bncut: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field; then, within each group, sorts investments in ascending order according to values in another specified field; next, determines the inclusive cut-off value that would be used for selecting the bottom specified number of investments from within each group; and finally, assigns to each investment the cut-off value determined for its corresponding group. Its syntax is as follows:

bncut:<rank_field_ref>,[<group_field_ref>|1],<at_step_ref>,[<N>|<param_ref>]

As shown, the function bncut takes four arguments: the first of which, rank_field_ref, is a field reference; the second of which is either another field reference, group_field_ref, or the number 1; the third of which, at_step_ref, is a step reference; and the fourth of which is either a positive integer N or a parameter reference to such values. The argument at_step_ref specifies that cut-off values be determined among all investments, and only among those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group is then separately sorted in ascending order by values in the field referenced by rank_field_ref. Within each group, the Nth investment's value in the field referenced by rank_field_ref is determined (if a group contains fewer than N investments, then the largest value is used) and assigned to the calling field for every investment within the group.

For the sake of clarification, note that any step of comparison type bn is equivalent to a step of comparison type am after appropriate use of the field functions bncut and linear. For example, consider the command fragment

... field6=bncut:field5,1,step4,100 field7=linear:1,field5,-1,field6 step4=field7am0 ...
The field function bncut determines the inclusive cut-off value that would be used to select the bottom 100 investments by field5 at step4 and assigns it to field6 for all investments. The field function linear then subtracts this cut-off value from each investment's value in field5. Finally, step4 selects all investments for which the difference assigned to field7 is at most 0, or equivalently, all investments for which field5 is at most field6. In other words, step4 selects all investments that would pass step4 if it were defined to select the bottom 100 investments by field5. Therefore, the above command fragment is actually equivalent to the single step argument

step4=field5bn100
Obviously, direct use of a step of type bn is preferable to re-structuring it as a step of type al in the manner shown above unless the cut-off value itself is actually required for some other purpose. As an example of the latter situation, suppose one wishes for step4 to select all investments whose value in field5 is at least twice the minimum value in field5 taken over all investments eligible at step4. The command fragment above can be modified to achieve this as follows:

... field6=bncut:field5,1,step4,1 field7=linear:1,field5,-2,field6 step4=field7al0 ...
Note how the field function bncut was used to obtain the minimum value in field5 among investments eligible at step5.
bp: ('bp') A comparison code signifying the selection of a "bottom percentage" (specified by the comparison value) of eligible investments according to the referenced field. More precisely, the step condition

field<field_number>bp[<comparison_value>|<param_ref>]

signifies the selection of investments whose value in field<field_number> is less than or equal to the value in the Nth position when field<field_number> is sorted in ascending order among eligible investments, where N is obtained by multiplying the number of eligible investments by comparison_value as a percentage or, if the comparison value is parameterized, the percentage value referenced by param_ref for the variant being tested, and rounding down if non-integral. Note that if the field value in the Nth position is equal to the field values of other eligible investments, then all such tying investments (in addition to the first N investments) are selected by the step condition. To break ties for a field with a tendency to produce ties, consider adding to or subtracting from it a sufficiently small multiple of another field using the field function linear; the added or subtracted field then roughly functions as a tie-breaker.
bpcut: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field; then, within each group, sorts investments in ascending order according to values in another specified field; next, determines the inclusive cut-off value that would be used for selecting the top specified percentage of investments from within each group; and finally, assigns to each investment the cut-off value determined for its corresponding group. Its syntax is as follows:

bpcut:<rank_field_ref>,[<group_field_ref>|1],<at_step_ref>,[<Bottom%>|<param_ref>]

As shown, the function bpcut takes four arguments: the first of which, rank_field_ref, is a field reference; the second of which is either another field reference, group_field_ref, or the number 1; the third of which, at_step_ref, is a step reference; and the fourth of which is either a percentage between 0 and 100 or a parameter reference to such values. The argument at_step_ref specifies that cut-off values be determined among all investments, and only among those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group is then separately sorted in ascending order by values in the field referenced by rank_field_ref. Each group's size, N, is determined, and the (N * Bottom%/100 rounded down)th investment within the group is found and its value in the field referenced by rank_field_ref is assigned to the calling field for every investment within the group. If (N * Bottom%/100) is less than 1, then -HUGE_VAL is instead assigned to the calling field for all investments within the group.

For the sake of clarification, note that any step of comparison type bp is equivalent to a step of comparison type am after appropriate use of the field functions bpcut and linear. For example, consider the command fragment

... field6=bpcut:field5,1,step4,30 field7=linear:1,field5,-1,field6 step4=field7am0 ...
The field function bpcut determines the inclusive cut-off value that would be used to select the bottom 30% of investments by field5 at step4 and assigns it to field6 for all investments. The field function linear then subtracts this cut-off value from each investment's value in field5. Finally, step4 selects all investments for which the difference assigned to field7 is at most 0, or equivalently, all investments for which field5 is at most field6. In other words, step4 selects all investments that would pass step4 if it were defined to select the bottom 30% investments by field5 (plus ties). Therefore, the above command fragment is actually equivalent to the single step argument

step4=field5bp30
Obviously, direct use of a step of type bp is preferable to re-structuring it as a step of type am in the manner shown above unless the cut-off value itself is actually required for some other purpose. As an example of the latter situation, suppose one wishes for step4 to select all investments whose value in field5 is at most twice the median value in field5 among all investments eligible at step4. The command fragment above can be modified to achieve this as follows:

... field6=bpcut:field5,1,step4,50 field7=linear:1,field5,-2,field6 step4=field7am0 ...
Note how the field function bpcut was used to obtain a "median" value for field5 among investments eligible at step5. (The value returned by bpcut:field5,1,step4,50 is actually greater than the median of field5 at step4, though the difference is minor with a large enough sample. The average of tpcut:field5,1,step4,50 and bpcut:field5,1,step4,50 is closer to the true median, and is in fact equal to the median when the sample size is even.)
bvs.v: A field file containing [Book Value per share] as published in the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Book Value per share] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by bvs.v is 19860106.

Since VLIS 3.0, Value Line has represented null values in [Book Value per share] with zeros, thereby making it impossible for current investors to distinguish between companies with zero [Book Value per share] and those whose [Book Value per share] is unknown or not meaningful. Thus, [Book Value per share] has been regularized in bvs.v by replacing null values with zero values prior to VLIS 3.0. It is possible that other irregularities exist in [Book Value per share] (such as whether quartery or annual balance sheets are used, whether it excludes intangibles, etc), but if so, they are not possible to detect with the available data.

The default value for bvs.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with undefined [Book Value per share] are not distinguishable on the basis of bvs.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in bvs.v.

It is assumed that bvs.v will be used with vprc to calculate daily price-to-book value ratios. Thus, it is worth pointing out that Value Line's own field [Price To Book Value] is frought with irregularities over the backtesting period, which complicates many comparisons between backtest.exe and the Screen Builder.

Briefly, the irregularities in Value Line's [Price To Book Value] are as follows: In VS+ and VS3, [Price To Book Value] was equal to [Recent Price] divided by [Book Value per share], meaning that field values fluctuated according to price with each new issue. However, in VLIS 2.0, Value Line appears to have adopted a very different definition for [Price To Book Value] that resulted only in quarterly variations in field values (with update cycle varying by Industry). At the same time, Value Line introduced the field [Price To Book Value Qtr] in VLIS 2.0 that did fluctuate according to [Stock Price], but this field still does not appear to have been a simple ratio between [Stock Price] and other balance sheet items either. It is possible that Value Line inadvertently swapped field names between the new field and what used to be [Price To Book Value], but if so, then this mistake went uncorrected for five years until VLIS 3.0.

A new irregularity in [Price To Book Value] was introduced in VLIS 3.0: values are now either rounded or truncated (it is impossible to determine which) to integers. It is not known which balance sheet items (quarterly or annual) are used to calculate [Price To Book Value], but it does appear that values fluctuate each week according to [Stock Price] (we cannot be certain due to the truncation or rounding). Furthermore, Value Line does not distinguish between zero and null values (also note that values between 0 and 1 may be truncated or rounded to 0, making them indistinguishable as well).

Due to these severe irregularities in Value Line's [Price To Book Value] field, entirely avoiding this field in screen definitions is recommended; instead, use [Stock Price] and specific balance sheet items such as [Book Value per share], as represented by vprc and bvs.v, to calculate price-to-book value ratios.
c1: The name of the subdirectory (of the directory containing backtest.exe and blend.exe) where c1 cache files are stored. This subdirectory must be manually created in order to activate c1 caching.
c1 cache: Files in the c1 subdirectory created and read by backtest.exe, consisting of one file per variant that stores portfolio content on each trading date.

In order to store portfolio content compactly, c1 cache files only store differences in portfolio content from one trading date to the next. Thus, except for unusually large portfolios, variants with unusually high turnover, or variants with small hold values, c1 cache files, which typically contain just a few records per market date, are much smaller than c2 cache files, which contain exactly one record per market date per cycle. Thus if hard drive space is needed, delete c2 cache files before deleting c1 cache files.

With each execution of a backtest command, a separate c1 cache file is created for each variant not previously c1-cached; for each variant already c1-cached, a unique c1 cache file is opened from which backtest.exe reconstructs portfolio content for each cycle on its trading dates instead of executing steps. While c1 cache files are smaller than c2 cache files, the reconstruction of portfolio content and computation of portfolio values requires more processing than reading c2 cache files, though usually far less processing than testing the corresponding variants from scratch.

c1 cache files are independent of the values specified by start, end, friction, rebaln and rskintvl. A description of the structure of c1 cache files is beyond the scope of this glossary.
c2: The name of the subdirectory (of the directory containing backtest.exe and blend.exe) where c2 cache files are stored. This subdirectory must be manually created in order to activate c2 caching, which is required for running blend.exe.
c2 cache: Files in the c2 subdirectory created by backtest.exe, essential for running blend.exe, consisting of one file per variant that stores daily portfolio values for each cycle.

With each execution of a backtest command, a separate c2 cache file is created for each variant not previously c2-cached; for each variant already c2-cached, a unique c2 cache file is opened from which backtest.exe reads daily portfolio values for each cycle instead of executing any of the variant's steps. All c2 cache reading or writing operations are reported through stdout upon completed execution of each backtest command.

With each execution of a blend command, each c2 cache filename specified in an argument is opened for reading; if any c2 cache file cannot be opened, then blend.exe reports this through stdout and closes.

c2 cache files are independent of the values specified by start, end, friction and rskintvl. A description of the structure of c2 cache files is beyond the scope of this glossary.
CAGR: Compound Annual Growth Rate as calculated (by either backtest.exe or blend.exe) for each cycle of each variant using the formula

(end_port_val/start_port_val)^(253/(end - start)) ,

where start_port_val is portfolio value determined on the market date start and end_port_val is portfolio value determined on the market date end.
cash: An investment that is open on every market date and whose daily total returns match those of a "risk free" security, such as 1-Year US Treasury Notes. While cash is not included among eligible investments, it is automatically held (except when prevented with -shrink) in portfolio positions when an insufficient number of investments pass a backtest command's final step or qualify for continued holding by an htd condition.

To examine the daily total returns for cash, simply run a blend command with -portval for any strategy that cannot logically select any investments.
cdv.a: A field file containing [Actual Current Dividend] (in dollars per share) for each investment as determined from the source of daily pricing data.

Field values are intended to approximate the indicated annual dividends that an investor could have inferred from each investment's actual dividend history and its company statements available up through the current trading date. Computation of the field is complicated by the fact that companies may issue dividends with multiple frequencies (e.g., both quarterly and annual dividends) or issue dividends on multiple cycles with the same frequencies (e.g., two quarterly dividend cycles, staggered by six weeks).

For each investment on the current trading date, the value stored in cdv.a, represented by CDV, is calculated as follows: first, CDV is initialized to cdv.a's default value of 0. Records of all the investment's ordinary cash dividends whose ex-dividend dates are no later than the current trading date are selected. Each dividend amount is appropriately adjusted for any splits that occurred since its ex-dividend date so that all dividend amounts are expressed in dollars per share as of the current trading date. Each dividend record indicates whether the dividend was intended to recur monthly, quarterly, semi-annually or annually, whether its frequency was unknown, or whether it was known to be non-recurring. The value of CDV is then increased as follows:

The most recent monthly dividend record is selected. If no such dividend record exists, or if its ex-dividend date is more than 25 market days prior to the current trading date, then CDV is unchanged; otherwise, CDV is increased by 12 times its dividend amount. Additionally, CDV is increased by 12 times the dividend amount for any other monthly dividend record whose ex-dividend date is no more than 25 market days prior to the current trading date and no more than 10 market days prior to the most recent monthly ex-dividend date.

The most recent quarterly dividend record is then selected. If no such dividend record exists, or if its ex-dividend date is more than 72 market days prior to the current trading date, then CDV is unchanged; otherwise, CDV is increased by 4 times its dividend amount. Additionally, CDV is increased by 4 times the dividend amount for any other quarterly dividend record whose ex-dividend date is no more than 72 market days prior to the current trading date and no more than 31 market days prior to the most recent quarterly ex-dividend date.

The most recent semi-annual dividend record is then selected. If no such dividend record exists, or if its ex-dividend date is more than 135 market days prior to the current trading date, then CDV is unchanged; otherwise, CDV is increased by 2 times its dividend amount. Additionally, CDV is increased by 2 times the dividend amount for any other semi-annual dividend record whose ex-dividend date is no more than 135 market days prior to the current trading date and no more than 63 market days prior to the most recent monthly ex-dividend date.

The most recent annual dividend record is then selected. If no such dividend record exists, or if its ex-dividend date is more than 252 market days prior to the current trading date, then CDV is unchanged; otherwise, CDV is increased by its dividend amount. Additionally, CDV is increased by the dividend amount for any other annual dividend record whose ex-dividend date is no more than 252 market days prior to the current trading date and no more than 126 market days prior to the most recent annual ex-dividend date.

Finally, records of all other recurrng dividends (of other or uknown frequency) whose ex-dividend dates are no more than 252 market days prior to the current trading date are selected and their dividend amounts are added to CDV.

It is assumed that cdv.a will be used for calculating indicated annual dividend yields using the field function aprc, with which cdv.a is commensurable.
cdv.v: A field file containing [Current Dividend] (in dollars per share) as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Current Dividend] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by cdv.v is 19860106.

The default value for cdv.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with zero [Current Dividend] are not distinguishable on the basis of cdv.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in cdv.v.

It is assumed that cdv.v will be used with vprc to calculate daily dividend yields. Thus, it is worth pointing out that Value Line's own field [Current Dividend Yield] suffers from irregularities over the backtesting period, which complicates many comparisons between backtest.exe and the Screen Builder.

Briefly, the irregularities in Value Line's [Current Dividend Yield] field are as follows: In VS+ and VS3, [Current Yield] (as it was then named) was equal to [Current Dividend] divided by [Recent Price], expressed as a percentage, for all stocks with positive [Current Dividend] values, and zero for all other stocks. However, with the introduction of VLIS 2.0 in 1997, Value Line began assigning nulls to [% Current Yield] for all stocks without postivie [Current Dividend] values. This continued until the July 25, 2003 issue of VLIS 3.0, when Value Line reverted to assigning zero values to [% Current Yield] for all non-yielding stocks.
ces.v: A field file containing [Current EPS] (in dollars per share) as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Current EPS] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by ces.v is 19860106.

The default value for ces.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with undefined [Current EPS] are not distinguishable on the basis of ces.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in ces.v.

It is assumed that ces.v will be used with vprc to calculate daily P/E ratios. Thus, it is worth pointing out that Value Line's own field [Current P/E] suffers from irregularities over the backtesting period, which complicates many comparisons between backtest.exe and the Screen Builder.

Briefly, the irregularities in Value Line's [Current P/E] are as follows: In VS+ and VS3, [Current P/E] was equal to [Recent Price] divided by [Current EPS] for all stocks with positive [Current EPS] values and for which the resulting ratio was less than or equal to 60. Null values were assigned for all other stocks. However, with the introduction of VLIS 2.0 in 1997, Value Line raised the cap on [Current P/E] values from 60 to 100. For the frist three months of 1997, negative [Current P/E] values were calculated for stocks with negative [Current EPS] values, provided the resulting ratio was greater than or equal to -100. The cap of 100 remained in effect until the first issue of VLIS 2.0 in 2002, when the cap on [Current P/E] was removed entirely. Since then, [Current P/E] has been equal to [Stock Price] divided by [Current EPS] for all stocks with positive [Current EPS] values, and null otherwise.
cfl.v: A field file containing a regularized version of [Cash Flow] (in millions of dollars) as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen 3 and VLIS 2.0 from December 2, 1988 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Cash Flow] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by cfl.v is 19881205.

The field [Cash Flow] was introduced on 19881202 with the first issue of Value Screen 3, where it was reported in dollars per share, but since the first issue of VLIS 2.0 on 19970103, [Cash Flow] has been reported in millions of dollars. Thus, Value Line's [Cash Flow] field has been regularized in cfl.v by multiplying values from issues of VS3 by [Shares Outstanding] (see cso.v) as found within the same issues, thereby producing a field whose values are consistently expressed in millions of dollars over the entire backtesting period supported by cfl.v.

Since VLIS 3.0, Value Line has represented null values in [Cash Flow] with zeros, thereby making it impossible for current investors to distinguish between companies with zero [Cash Flow] and those whose [Cash Flow] is unknown or not meaningful. Thus, [Cash Flow] has been further regularized in cfl.v by replacing null values with zero values prior to VLIS 3.0.

The default value for cfl.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with zero or undefined [Cash Flow] are not distinguishable on the basis of cfl.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in cfl.v.
characterization period: In the context of EPL, an interval of market dates [a, b) in a stock's history where a (called the characterization period's opening date) and b (called its closing date) are critical dates and a is the only critical date contained in [a, b). The stock's prospective and retrospective total returns are unambiguously defined (characterized) from all reference points within the characterization period.
closing date: The first market date on which an investment is closed to further purchase; equivalently, the excluded upper bound of an investment's characterization period.
commensurability: (1) The condition of two values being meaningfully comparable. For example, an investment's g-price on 19870202 is commensurable with the same investment's g-price on 19870302: by design, the ratio of the latter to the former is equal to the investment's total return from the close of 19870202 to the close of 19870302. On the other hand, one investment's g-price on 19870302 is not commensurable (i.e., it is incommensurable) with the g-price of another investment on the same market date: due to the arbitrary scaling of g-prices, there is no relationship between one investment's g-prices and those of another. A high g-price can indicate a variety of unrelated attributes of an investment such as spectacular performance, a long history, few critical dates for the associated stock, etc. Thus sorting investments by g-price is not meaningful.

On the other hand, an investment's actual price (or rather, the associated stock's actual price) on 19870202 is not necessarily commensurable with the same investment's actual price on 19870302 due to the possibility of splits, among other reasons. Splits and other events are, of course, why adjusted closing prices like g-price exist. An investment's actual price on 19870202, on the other hand, is commensurable with another investment's actual price on the same date in the sense that a higher stock price usually means lower spreads, greater liquidity, greater opportunity for institutional investment, etc.

(2) The condition of two fields files or field functions being meaningfully comparable on a per-investment basis. In general, two field files with the same extension are commensurable while those with different extensions are incommensurable. Similarly, pricing functions labeled xprc are commensurable with field files with extension x, provided the share_lag argument of xprc matches the lag used for the field file. For example, an investment's values in cso.a (actual shares outstanding) and aprc (actual price) can be multiplied to get market capitalization, provided the lag specified for cso.a matches the share_lag argument specified for aprc (if the two lags differ, then a split between the two market dates used for retrieving values makes them incommensurable). On the other hand, vprc (daily price as scaled in the latest Value Line Investment Survey) and cso.a (actual shares outstanding) are incommensurable due to the possibility of Value Line having adjusted for a split ahead of or behind the market date (namely, the split's ex-dividend date) when cso.a reflects the split. However, these latter two are incommensurable for a more trivial reason: cso.a has meaningful values for the entire universe of US stocks on any given market date while vprc only provides meaningful prices on stocks covered by the Value Line Investment Survey on a given market date.
comparison code: The two-letter substring of a step condition mnemonically signifying the manner in which investments are compared to comparison values in determining whether they pass a step. The ten comparison codes and a brief description of the associated comparison follows:

Absolute comparisons:
An investment is selected if its field value is...
et == equal to...
ne != not equal to...
al >= at least...
am <= at most...
gt > greater than...
lt < less than...
...the comparison value.
Relative comparisons:
An investment is selected if its...
tn .. descending-sort rank... (for selecting top number of investments)
bn .. ascending-sort rank... (for selecting bottom number of investments)
tp .. descending-sort percentage rank... (for selecting top percentage of investments)
bp .. ascending sort percentage rank... (for selecting bottom percentage of investments)
...by field value is at most the comparison value, or if its field value is tied with that of any investment so selected.

Final step arguments require a comparison code of tn or bn. See each comparison code's glossary entry for more details.
comparison value: The numeric value represented, either literally or through a parameter reference, by the sub-string following a comparison code in a step condition.
-count: ('-count') A command switch accepted by backtest.exe that causes the number of investments passing each step for each variant on each market date to be printed to sumfile instead of performance statistics for each variant. With this switch, backtest.exe is said to be operating in "counting mode."

In addition to changing the information printed to sumfile, counting mode disables certain performance optimizations that would otherwise prevent counting the investments passing certain steps. Arguments hold, rskintvl, rebaln, htd, friction, stopgain, and stoploss are ignored, while arguments creating user-defined field files are illegal in counting mode.
critical date: See Event-Partition Linearization.
csh.v: A field file containing company [Cash] (in millions of dollars) as published in the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen 3 and VLIS 2.0 from December 2, 1988 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Cash] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by csh.v is 19881205.

The default value for csh.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with undefined [Cash] are not distinguishable on the basis of csh.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in csh.v.
cso.v: A field file containing [Common Shares Outstanding] (in millions of shares) as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Common Shares Outstanding] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by cso.v is 19860106.

The field named [Common Shares Outstanding] was introduced on 19970103 with the first issue of VLIS 2.0. However, for the purpose of building cso.v, [Common Shares Outstanding] has been extended back through all earlier electronic archives of the Value Line Investment Survey as follows: Throughout VS3, [Common Shares Outstanding] is substituted with the field [Shares Outstanding] (which appears to include preferred shares), also in millions of shares. Throughout VS+, [Common Shares Outstanding] is substituted with [Market Capitalization] (in millions of dollars) divided by [Recent Price].

The default value for cso.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with undefined [Common Shares Outstanding] (or substituted fields) are not distinguishable on the basis of cso.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in cso.v.
cycle: (1) For backtesting in general, the backtest of a single portfolio beginning on a specific starting date and following a specific sequence of regularly-spaced trading dates.

(2) One of the hold(3) (numbered from 0 to hold - 1) backtests of a variant automatically executed by backtest.exe, where cycle n first trades on start_min + n and has a schedule of trading dates consisting of start_min + n + 0 * hold, start_min + n + 1 * hold, start_min + n + 2 * hold, etc, where the final trading date is the unique market date in the sequence falling within the interval [end_max - hold, end_max). Each market date within the interval [start_min, end_max) is a trading date for exactly one of the hold cycles. For 0 < n < hold - 1, cycle n's portfolio is initialized to that of cycle 0, and therefore is identical to cycle 0 until cycle n's first trading date on start_min + n is reached.

(3) One of the hold(4) (numbered 0 to hold - 1) daily portfolio value sequences constructed by blend.exe from the c2 cache files specified by arguments in a blend command. Each cycle is assigned a sequence of market dates called its rebalancing dates, with cycle n's first rebalancing date equal to start + n. This first rebalancing date in the sequence is a trading date for exactly one cycle, called the corresponding cycle, of each strategy (as represented by its c2 cache file) included in the blend; subsequent rebalancing dates are exactly those market dates that are likewise trading dates for the same corresponding cycle of each strategy. Since hold is defined as the least common multiple of the holding periods among the blended strategies, it follows that cycle n's rebalancing dates are precisely start + n + 0 * hold, start + n + 1 * hold, start + n + 2 * hold, etc.

Each cycle's portfolio value on start is simply the sum of the weight values specified in the blend command arguments; portfolio values on subsequent market dates are calculated by multiplying the portfolio value from the most recent rebalancing date (or start, if the first rebalancing date has not yet been reached) by the weighted average of the total returns for each strategy, measured from the last rebalancing date (or start) through the current market date and weighted according to their associated weight values specified in the blend.exe command. The aforementioned total return for each strategy is determined by dividing portfolio values found within the strategy's c2 cache file for the corresponding cycle on the appropriate market dates.

Turnover is also estimated for each cycle by blend.exe using the turnover values found within the c2 cache files for the appropriate cycles. Since c2 cache files contain no information on which investments were bought and sold during the backtests that produced them, the turnover for a blend of strategies can only be approximated by assuming that on rebalancing dates, no trades for different strategies cancel each other out; consequently, turnover may be overestimated for some blends.
.d: A field file extension indicating that the file's values are essentially as published (see a particular field file's glossary entry for exceptions) in Investor's Business Daily's "Daily Graphs".
.dat: The file extension used to identify files essential to running backtest.exe and to distinguish them from field files.
day: A field function calculating the calendar day number, lagged a specified number of market dates from the current trading date. Its syntax is as follows:

day:[<lag_days>|<param_ref>]

As shown, the function day takes a single argument that is either an integer (possibly negative) or parameter reference to integers. The function day first identifies the market date that is lag_days prior to the current trading date (if lag_days is negative, then the determined market date will be later than the current trading date), provided that it does not pass the latest end supported by gprc.dat and that it does not precede the earliest start supported by gprc.dat by more than the retrospective limit. When the identified market date would otherwise exceed one of these limits, it is defined as the earliest or latest (according to whether lag_days is positive or negative, respectively) market date within the limits. Once the lagged market date is identified, the function day assigns the calendar day numbner (1, 2, ... 31) of the identified market date to the calling field for all investments.

Note that if lag_days is zero, then day determines the calendar day number associated with the current trading date.
DD(): Coming soon!
default value: A special value specified in a field file's header that backtest.exe applies to any investment whose field value on a given market date is not available. Unlike Jamie Gritton's Screen Builder, backtest.exe does not automatically "deblank" fields. That is, investments without meaningful values in a field are not automatically removed when the field is required by a step for sorting. Instead, investments having the default value in a field must be explicitly filtered out in a separate step if such investments are not desired.
dfh: A field function calculating, for each investment over a specified interval of market dates, the market date where the investment's highest closing g-price was most recently achieved within the interval, expressed as the number of market dates before the interval's end ("days from high"). Its syntax is as follows:

dfh:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function dfh takes two arguments, both of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function dfh first determines its highest closing g-price achieved over the interval consisting of rs_days (or the value referenced by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value referenced by param_ref_2 for the variant being tested) number of market days before the current trading date; it then counts market days backward (starting with 0) from the interval's last market date until the highest closing g-price is found, assigning the number of market days counted to the calling field. Thus, dfh always assigns a value that is between 0 and (rs_days - 1), inclusive. A value of 0 indicates that the high was last achieved at the end of the interval, while a value of (rs_days - 1) indicates that the high was last reached at the beginning of the interval.

By default, a meaningful dfh value is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional "days from high" computation, use the field function dsio or dspo.
dfl: A field function calculating, for each investment over a specified interval of market dates, the market date where the investment's lowest closing g-price was most recently achieved within the interval, expressed as the number of market dates before the interval's end ("days from low"). Its syntax is as follows:

dfl:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function dfl takes two arguments, both of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function dfl first determines its lowest closing g-price achieved over the interval consisting of rs_days (or the value referenced by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value referenced by param_ref_2 for the variant being tested) number of market days before the current trading date; it then counts market days backward (starting with 0) from the interval's last market date until the lowest closing g-price is found, assigning the number of market days counted to the calling field. Thus, dfl always assigns a value that is between 0 and (rs_days - 1), inclusive. A value of 0 indicates that the low was last achieved at the end of the interval, while a value of (rs_days - 1) indicates that the low was last reached at the beginning of the interval.

By default, a meaningful dfl value is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional "days from low" computation, use the field function dsio or dspo.
dsio: A field function calculating the number of market days since each investment's opening date. Its calling syntax is as follows:

dsio

As shown, the function dsio takes no arguments. For each investment, the function dsio subtracts its opening date ordinal from the ordinal corresponding to the current trading date and assigns the difference to the calling field. Since only open investments are included in the universe of investments available for screening, a meaningful non-negative integer is always returned.

The field function dsio is useful for filtering out investments with events (such as mergers or acquisitions) in their recent history that would perhaps make the values of other fields not useful or meaningful. For example, the command fragment

... field2=dsio field3=rrs:5,42 ... step2=field2al47 step3=field3tn20 ...causes backtest.exe to first filter out investments that have been open for less than 47 market days before selecting investments on the basis of field3, which requires 47 market days of open history in order to avoid rrs computations that straddle events, if one so desires.
dsp: A field function that assigns to the calling field the number of market days that each investment has been held since purchase. Its syntax is as follows:

dsp

As shown, the function dsp takes no arguments. For each investment not owned, dsp assigns the value 0 to the calling field. For each investment owned, dsp assigns the number of market days the investment has been owned to the calling field. Note that the value assigned for each investment is dependent on the variant being tested if either automatic or manual parameterization is used in the backtest command.
dspo: A field function calculating the number of market days since actual pricing began for each investment's underlying stock. Its calling syntax is as follows:

dspo

As shown, the function dspo takes no arguments. For each investment, the function dspo subtracts the ordinal of the market date on which actual pricing (as distinguished from g-prices) began for its underlying security from the ordinal of the current trading date and assigns the difference to the calling field. Since only liquid investments (i.e., investments with actual princes on the current trading date) are included in the universe of investments available for screening, a meaningful non-negative integer is always returned.

The field function dspo is useful for filtering out investments whose underlying stock has perhaps not been trading long enough for the values of other fields to be useful or meaningful. For example, the command fragment

... field2=dspo field3=rrs:5,42 ... step2=field2al47 step3=field3tn20 ...causes backtest.exe to first filter out investments whose actual pricing history is less than 47 market days before selecting investments on the basis of field3, which requires 47 market days of actual pricing history in order to avoid rrs computations that use the history of parent companies or interpolated g-prices, if one so desires.
dv253.a: A field file containing [Actual Dividend 253d] (in dollars per share) for each investment as determined from the source of daily pricing data.

For each investment on the current trading date, the value stored in dv253.a, represented by DIV, is calculated as follows: first, DIV is initialized to dv253.a's default value of 0. Records of all the investment's ordinary cash dividends whose ex-dividend dates are no later than the current trading date are selected. Each dividend amount is appropriately adjusted for any splits that occurred since its ex-dividend date so that all dividend amounts are expressed in dollars per share as of the current trading date. For each dividend record whose ex-dividend date is no more than 252 market days prior to the current trading date, DIV is increated by its dividend amount.

It is assumed that dv253.a will be used for calculating annual dividend yields using the field function aprc, with which dv253.a is commensurable.
eg5.v: A field file containing [EPS Growth 5-Year] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [EPS Growth 5-Year] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by eg5.v is 19860106.

Since VLIS 3.0, Value Line has represented null values in [EPS Growth 5-Year] with zeros, thereby making it impossible for current investors to distinguish between companies with zero [EPS Growth 5-Year] and those whose [EPS Growth 5-Year] is unknown or not meaningful. Thus, [EPS Growth 5-Year] has been regularized in eg5.v by replacing null values with zero values prior to VLIS 3.0.

The default value for eg5.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with zero or undefined [EPS Growth 5-Year] are not distinguishable on the basis of eg5.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in eg5.v.
eligible: Passing previous screening steps (said of investments). More precisely, an investment is said to be eligible at step0 if it is liquid and open for purchase on the current trading date; an investment is said to be eligible at stepn+1 if it passed stepn. Investments passing the final step are said to be eligible for purchase. Investments passing step_ref in the HTD condition <step_ref><step_condition> are said to be eligible for its step condition <step_condition>. If an HTD condition consists only of <step_condition>, then all investments are said to be eligible for its step condition <step_condition>.
elqw.v: A field file containing a regularized version of [% EPS Chg from Last Qtr] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [% EPS Chg from Last Qtr] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by elqw.v is 19860106.

Value Line's [% EPS Chg from Last Qtr] field, unfortunately, has been frought with irregularities over its history. One of those irregularities has been the field's name itself: the current name, [% EPS Chg from Last Qtr], is very misleading: contrary to what this name might suggest, the field provides the most recently reported quarterly EPS results as a percentage of the EPS results from the same quarter of the previous year, not the percentage change in EPS results over the most recent consequtive two quarters. Thus, backtest.exe uses the more descriptive name [VL % EPS Chg vs Yr Ago (Regularized)] in sumfile.

While the field's concept is easy enough to describe, calculating it raises a few issues:

1. Whether negative EPS values are allowed in the computation of percentage change. (When VL allows negative values at all, it allows either or both quarters' values to be negative.)
2. Whether field values are capped (replaced by nulls if exceeding a value), and if so, at what level.
3. Whether a distinction is made between zero values and null values.

Value Line has dealt with these issues in three different ways. VS+ and VS3 (1986 to 1996) required positive EPS figures, capped percentages at 1000% and distinguished between zero and null field values. VLIS 2.0 capped percentages at 300% and provided no distinction between null and zero field values. It started out allowing negative EPS figures, but in May of 1999 VLIS 2.0 reverted to the VS+/VS3 practice of requiring both EPS figures to be positive. No changes on these issues were made in the transition from VLIS 2.0 to VLIS 3.0, nor have there been any changes since VLIS 3.0.

The data in elqw.v has been mostly regularized: First, from 1986 to 1996, Value Line's 1000% cap remains in effect, but from 1997 forward, Value Line's 300% cap has been removed (allowing arbitrarily large percentage values) through use of other Value Line fields within the trailing 13 weekly issues. (A description of how this is done is beyond the scope of this glossary entry.) Second, zero values (representing no change in EPS) have been reconstructed for VLIS 2.0 and VLIS 3.0 using the same methods as those just referred to. Third, values based on negative EPS figures for one or both quarters are replaced with nulls. Finally, nulls are in turn replaced with -HUGEVAL; that is, the default value for elqw.v is -HUGEVAL.
end: (1) ('end') The leading substring of the optional argument in a backtest command [blend command] specifying the market date on which final portfolio values are determined and performance measurement ends for all cycles when reporting results in sumfile. The syntax for the end argument is as follows:

end=<yyyymmdd>

where yyyymmdd is an integer representing a valid market date.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in end (2). If end (2) is omitted, then backtest.exe [blend.exe] sets end to end_max and reports this default setting through stdout. If end is later than end_max, then backtest.exe [blend.exe] adjusts end to end_max and reports the adjustment (with a brief explanation) through stdout. If end is not a valid market date or if the interval of market dates [start, end) does not contain hold number of market dates, then backtest.exe [blend.exe] reports an invalid end argument through stdout.
end_max: (1) For a given backtest command, the last market date on which the specified strategy is able to select investments for purchase due to either the discontinued availability of required field file data, as indicated in field file headers, or to the upper bound on the backtesting period supported by daily pricing data, as indicated in date_index.dat. The value of end_max is independent of any parameter values, though it is affected by use of the field function pref.

(2) For a given blend command, the last market date on which all strategies comprising the blend are able to select investments for purchase, as indicated in the header of its corresponding cache file. If the comprising strategies have no intersecting interval of tradability, then end_max is undefined and the blend command cannot be executed. Otherwise, the value of end_max is simply equal to the minimum value of end_max (1) found among all cache files named in arguments.
eng.e: A field file containing Engine Ratings as published by ValuEngine. The data is based on monthly snapshots of the ratings taken on the third Thursday of each month from January 1990 through April 2002. With zero lag, ratings become effective on the first market date following the third Thursday of each month and remain in effect until the ratings for the next month become effective. Investments not rated by ValuEngine (with a rating of 1, 2, ... 5, where 5 is the most favorable rating) receive ratings of 0.
EPL: See Event-Partition Linearization.
et: ('et') A comparison code signifying the selection of investments whose field value is equal to a comparison value. That is, the step condition

field<field_number>et[<comparison_value>|<param_ref>]

selects all eligible investments whose value in field<field_number> is equal to comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested. The comparison code et can also be used to check for equality to any one among several comparison values (any of which may be parameterized) by separating them with the character '!', which functions as "or". For example, the step argument

step3=field2et2!param2!3
selects all eligible investments whose value in field2 is either 2, 3, or the value referred to by param2 for the variant being tested.

Since all comparisons are made using 32-bit floating point representations, the comparison code et should be used with caution due to floating point imprecision.
event: See Event-Partition Linearization.
Event-Partition Linearization (EPL): A type of linearization in which certain events (marked by critical dates) that would otherwise thwart linearization, such as suspensions, mergers, acquisitions, spin-offs, etc, are used to partition each stock's history into characterization periods. A stock's complete history is then separately linearized from the standpoint of a hypothetical investor within each of its characterization periods, allowing a stock's prospective and retrospective daily total returns to depend upon the point of reference, as is the case in reality. Strictly speaking, EPL only becomes a type of linearization when one organizes the database by the narrower concept of investment instead of by conventional stock identifiers like CUSIP, ticker symbol, etc because EPL results in more than one record per stock per date.
exp: A field function raising e to a specified field's values. Its syntax is as follows:

exp:<field_ref>

As shown, the function exp takes a field reference as its single argument. For each investment, the function exp raises e to the investment's value in the field referenced by field_ref and assigns the result to the investment's corresponding value in the calling field.
field: (1) ('field') The leading sub-string of an argument in a backtest command that generates a column of numeric values (one value for each investment) according to which investments may be sorted and selected via step arguments. The syntax for field arguments is as follows:

field<field_number>=[<filename>[:<lag_days>]|<function_name>[:<argument1>[,<argument2>...]]]

field_number is a non-negative integer. Every backtest command requires exactly one field argument with field_number equal to 0. Field arguments may be entered in any order, but the set of field numbers used in a command must not skip any number. For example, if field5= appears somewhere in a command, then field4= must appear somewhere in the command as well.

If filename is provided, it specifies the name of a field file or signal file from which the field's values are retrieved; lag_days is a non-negative integer that determines how many market days back from the current trading date the backtester should go in seeking values from the field file specified by filename. lag_days cannot be parameterized.

Otherwise, function_name must be provided along with any arguments the named field function requires; see field function for more details.

(2) The entire argument referred to in (1).

(3) The memory array itself that contains the column of values referred to in (1) .
field file: A custom binary data file containing values according to which investments may be sorted and selected in a backtest. Field files can be recognized by their single-character extensions indicating their source. Files distributed with backtest.exe that have multi-character extensions, such as gprc.dat, are not field files and should not be specified by field arguments (doing so should produce an error message). The naming of field files loosely follows the field abbreviations used by Jamie Gritton's Screen Builder at backtest.org. For example, tim.v contains Value Line Timeliness ranks.

Every field file begins with a 13-byte header in which the first byte indicates the data's type (which can be either a standard C++ type or a custom type) by a 1-byte character, the earliest market date of availability by a 4-byte integer, the first market date of unavailability (after availability) by a 4-byte integer, and the default value for the field by a 4-byte floating point number. Following the 13-byte header is a description (in ASCII) of the field enclosed in brackets and terminated by the null character; following that is the field data in binary form.

A field file's availability dates contained in its header are used to adjust the arguments start and end if they enclose an interval of market dates that extends outside the field file's interval of availability; any such adjustments are reported by backtest.exe through stdout.

Regardless of a field file's data type, its values are converted to standard 4-byte floating point representations as they are read into arrays. Thus step arguments that check for strict equality or inequality should be avoided except in cases of comparing integers that aren't too large (checking equality to integers as large as 10,000, such as Value Line Industry Codes, appears to be safe). In any case, the safety of specific equality and inequality comparisons can be easily tested by running carefully crafted backtest commands (see et).
field function: A function for calculating field values at backtest command execution time. The syntax for a field argument that "calls" a field function is as follows:

field<field_number>=<function_name>[:<arg_1>[,<arg_2>...]]

See the glossary entry for field for a description of field_number. The field represented by field<field_number> is referred to as the calling field.

function_name is the same string of characters by which field functions are referred to in this glossary. The field functions currently available are the fields designated "field function" under "Type" in the table found here. See each field function's glossary definition for more details.

If required, arg_1, arg_2,... can be either field references, parameter references or decimal representations of numbers, depending on the function. If a field function's argument is a field reference, then field_number must be greater than the field number of the referenced field. This requirement prevents circular field references.

backtest.exe also accepts field function arguments enclosed in parentheses instead of separated from function_name by a colon. Using parentheses, however, will cause most shells to interpret the rest of the argument string as a shell command instead of passing the entire string as an argument to backtest.exe.

Calls to field functions cannot be nested.
field reference: A string of the form

field<field_number> ,

where field_number is a non-negative integer, used to label fields for definition, to reference fields in step conditions and to reference fields as arguments in field functions.
forward interpolation: Coming soon!
free leverage: Coming soon!
friction: (1) ('friction') The leading sub-string of the optional argument in a backtest command specifying the total return (in multiplier form) applied to all sale proceeds in order to account for round-trip trading costs (friction). The syntax for the friction argument is as follows:

friction=<friction_multiplier>

where friction_multiplier is a decimal representation of a positive number not greater than 1.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in friction (2). If friction (2) is omitted from a backtest command, then backtest.exe sets friction to 1 and reports this default setting through stdout. A friction value of 1 is equivalent to assuming no trading costs. The value of friction becomes particularly important with small values for hold because in such cases, the default value of 1 simulates no-cost frequent trading. It is also recommended that friction be adjusted appropriately when backtesting over earlier time periods. Otherwise, favorable backtest results may reflect exploitation of anomalous and false arbitrage opportunities the market allowed to exist merely because of the higher trading costs of the time, not the predictable market inefficiencies we seek in backtesting.

(4) ('friction') The leading sub-string of the optional argument in a blend command specifying the total return (in multiplier form) applied to all sale procedes in order to account for round-trip trading costs (friction). The syntax for the friction argument is as follows:

friction=<friction_multiplier>

where friction_multiplier is a decimal representation of a positive number not greater than 1.

(5) The entire argument referred to in (1).

(6) The variable holding the value specified in friction (2). If friction (2) is omitted from a blend command, then blend.exe sets friction to 1 and reports this default setting through stdout. A friction value of 1 is equivalent to assuming no trading costs. The value of friction becomes particularly important with small values for hold because in such cases, the default value of 1 simulates no-cost frequent trading. It is also recommended that friction be adjusted appropriately when backtesting over earlier time periods. Otherwise, favorable backtest results may reflect exploitation of anomalous and false arbitrage opportunities the market allowed to exist merely because of the higher trading costs of the time, not the predictable market inefficiencies we seek in backtesting.
.g: A field file extension indicating that the file's values are derived entirely from gprc.dat.
gprc: A field function retrieving each investment's unsigned closing g-price a specified number of market dates previous to the current trading date. Its syntax is as follows:

gprc:[<lag_days>|<param_ref>]

As shown, the function gprc takes a single argument that is either a number or parameter reference. The value of this argument must be a non-negative integer at most the retrospective limit. For each investment on market date d, gprc retrieves its unsigned closing g-price from gprc.dat for the market date d - lag_days (or d decremented by the value referenced by param_ref for the variant being tested) and assigns it to the calling field. Since g-prices, by themselves, are meaningless due to their arbitrary scaling, fields populated with the field function gprc are only commensurable with other fields containing g-prices such as those populated with hgprc, lgprc or pgrpc. If meaningful prices are desired, then use the field function aprc or a vendor-specific pricing field function that is commensurable with related fields.

Note that if lag_days is zero, then the closing g-prices returned by gprc are those of the current trading date, and thus the same g-prices at which trades take place.
g-prices: Daily adjusted closing prices derived from GTR1 data. An investment's closing g-price on a given market date is defined as the product of its daily total returns in multiplier form (TR1) from its earliest GTR1 data record date through the given market date. Since GTR1 Linearization defines TR1 values as negative on suspension dates and resumption dates, g-prices are negative during suspension periods, which is how backtest.exe determines whether an investment is liquid for purchase or sale.

GTR1 Linearization also ensures that for any given stock on a given market date, the corresponding investment's g-prices correctly reflect all past and future splits, dividends, spin-offs, mergers, acquisitions, liquidations, post-delisting sales and interest on any cash proceeds from such events. Cash dividends are reinvested on ex-dividend dates, while all stock distributions are passively held until a change of investment ID is allowed at the next trading date in a backtest. Note that since g-prices are arbitrarily scaled, they are only meaningful when compared with other g-prices for the same investment.

Finally, since GTR1 Linearization theoretically defines an investment's daily retrospective total returns indefinitely into the past, g-prices are themselves defined indefinitely into the past for each investment as well, though in practice they are computed no earlier than the first market date covered by the data source.
grpc.dat: The file containing g-prices for all investments, essential to backtest.exe for calculating prospective total returns and calculating values for most field functions. For each investment, it is guaranteed to contain g-prices on all consecutive market dates from the retrospective limit'th market date preceding the investment's opening date through the first market date the investment is liquid on or after the prospective limit'th market date counted forward from the investment's closing date.
GSD(): Geometric Standard Deviation of total returns as calculated (by either backtest.exe or blend.exe) with rskintvl=p for each cycle of each variant.

GSD(p) is calculated as follows: first, the sequence of n market date intervals (start + 0p, start + 1p], (start + 1p, start + 2p], ... (start + (n - 1)p, end] is defined, where n is the smallest integer greater than or equal to (end - start)/p. The n total returns (obtained by dividing portfolio values at interval endoints) over the sequence of intervals are then calculated and their logarithms are taken, resulting in a sequence of n "log-returns".

The average log-return is defined as the natural logarithm of the portfolio's total return from the close of start to the close of end, divided by (end - start)/p.

Next, the differences between the first n - 1 log-returns and the average log-return are then squared and summed. For the final interval, the average log-return is re-scaled by multiplying it by the ratio (which may be 1) of the final interval's length (in market days) to p. The difference between the final log-return and the re-scaled average log-return is then squared and added to the sum.

Finally, the sum of squared differences is divided by (end - start)/253 (where 253 is the average number of market days in a year), the square root is taken, the inverse natural logarithm is taken and the resulting multiplier is converted to a percentage (i.e., multiplied by 100 after subtracting 1), giving GSD(p).
gt: ('gt') A comparison code signifying the selection of investments whose field value is greater than a comparison value. That is, the step condition

field<field_number>al[<comparison_value>|<param_ref>]

selects all eligible investments whose value in field<field_number> is greater than comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested.
gtoa.a: A field file containing a multiplier for each investment used to convert its unsigned closing g-price to its underlying stock's actual closing price. Since the field function aprc (which uses gtoa.a) exists for directly assigning actual price to fields, gtoa.a's main purpose is detecting and correcting for stock splits in calculating products and ratios among fields with differing lags (see lag for an example of this usage). However, gtoa.a cannot be used to distinguish between splits and other distributions such as ordinary dividends.

Since g-prices are alway defined and since investments are required to have a non-zero actual closing price in order to be eligible on a given market date, values in gtoa.a are always defined and positive for eligible investments. Thus no default value for gtoa.a need be defined.
gtov.v: A field file containing a multiplier for each investment used (primarily by the field function vprc) to convert its daily closing g-price to its underlying stock's daily closing Value Line-adjusted price.

Multipliers are based on the stock prices found in monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and in weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. The multiplier is defined on a given market date for each investment as its last Value Line-reported closing price divided by the investment's closing g-price from the same market date as that of the reported price. With zero lag, multipliers are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by gtov.v is 19860106.

Eligible investments either not covered by the electronic version of the Value Line Investment Survey or with no reported price therein are defined to have zero values in gtov.v. Note that this means that the approximately 60 securities missing from VS+ and VS3 on any given market date have zero values in gtov.v (and thus zero values for vprc). Thus neither gtov.v nor vprc should be used to restrict a backtest to Value Line stocks; instead, tim.v or incd.v should be used.
GTR1 Linearization: A type of Event-Partition Linearization specified by myself, Robert Geary, in the document GTR1v006.pdf. See MI post xxxxxx for its key features.
GTR1 data: The CSV text files of prospective and retrospective 1-day total returns (TR1) on investments produced by GTR1Linearizer.exe.
GTR1Linearizer.exe: A Windows application, written in C++ by TechCzech from fool.com's Mechanical Investing message board, that performs GTR1 Linearization on daily stock databases that resemble CRSP's daily database of US stocks.
hgprc: A field function calculating the highest unsigned closing g-price for each investment over a specified interval of market dates. Its syntax is as follows:

hgprc:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function hgprc takes two arguments, each of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function hgprc calculates its maximum unsigned closing g-price over the period consisting of rs_days (or the value referenced by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value referenced by param_ref_1 for the variant being tested) number of market days before the current trading date and assigns it to the calling field.

Note that if lag_days is zero, then highest closing g-price is measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place. Also note that since hgprc returns g-prices, it is only commensurable with other field functions that return g-prices such as gprc, pgprc and lgprc, and any field files whose values are also g-prices.

By default, a meaningful highest g-price is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out stocks with inadequate actual pricing history for a conventional maximum price computation over the full period, use the field function dsio or dspo.
hold: (1) ('hold') The leading sub-string of the optional argument in a backtest command specifying the common fixed holding period among all cycles of all variants in a backtest. The syntax for the hold argument is as follows:

hold=<hold_days>

where hold_days is a positive integer no greater than the prospective limit.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in hold (2). If hold (2) is omitted from a backtest command, then backtest.exe sets hold to 20 and reports this default setting through stdout (see holding period for an explanation of why 20 is used by default). In addition to specifying the holding period, hold determines the number of cycles created for each variant in executing a backtest command.

(4) In the execution of a blend command, the least common multiple of the holding periods of the blended strategies.
holding period: Generally, the length of time between trading dates for a cycle. In the backtests performed by backtest.exe, holding periods are always a fixed number of market dates (specified by hold) regardless of where during the week, month or year the resulting trading dates happen to fall. This usually means, for example, that no cycle trades on Friday, during the "Superior Six" days of the month, or in January, significantly more than any other cycle, thereby leaving pure "noise" as the only likely explanation for cycle variation. A default holding period of 20 market dates is used by backtest.exe because it approximates the length of a month (the typical default holding period used by other backtesters) while still randomizing each cycle's trading dates on the calendar very well.
htd: (1) ('htd') The leading sub-string of the optional argument in a backtest command specifying an HTD condition. The syntax for the htd argument is as follows:

htd=<htd_condition>

where htd_condition is an HTD condition.

(2) The entire argument referred to in (1). Omitting the htd argument is logically equivalent to including an HTD condition of step<final_step_number>, where step<final_step_number> is a reference to the final step in the backtest command . However, actually entering the argument

htd=step<final_step_number>

will cause backtest.exe to report that the htd argument is redundant and close without completing the backtest.
HTD condition: (1) A string of the form

[<step_ref>][<step_condition>]

where step_ref is a step reference and step_condition is a step condition, one or both of which can be included. step_ref can refer to any step in the backtest command except the last, which would make the HTD condition redundant (see htd). HTD conditions are used in htd arguments to instruct the backtester to hold certain investments already owned, even if they do not pass the final step of the backtest command.

(2) The instruction to the backtester signified by an HTD condition (1), which is as follows:

If <step_condition> is omitted (meaning <step_ref> is included), then the HTD condition instructs the backtester to select all investments passing step_ref for guaranteed continued holding.

If <step_ref> is omitted (meaning <step_condition> is included), then the HTD condition instructs the backtester to apply step_condition to all liquid investments open for purchase on the trading date to select investments for guaranteed continued holding.

If both <step_ref> and <step_condition> are included, then the HTD condition instructs the backtester to apply step_condition to all investments passing step_ref to select investments for guaranteed continued holding.
if: A field function that assigns, for each investment, one of two possible return values to the calling field according to whether the investment satisfies an absolute step condition. Its syntax is as follows:

if:<absolute_step_condition>,[<true_field_ref>|<true_param_ref>|<true_decimal_expr>],[<false_field_ref>|<false_param_ref>|<false_decimal_expr>]

As shown, the function if takes three arguments: the first of which, absolute_step_condition, is an absolute step condition (whose comparison value may be parameterized); the second of which is either a field reference, a parameter reference or a decimal expression; and the third of which is likewise either a field reference, a parameter reference or a decimal expression. Each investment is separately tested against absolute_step_condition: if it passes, then the value referenced by the second argument is assigned to the calling field; otherwise, the value referenced by the third argument is assigned to the calling field. For example, the backtest command argument

field4=if:field3am7,param0,field2
assigns, for each investment, the value referenced by param0 to the calling field if the investment's value in field3 is at most 7, or the investment's value in field2 otherwise.
incd.v: A field file containing [Industry Code] as used in the Value Line Investment Survey. A table showing Industry Names and date ranges for each [Industry Code] value is provided.

The four-digit [Industry Code] appeared explicitly in Value Screen Plus and Value Screen 3, but beginning with VLIS 2.0 (1997), [Industry Code] can only be deduced for each security using its abbreviated Industry name. This is possible because each industry has its own row in the data table; abbreviated Industry name appears in the same column where it appears for securities, while the four-digit [Industry Code] appears under [Ticker Symbol].

VLWRP reconstructed weekly industry classifications ([Industry Name], [Industry Code] and Issue of coverage in Ratings & Reports) for all securities covered by the paper edition of the Value Line Investment Survey from 1986 through February 1998, including all securities excluded by VS+ and VS3. This work was merely to serve as the foundation for weekly reconstruction of other Value Line fundamental data fields (those that change according to industry coverage in Value Line's Ratings & Reports), but [Industry Code] has its own important uses, such as ensuring that a backtest represents a uniform strategy over time, in spite of changes between versions of the Value Line Investment Survey.

Investments covered by the Value Line Investment Survey but not assigned to an industry (either in the paper or electronic versions) receive a default field value of 9991 in incd.v, a code that has been used by Value Line for the same purpose in the past. Investments not covered at all by the Value Line Investment Survey (paper or electronic) receive a distinct default value of 9999 from incd.v. Thus the command arguments

field0=incd.v step0=field0lt9999
are one general means of restricting a backtest to the Value Line universe from 1986 through the present.

With zero lag, [Industry Code] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by incd.v is 19860106.
incommensurability: See commensurability.
inr.v: A field file containing [Industry Rank] as published in the Value Line Investment Survey.

The field file inr.v contains weekly [Industry Rank] values from January 3, 1986 through the present end of the database. Investments with undefined [Industry Rank] (either because they were not covered by Value Line or were covered but not ranked by Value Line) receive the default value of 9999 in inr.v. With zero lag, [Industry Rank] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by inr.v is 19860106.

From 1986 through February 1998, weekly [Industry Rank] was reconstructed by VLWRP by taking the average [Timeliness Rank] among the ranked stocks within each industry, sorting the industries in ascending order by their average [Timeliness Rank] values and numbering them from 1. This required the weekly reconstruction of [Industry Code], as found in incd.v, in order to correctly sort stocks into Value Line industries, including those excluded from Value Screen Plus and Value Screen 3.

From March 6, 1998 (the beginning of weekly archives of VLIS 2.0) through the present, inr.v contains the actual weekly Industry Ranks calculated by Value Line themselves in the manner just described.
int: A field function truncating another field's values to integers. Its syntax is as follows:

int:<field_ref>

As shown, the function int takes a field reference as its single argument. For each investment, the function int truncates its corresponding value (as a decimal expression) in the field referenced by field_ref to an integer and assigns it to its corresponding value in the calling field. For example, if an investment's value in the field referenced by field_ref is -5.84, then int assigns -5 to the investment's corresponding value in the calling field.

Note that only sufficiently small integers have exact 32-bit floating point representations in the C++ data type float that backtest.exe uses for all fields. The field function int is implemented by statically casting values in the referenced field to integers and then implicitly casting the integers back to float when assigning them to the calling field.
interpolation: Coming soon!
investment: In the context of EPL, an ordered pair (P, [a, b)), where P is a security identifier and [a, b) is a characterization period for the security. Intuitively, an investment is a security purchasable within a certain sub-interval of its pricing history.
irregularity: A variation, such as in units, ranges, or null-handling, in the way a data field was calculated or reported by a vendor (such as Value Line) over part of the field's archived history. Irregularities, if not corrected by regularization or handled in backtest commands, can render backtests invalid.
lag: Broadly speaking, the number of market days by which a field value's date of calculation or date of release by a data vendor precedes a trading date. Note that this concept of lag applies to individual fields separately, and is therefore distinguished from the more conventional concept of "lag" in backtesting--a number of market dates by which trades are delayed after investments are selected for sale and purchase. More precisely, lag refers to:

(1) For field files, the number of market days by which backtest.exe decrements the current trading date for the purpose of joining investments to their field values. Lag is specified for a field file by appending it to its filename with a colon (see field file). For example, the backtest command argument

field3=tim.v:4
instructs backtest.exe to populate field3 with the [VL Timeliness Rank] values that were effective for trading four market days ago.

Note that even with a specified lag of zero, there may still be some degree of lag present between field calculation or publication and the close of the current trading date when trades are made. For example, the Value Line field [VL Timeliness Rank] is published on Friday evenings, but with a lag of zero specified for tim.v, rank values are not effective for trading until the close of the next market date (the following Monday, if it is not a holiday). Thus if the current trading date is a Friday, then the values in tim.v:0 will be a full week old. See each field file's glossary entry for details on any inherrent lag present field a specified lag of zero.

Field files can be lagged independently of each other, though care must be taken to maintain commensurability if they are combined in calculations. To see how lagging fields by differing amounts can make them incommensurable, consider the following command fragment that represents an attempt to measure volume momentum:

field0=av21.a:0 field1=av21.a:10 field2=ratio:field0,field1
Here, field2 is equal to average daily volume over the last 21 market days divided by average daily volume over the 21 market days ending 10 market days ago. While these arguments are perfectly acceptable to backtest.exe, the construction of field2 is conceptually flawed. If a stock has split 2-for-1 within the last two weeks, the ratio will be inflated by a factor of 2, because av21.a:10 is not automatically adjusted for the split. To correct for splits, use the field gtoa.a as follows:

field0=av21.a:0 field1=av21.a:10 field2=gtoa.a:0 field3=gtoa.a:10 field4=ratio:field0,field1 field5=ratio:field2,field3 field6=product:field4,field5
Now, if a stock has had a 2-for-1 split within the last two weeks, field5 will have a value of 0.5 for that stock, thus correctly canceling out the doubling of field0 as a result of the split.

Note that lagging a field file can cause investments that would otherwise have meaningful field values to instead receive the field file's default value. This is because backtest.exe, in seeking back the specified number of market days, may seek past an investment's opening date, before which field file values are not defined. Consequently, field file lag is currently limited to 20 market days in order to prevent untintended distortions caused by this phenomenon.

Finally, each day of lag specified for a field file increases both the earliest possible start and the latest possible end supported by the field file. For this reason, it is not possible for field file lag to be parameterized, since backtest.exe requires all variants to be tested over the same interval of market dates.

(2) For signal files, a number of market days by which backtest.exe seeks back from the current trading date for a signal value. Unlike field file lag, signal file lag does not affect start or end, can be parameterized and is limited in degree only by the retrospective limit. If a specified lag value causes backtest.exe to seek beyond the signal file's first record, then backward interpoloation is used.

(3) For field functions, certain lag arguments may be accepted: see each field function's glossary entry for details. Arithmetic field functions such as linear, product and ratio do not directly accept lag arguments, but such fields can be considered "lagged" if the referenced fields, if any, are lagged.

The two-argument versions of pricing functions such as aprc exist for the purpose of generating prices that are commensurable with other fields lagged by different amounts. For example, if one wishes to compute market capitalization using shares outstanding with a lag of 2 and price with a lag of 5, this can be done as follows:

field0=sho.a:2 field1=aprc:2,5 field2=product:field0,field1
The quote_lag value of 5 for aprc produces prices that are lagged by the desired 5 market days, and since the lag of 2 for sho.a matches the share_lag value of 2 for aprc, field0 and field1 are commensurable.
lgprc: ('lgprc') A field function calculating the lowest unsigned closing g-price for each investment over a specified interval of market dates. Its syntax is as follows:

lgprc:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function lgprc takes two arguments, each of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function lgprc calculates its lowest unsigned closing g-price over the period consisting of rs_days (or the value referenced by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value referenced by param_ref_1 for the variant being tested) number of market days before the current trading date and assigns it to the calling field.

Note that if lag_days is zero, then lowest closing g-price is measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place. Also note that since lgprc returns g-prices, it is only commensurable with other field functions that return g-prices such as gprc, pgprc and hgprc, and any field files whose values are also g-prices.

By default, a meaningful lowest g-price is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out stocks with inadequate actual pricing history for a conventional minimum price computation over the full period, use the field function dsio or dspo.
linear: A field function calculating a linear combination (a.k.a. a weighted sum) among one or more fields (and optionally, the number 1) for each investment. Its syntax is as follows:

linear:[<coefficient_value_1>|<param_ref_1>],[1|<field_ref_1>][,[<coefficient_value_2>|<param_ref_2>],[1|<field_ref_2>]...]

As shown, function linear takes an even number of arguments that alternate between coefficients (either constant values or parameter references) and field references (or the number 1). For each investment, the function linear calculates the linear combination of fields in which each field referenced in the argument list is multiplied by the coefficient appearing immediately to its left and the sum is assigned to the calling field.

The function linear can be used to perform addition and subtraction by choosing appropriate coefficients (all 1's for addition and a 1 and -1 for subtraction). The option to specify the number 1 in place of a field reference is provided so that constants can be included in sums and differences. For example, in the command fragment

field0=trp:0,126 field1=trm:0,126 field2=linear:100,field1,-100,1
field2 receives the value 100*trm:0,126 - 100, which is equal to 126-day total return in percentage form. Thus field2 and field0 equivalent.
linearization: The general process or a particular method of putting a daily stock database into a linearized state.
linearized: Descriptive of a daily stock database wherein each stock's daily history is stored as a single-valued function of market date. For example, Yahoo! Finance's historical daily adjusted closing prices form a linearized database of stock market history (albeit with survivorship bias and other problems). On the other hand, actual closes accompanied by dividend and split information do not constitute a linearized database because a stock's daily history has multiple pieces of information associated with each market date. Linearized databases are desirable for the computational simplicity involved in calculating prospective and retrospective total returns and other technical measurements at backtester run-time. In the case of Yahoo! Finance, for example, total returns are calculated by simply dividing two adjusted closing prices; reference to dividend and split information is not necessary.
ln: A field function that calculating the natural logarithms of another field's values. Its syntax is as follows:

ln:<field_ref>

As shown, the function ln takes a field reference as its single argument. For each investment, the function ln first checks that its corresponding value in the field referenced by field_ref is positive. If so, then it takes the field value's natural logarithm and assigns it to the investment's corresponding value in the calling field; otherwise it assings the value 0.
lt: ('gt') A comparison code signifying the selection of investments whose field value is less than a comparison value. That is, the step condition

field<field_number>al[<comparison_value>|<param_ref>]

selects all eligible investments whose value in field<field_number> is less than comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested.
ltd.v: A field file containing a regularized version of [Long-Term Debt] (in millions of dollars) as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen 3 and VLIS 2.0 from December 2, 1988 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Long-Term Debt] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by ltd.v is 19881205.

Value Line's [Long-Term Debt] field, unfortunately, has been subject to some irregularities over time: First, VS3 assigned zero values instead of nulls to companies with unknown or undefined long-term debt figures, thereby making it impossible to distinguish the most desirable values (indicating no long-term debt) from meaningless values.

With the arival of VLIS 2.0 in 1997, Value Line made two changes: first, the industries formerly excluded from the electronic version of Value Line (see Value Screen 3) were added to VLIS 2.0, and second, Value Line began replacing zeros in [Long-Term Debt] with nulls. The second change perpetuated the problem of ambiguous representations of zero values and nulls, but the first change exacerbated the problem by increasing the number of stocks belonging to industries for which long-term debt is usually not defined, making zero long-term debt filters even less reliable.

Toward the end of 1997, Value Line solved the problem by using zeros in [Long-Term Debt] to signify no long-term debt and nulls to signify companies for which long-term debt is undefined. However, in VLIS 3.0, Value Line reverted to using zeros to represent both no long-term debt and undefined long-term debt, meaning the original problem has returned. For this reason, ltd.v has been regularized by setting its default value to zero, meaning that companies with no long-term debt and those for which long-term debt is uknown or undefined are indistinguishable on the basis of ltd.v for the entire length of the backtesting period.

For the purpose of screening for companies with no long-term debt, note the following: During the period when Value Line distinguished between zero values and null values in [Long-Term Debt] (VLIS 2.0 after 1997), there is not a single instance of a company with a null value in [Long-Term Debt] and a positive value in [Total Assets], and over the same period there are only a few instances of companies with non-null values in [Long-Term Debt] and null values in [Total Assets]. Therefore, it appears that requiring [Total Assets] (whose default value is zero) to be positive and [Long-Term Debt] to be zero should do a near perfect job of identifying stocks (and only those stocks) whose [Long-Term Debt] is meaningfully zero.
market date: (Also market day.) A date on which the US stock market was open for trading, represented in the form yyyymmdd. If n is an integer, the notation yyyymmdd + n signifies incrementation of the market date yyyymmdd by n market dates, and yyyymmdd - n signifies decrementation of yyyymmdd by n market dates. If YYYYMMDD is another market date ealier than yyyymmdd, then the notation yyyymmdd - YYYYMMDD signifies the integer n such that YYYYMMDD + n = yyyymmdd.
market date.: See market day.
max: A field function calculating the maximum value among a collection of fields, parameters and constant values. Its syntax is as follows:

max:[<field_ref_1>|<value_1>|<param_ref_1>][,[<field_ref_2>|<value_2>|<param_ref_2>]...] ,

where field_ref_1, field_ref_2, ... are field references, value_1, value_2, ... represent decimal values, and param_ref_1, param_ref_2, ... are parameter references. The field function max calculates, on a per-investment and per-variant basis, the maximum among the associated values and assigns it to the calling field. For example, the command argument

field3=max:field2,param0,5causes backtest.exe to calculate, for each investment and each variant, the maximum value among the three numbers consisting of the investment's value in field3, the variant's corresponding value in param0, and the number 5. It does not calculate a global maximum over all values in a field or all values taken on by a parameter.
mcpp.a: A field file storing each investment's full-market, ascending-order percentile rank by market capitalization.

Values in mcpp.a are calculated as follows: on each market date, actual closing price (as returned by aprc) is multiplied by actual shares outstanding (as stored in sho.a), thus producing "market capitalization" (see comments under sho.a on why these values can understate company market capitalization). Investments are then sorted in ascending order by market capitalization (tie-breaking is unspecified). Beginning with 0 assigned to the investment with the smallest non-zero market capitalization, percentile ranks are assigned to investments, incrementing by 100/N, where N is the number of investments with non-zero market capitalization, until 100*(N - 1)/N is assigned to the investment with the largest market capitalization. Finally, a default value of 0 is assigned to all investments with zero market capitalization (which exist due to missing shares outstanding values).
min: A field function calculating the minimum value among a collection of fields, parameters and constant values. Its syntax is as follows:

min:[<field_ref_1>|<value_1>|<param_ref_1>][,[<field_ref_2>|<value_2>|<param_ref_2>]...] ,

where field_ref_1, field_ref_2, ... are field references, value_1, value_2, ... represent decimal values, and param_ref_1, param_ref_2, ... are parameter references. The field function min calculates, on a per-investment and per-variant basis, the minimum among the associated values and assigns it to the calling field. For example, the command argument

field3=min:field2,param0,5causes backtest.exe to calculate, for each investment and each variant, the minimum value among the three numbers consisting of the investment's value in field3, the variant's corresponding value in param0, and the number 5. It does not calculate a global minimum over all values in a field or all values taken on by a parameter.
mod: A field function calculating a specified field's remainder upon division by a positive number. Its syntax is as follows:

mod:<field_ref>,[<divisor_num>|<param_ref>]

As shown, the function mod takes two arguments, the first a field reference and the second a positive number or parameter reference to such values. For each investment, the function mod first divides the investment's corresponding value in the field referenced by field_ref by divisor_num and truncates the resulting quotient to an integer; the product of divisor_num and the integral quotient is then subtracted from the investment's value in field_ref and the resulting difference (remainder) is assigned to the investment's value in the calling field.
month: A field function calculating the calendar month number, lagged a specified number of market dates from the current trading date. Its syntax is as follows:

month:[<lag_days>|<param_ref>]

As shown, the function month takes a single argument that is either an integer (possibly negative) or parameter reference to integers. The function month first identifies the market date that is lag_days prior to the current trading date (if lag_days is negative, then the determined market date will be later than the current trading date), provided that it does not pass the latest end supported by gprc.dat and that it does not precede the earliest start supported by gprc.dat by more than the retrospective limit. When the identified market date would otherwise exceed one of these limits, it is defined as the earliest or latest (according to whether lag_days is positive or negative, respectively) market date within the limits. Once the lagged market date is identified, the function year assigns the calendar month number (1, 2, ... 12) of the identified market date to the calling field for all investments.

Note that if lag_days is zero, then month determines the month associated with the current trading date.
ne: ('ne') A comparison code signifying the selection of investments whose field value is not equal to a comparison value. That is, the step condition

field<field_number>ne[<comparison_value>|<param_ref>]

selects all eligible investments whose value in field<field_number> is not equal to comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested. The comparison code ne can also be used to check for unequality to all of several comparison values (any of which may be parameterized) by separating them with the character '!', which functions as "and". For example, the step argument

step3=field2ne2!param2!3
selects all eligible investments whose value in field2 is neither 2, 3, nor the value referred to by param2 for the variant being tested.

Since all comparisons are made using 32-bit floating point representations, the comparison code ne should be used with caution due to floating point imprecision.
-nocache: ('-nocache') A command switch accepted by backtest.exe that causes it to operate as if neither the c1 nor c2 cache directories exist. In other words, this switch disables all caching activity (both reading and writing) while executing the backtest command. Upon completion of the command, backtest.exe reports through stdout that it is unable write to each variant's c2 cache file.
nominal suspension: A gap or ending in a stock's pricing history as a result of an inadequacy or error in the original data source. Nominal suspensions are distinguished from actual suspensions.
opening date: The first market date on which an investment is open for purchase; equivalently, the included lower bound of an investment's characterization period.
ord: A field function calculating the calendar day number, lagged a specified number of market dates from the current trading date. Its syntax is as follows:

day:[<lag_days>|<param_ref>]

As shown, the function day takes a single argument that is either an integer (possibly negative) or parameter reference to integers. The function day first identifies the market date that is lag_days prior to the current trading date (if lag_days is negative, then the determined market date will be later than the current trading date), provided that it does not pass the latest end supported by gprc.dat and that it does not precede the earliest start supported by gprc.dat by more than the retrospective limit. When the identified market date would otherwise exceed one of these limits, it is defined as the earliest or latest (according to whether lag_days is positive or negative, respectively) market date within the limits. Once the lagged market date is identified, the function day assigns the calendar day numbner (1, 2, ... 31) of the identified market date to the calling field for all investments.

Note that if lag_days is zero, then day determines the calendar day number associated with the current trading date.
parameter file: A comma, space or tab-separated tabular text file containing values to be substituted for parameter references during execution of a parameterized backtest command. Each row of a parameter file generates a separate variant of the general parameterized strategy: the value in the nth column (where columns are numbered from left to right, starting with 0) of the mth row (where rows are numbered from top to bottom, starting with 0) contains the value substituted for param<n> when backtesting Variant<m>.

Not every column in a parameter file must be referenced within the backtest command, but for every parameter reference, param<n>, appearing in the command there must exist an nth column of values in the parameter file.
parameterization: Combining multiple backtest commands that differ only in comparison values, numerical-valued field function arguments, or certain other elements into a single backtest command by replacing such values with parameter references and specifying a tabular text file of substitution values, called a parameter file, using the paramfile argument. A complete example of parameterization can be found in the glossary entry for variant.
parameterized: Containing parameter references in place of comparison values or numeric field function arguments (said of a backtest command). Parameterized backtest commands require the argument paramfile naming a valid parameter file.
parameter reference: A string of the form

param<n> ,

where n is a non-negative integer, referring to the nth column of values in the parameter file named by the paramfile argument in a parameterized backtest command. There is no relationship between n (the parameter number) and field numbers or step numbers: parameter numbers can be used in any order and may skip values, so long as for each parameter reference, param<n>, appearing in the command there exists an nth column of values in the parameter file.
paramfile: (1) ('paramfile') The leading sub-string of an argument required in a parameterized backtest command specifying a parameter file. The syntax for the paramfile argument is as follows:

paramfile=<param_filename>

where param_filename is a file name.

(2) The entire argument referred to in (1).
pav63p.a: A field file storing each investment's full-market, ascending-order percentile rank by price times average daily volume over 63 market days.

Values in pav63p.a are calculated as follows: on each market date, actual closing price (as returned by aprc) is multiplied by average daily volume over 63 market days (as stored in av63.a), thus producing "dollar volume". Investments are then sorted in ascending order by dollar volume (tie-breaking is unspecified). Beginning with 0 assigned to the investment with the smallest non-zero dollar volume, percentile ranks are assigned to investments, incrementing by 100/N, where N is the number of investments with non-zero dollar volume, until 100*(N - 1)/N is assigned to the investment with the largest dollar volume. Finally, a default value of 0 is assigned to all investments with zero dollar volume (which exist due to missing illiquidity as well as missing volume data).
pcntl: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field, and then, within each group, assigns ascending-order percentile ranks to investments according to their values in another specified field. Its syntax is as follows:

pcntl:<rank_field_ref>,[<group_field_ref>|1],<at_step_ref>,[1|-1]

As shown, the function pcntl takes four arguments: the first of which, rank_field_ref, is a field reference; the second of which is either another field reference, group_field_ref, or the number 1; the third of which, at_step_ref, is a step reference; and the fourth of which is either 1 or -1, indicating whether groups are to be sorted in ascending or descending order, respectively, by values in the field referenced by rank_field_ref. The argument at_step_ref specifies that pcntl be calculated for all investments, and only those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group is then separately sorted by values in the field referemced by rank_field_ref and in the order specified by the fourth argument. Within each group, percentile ranks are then assigned to the calling field, beginning with 0 and incrementing by 100/(# of investments in group), in the sorted order. Finally, the step referred to by at_step_ref is allowed to proceed.
pdg.v: A field file containing [Projected Dividend Growth Rate] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Projected Dividend Growth Rate] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by pdg.v is 19860106.

Since VLIS 3.0, Value Line has represented null values in [Projected Dividend Growth Rate] with zeros, thereby making it impossible for current investors to distinguish between companies with zero [Projected Dividend Growth Rate] and those whose [Projected Dividend Growth Rate] is unknown or not meaningful. Thus, [Projected Dividend Growth Rate] has been regularized in pdg.v by replacing null values with zero values prior to VLIS 3.0.

The default value for peg.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with zero or undefined [Projected Dividend Growth Rate] are not distinguishable on the basis of pdg.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in pdg.v.
peg.v: A field file containing [Projected EPS Growth Rate] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Projected EPS Growth Rate] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by peg.v is 19860106.

Since VLIS 3.0, Value Line has represented null values in [Projected EPS Growth Rate] with zeros, thereby making it impossible for current investors to distinguish between companies with zero [Projected EPS Growth Rate] and those whose [Projected EPS Growth Rate] is unknown or not meaningful. Thus, [Projected EPS Growth Rate] has been regularized in peg.v by replacing null values with zero values prior to VLIS 3.0.

The default value for peg.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with zero or undefined [Projected EPS Growth Rate] are not distinguishable on the basis of peg.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in peg.v.
pgprc: A field function calculating each investment's projected g-price a specified number of market days ahead of the current trading date based on the regression line through the natural logarithms of its unsigned closing g-prices indexed over a specified interval of market dates. Its syntax is as follows:

pgprc:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>],[<proj_days>|<param_ref_3>]

As shown, the function pgprc takes three arguments, each of which can be either a number or a parameter reference. The value of the lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. The value of the third argument may be any number (including negatives and non-integers). For each investment, the function pgprc determines the regression line through the logarithms of its unsigned closing g-prices over the interval consisting of (rs_days + 1) number of consecutive market days ending with the market date that is lag_days number of market days prior to the current trading date. The market dates within this interval are assigned ordinals in chronological order, which are used as abscissa values in plotting the regression line (thus, for example, a Friday is treated as equidistant from the preceding Thursday and following Monday, assuming all weekdays are market days). The regression line is then projected proj_days number of market days ahead of (or behind, if its value is negative) the current trading date, and finally, the corresponding ordinate is exponentiated and assigned to the calling field.

Note that if lag_days is zero, then the regression line is based on data that covers the close of the current trading date, which corresponds to the same g-prices at which trades take place. Also note that since pgprc returns g-prices, it is only commensurable with other field functions that return g-prices such as gprc, hgprc and lgprc, and any field files whose values are also g-prices.

By default, a meaningful projected g-price is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional regression line computation, use the field function dsio or dspo.
ph253.g: A field file containing, for each eligible investment on every market date, current closing g-price divided by highest closing g-price over the last 253 market days (current market day included). This field file is often used as an approximation for price as a percentage of 52-week high, but note that conventional 52-week highs are usually taken over intra-day highs, whereas the highs used to calculate values in ph253.g are taken over closes.

Note that GTR1 Linearization defines each investment's daily closing g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. Thus ph253.g has no default value since a meaningful value is always defined. However, to filter out stocks with inadequate actual pricing history for a more conventional computation of price as a percentage of 253-day high, use the field function dsio or dspo.
pih.v: A field file containing [% Institutional Holdings] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen 3 and VLIS 2.0 from December 2, 1988 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [% Institutional Holdings] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by pih.v is 19881205.

Value Line's [% Institutional Holdings] field, unfortunately, has been subject to some irregularity over time: VS3 assigned zero values to companies with unknown or undefined institutional holding percentages, thereby making it impossible to distinguish companies not held by any institutions from those with unknown or unmeaningful institutuional holding percentages.

In VLIS 2.0 and VLIS 3.0, however, Value Line has done the opposite: companies known to not be held by any institutions are assigned null values in [% Institutional Holdings]. Thus it is still impossible to distinguish companies not held by any institutions from those with unknown or unmeaningful institutuional holding percentages.

Therefore, pih.v has been regularized via a default value of zero throughout its period of availability. If companies with low institutional holding percentages are sought, then those with the default value of zero in pih.v should first be filtered out in order to exclude companies whose institutional holding percentages are not meaningful. Companies whose percentages are meaningfully zero remain impossible to identify on the basis of pih.v.

Finally, note that pih.v cannot be used to identify the Value Line universe of stocks (instead, use tim.v) and that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in pih.v.
-portval: ('-portval') A command switch accepted by blend.exe that causes daily portfolio values for every cycle to be printed in sumfile. Such portfolio values are not written to sumfile by default because of the large file size they require.
pow: (1) A field function raising a specified field's values to a specified power. Its syntax is as follows:

pow:<field_ref_base>,[<pwr_num>|<param_ref_pwr>]

As shown, this version of pow takes two arguments, the first a field reference and the second a number or parameter reference. For each investment, the function pow first checks that its corresponding value in the field referenced by field_ref_base is positive. If so, then it raises this field value to the pwr_num power and assigns the result to the investment's corresponding value in the calling field; otherwise it assigns the value 0.

(2) A field function raising a specified base to the power of a specified field's values. Its syntax is as follows:

pow:[<base_num>|<param_ref_base>],<field_ref_pwr>

As shown, this version of pow takes two arguments, the first a positive number or parameter reference to such numbers and the second a field reference. For each investment, the function pow raises base_num to the power of the investment's value in the field referenced by field_ref_pwr.

(3) A field function raising a specified field's values to the power of another field's values. Its syntax is as follows:

pow:<field_ref_base>,<field_ref_pwr>

As shown, this version of pow takes two field references as arguments. For each investment, the function pow first checks that its corresponding value in the field referenced by field_ref_base is positive. If so, then it raises this field value to the power of the investment's corresponding value in the field referenced by field_ref_pwr and assigns the result to the investment's value in the calling field; otherwise it assigns the value 0.
pref: A field function that returns the values of the most preferred field referenced in the argument list that is not out-of-range on the current trading date. Its syntax is as follows:

pref:<field_ref_1>,<field_ref_2>[,<field_ref_3>...]
As shown, the function pref takes at least two field references as arguments. The referenced fields may contain either field file or field function values. Before the backtest begins, backtest.exe first determines each referenced field's date range, i.e., its interval of market dates over which any backtest that references it would normally be limited. The union of these intervals must itself be a solid interval of market dates; if it isn't, backtest.exe closes with an error message. The interval produced by this union is treated as the date range for the calling field itself, and it, rather than the individual date ranges for the referenced fields, is used to limit start_min and end_max. However, if any field referenced by pref is re-used independently of the call to pref, then start_min and end_max will be constrained by the referenced field's date ranges anyway.

Once the backtest begins, on each trading date, backtest.exe identfies the first field referenced in pref's argument list (as read from left to right) that is available on the current trading date. The field function pref then assigns all values (including default values) of the field thus identified to the calling field for all eligible investments.

Note that pref never mixes values from different fields referenced in its argument list. That is, if only the default value is available for a particular investment from the preferred field, pref does not look for a non-default value from a less preferred field.
product: A field function calculating the product among one or more other fields for each investment. Its syntax is as follows:

product:<field_ref_1>[,<field_ref_2>...]
As shown, product takes one or more field references as arguments (while only one argument is permissible, it is pointless--the field function does nothing but copy the argument field to the calling field). The backtester assigns the product of the referenced field values to the calling field for each investment.
prospective limit: An internal constant used by backtest.exe that specifies the maximum holding period supported by gprc.dat.
prospective total return: In the context of EPL, any total return, inclusive of all distributions (dividends, spin-off's, new stock, liquidation payments etc), a hypothetical investor will realize over some future interval if purchasing a stock on a certain market date. How distributions and other events are handled in calculating prospective total returns is specific to the linearization method itself. Prospective total returns are distinguished from retrospective total returns; the two may differ even for the same stock over the same interval if the interval traverses one or more of the stock's critical dates.

backtest.exe calculates prospective total returns (as multipliers) from trading date d by dividing each investment's closing g-price on market date d + hold by its closing g-price on market date d. Since g-prices are signed, negative multipliers are possible, which in turn produce negative position values. A negative position value signifies a suspension period for the investment, and therefore indicates that liquidation of the investment is forbidden until the position's value is positive again.
pst.v: A field file containing [Price Stability Rank] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Price Stability Rank] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by pst.v is 19860106.

The default value for pst.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with undefined or zero [Price Stability Rank] are not distinguishable on the basis of pst.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in pst.v.
rank: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field, and then, within each group, assigns ascending-order ranks to investments according to their values in another specified field. Its syntax is as follows:

rank:<rank_field_ref>,[<group_field_ref>|1],<at_step_ref>,[1,-1]

As shown, the function rank takes four arguments: the first of which, rank_field_ref, is a field reference; the second of which is either another field reference, group_field_ref, or the number 1; the third of which, at_step_ref, is a step reference; and the fourth of which is either 1 or -1, indicating whether groups are to be sorted in ascending or descending order, respectively, by values in the field referenced by rank_field_ref. The argument at_step_ref specifies that rank be calculated for all investments, and only those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group is then separately sorted by values in the field referenced by rank_field_ref and in the order specified by the fourth argument. Within each group, ranks are then assigned to the calling field, beginning with 1, in the sorted order. Finally, the step referred to by at_step_ref is allowed to proceed.
ratio: A field function calculating the ratio of two other fields for each investment. Its syntax is as follows:

ratio:<field_ref_1>,<field_ref_2>

As shown, ratio takes two field references as arguments, the first one specifying the numerator and the second one specifying the denominator in calculating the ratio assigned to the calling field. If the denominator field is zero for a given investment, ratio assigns 0; otherwise it assigns the value of the numerator field divided by the value of denominator field. It is up to the user to first screen out investments (using step arguments) where the denominator field is 0 if they wish to distinguish between zero and undefined ratios.
rce.v: A field file containing a mostly regularized version of [% Retained to Common Equity] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [% Retained to Common Equity] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by rce.v is 19860106.

Value Line's [% Retained to Common Equity] field, unfortunately, suffers from irregularities in its history. One of those irregularities has been the field's name itself: the current name, [% Retained to Common Equity], is potentially misleading: contrary to what it might suggest, the field does not contain the traditional "Retention Rate" (also called the "Plowback Ratio"); rather, it contains retained earnings over the most recent fiscal year as a percentage of common equity (also called "book value") at the end of the same year. Thus, backtest.exe uses the more descriptive name [VL Ret'd Earn as % of Com Eq (Regularized)] in sumfile.

As for the irregularities in content, VS+ and VS3 (1986 to 1996) replaced all negative percentages and all percentages over 100 with nulls, while VLIS 2.0 and VLIS 3.0 have allowed percentages between -300% and 300%, with nulls only replacing percentages outside this broader range. In an effort to regularize rce.v (i.e., bring the period covered by VS3 into conformity with the current version, VLIS 3.0, for applying nulls) by recovering meaningful values for [% Retained to Common Equity] where Value Line has assigned nulls, the following substitution is used: for a given record with a null value in [% Retained to Common Equity], the percentage 100*([Net Profit] - [Current Dividend]*[Common Shares Outstanding])/([Book Value per share]*[Common Shares Outstanding]) is calculated. Note that the denominator in this ratio approximates common equity at the end of the most recent fiscal year, while the numerator approximates retained earnings over the last fiscal year (they are merely approximations because they assume that preferred dividends equal common dividends, that current dividend rates are the same as those over the last fiscal year, and that there have been no changes in shares outstanding since the end of the last fiscal year). If this percentage is either between 100% and 300% or between -300% and 0%, then the null value in [% Retained to Common Equity] is replaced with this substitute percentage; otherwise the null value remains (until replaced with rce.v's default value, as described below).

The formula used for generating the substitute percentages just described has been found to differ by an average of about one percentage point from actual values in [% Retained to Common Equity] when they are not null. Thus the substitute percentages are believed to be equally accurate at approximating the percentages that were replaced with nulls by Value Line because they fell outside the range of 0% to 100% allowed by VS3. Since the fields required by the substitution formula were not available in VS+, the same method cannot be used to regularize the data in rce.v for the period covered by VS+ (1986-1988). If complete regularization over the entire period supported by rce.v is desired, then the only option is to use steps to filter out investments whose values fall outside the range of 0% to 100%.

Finally, the default value for rce.v has been set to -HUGEVAL. Since this value is applied to both non-Value Line stocks and Value Line stocks with nulls in [% Retained to Common Equity] (after regularization), the Value Line universe cannot be identified on the basis of rce.v (instead, use tim.v for this purpose).
rebalancing date: (1) In a cycle created by backtest.exe, a trading date on which the portfolio is fully rebalanced among both new and old positions (on non-rebalancing trading dates, rebalancing only happens among new positions). The rebalancing dates for cycle n are precisely start_min + n, start_min + n + hold*rebaln, start_min + n + 2*hold*rebaln, start_min + n + 3*hold*rebaln, ...

(2) For cycle n created by blend.exe, a market date that is simultaneously a trading date for corresponding backtest.exe cycles of all strategies in the blend, where the corresponding cycle of each strategy is defined as its unique cycle for which start + n is a trading date. On such market dates, cycle n's portfolio value is re-distributed among the blended strategies in proportion to their associated weight values. See cycle (3) for a formulaic specification of cycle n's rebalancing dates.
rebaln: (1) ('rebaln') The leading sub-string of the optional argument in a backtest command specifying the number of trading dates between rebalancing dates for each cycle. The syntax for the rebaln argument is as follows:

rebaln=<n>

where n is a positive integer.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in rebaln (2). If rebaln (2) is omitted from a backtest command, then backtest.exe sets rebaln to 1 and reports this default setting through stdout. A rebaln value of 1 causes full portfolio rebalancing every trading date for each cycle (or equivalently, every hold number of market days). The value of rebaln becomes particularly important with small values for hold because in such cases, the default value of 1 causes the backtester to simulate what might be considered an impractical number of small trades whose per-trade overhead costs (such as commissions) are not adequately accounted for by the friction multiplier.
regularize: To eliminate irregularities from historical data fields by amending the data in the course of encoding it in field files with the prupose of ensuring that the field data's meaning is as consistent as possible over the entire length of the backtest period. In order to avoid look-ahead bias, the changes made in the course of regularization must always be those that a real investor at the time of publication would have likely made himself. Such changes typically include unit conversion, handling of null values, and capping values.
relative comparison: For a given field and investment, a comparison between the rank or percentile of the investment's field value (taken over all eligible investments) and a comparison value. Relative comparisons, distinguished from absolute comparisons, are so named because they cannot be made without reference to the field values of every other investment in the set over which the rank or percentile is computed.
retrospective limit: An internal constant used by backtest.exe that specifies the number of guaranteed daily g-prices available in gprc.dat prior to any investment's first market date of eligibility for purchase in a backtest.
retrospective total return: In the context of EPL, any total return, adjusted for distributions and other events, a hypothetical investor sees over a past interval when performing technical analysis on a stock for possible trading on a specific market date. How distributions and other events are handled in calculating retrospective total returns is specific to the linearization method itself. Retrospective total returns are distinguished from prospective total returns; the two may differ even for the same stock over the same interval if the interval traverses one or more of the stock's critical dates.
risk: ('risk') An optional argument in a backtest command specifying which risk-related performance measurements are included, and in what order they appear, in sumfile produced by backtest.exe. Its syntax is as follows:

risk=<specifier_word>

where specifier_word is a string consisting of at most one instance of each risk specifier. Measurements represented by their risk specifiers in specifier_word are included in the cluster of statistics reported for each cycle of each variant in sumfile, with their ordering determined by the order of their specifiers in specifier_word. The cluster of statistics always include CAGR first and AT last, with all risk-related performance measurements between them.
risk specifier: A character permitted in words assigned to the risk argument of backtest commands, specifying that a certain risk-related performance measurement be included in sumfile produced by backtest.exe. The current set of risk specifiers and the measurements they specify are as follows:

g GSD (Geometric Standard Deviation of rskintvl returns)
d DD (Downside Deviation of rskintvl returns)
u UI (Ulcer Index for rskintvl returns)
s Sharpe (Sharpe Ratio for rskintvl returns)
b Beta (Beta vs SP500 rskintvl returns)
t TI (Treynor Index for rskintvl returns)
rrs: A field function calculating the annualized slope of the regression line through the natural logarithms of each investment's unsigned closing g-prices indexed over a specified interval of market dates. Its syntax is as follows:

rrs:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function rrs takes two arguments, both of which can be either a number or parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function rrs calculates the slope of the regression line through the logarithms of its unsigned closing g-prices over the interval consisting of (rs_days + 1) number of consecutive market days ending with the market date that is lag_days number of market days prior the current trading date. The market dates within this interval are assigned ordinals in chronological order, which are used as abscissa values in the slope computation (thus, for example, a Friday is treated as equidistant from the preceding Thursday and following Monday, assuming all are market days). The resulting slope is annualized by multiplying it by 253 (the average number of market days in a year) and the result is assigned to the calling field.

Note that if lag_days is zero, then the regression slope is measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place. Also note that if rs_days is 1 (the minimum value accepted), then rrs simply calculates annualized 1-day log-returns.

By default, a meaningful regression slope is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional regression slope computation, use the field function dsio or dspo.
rsi: A field function calculating the Relative Strength Index of each investment determined over a specified interval of market dates. Its syntax is as follows:

rsi:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function rsi takes two arguments, both of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function rsi calculates the sum of positive changes in unsigned g-price divided by the sum of all unsigned changes in unsigned g-price; the ratio is multiplied by 100 and the result is assigned to the calling field. Sums are taken over the period consisting of rs_days (or the value referenced by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value referenced by param_ref_1 for the variant being tested) number of market days before the current trading date.

Note that if lag_days is zero, then Relative Strength Index is measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place.

By default, a meaningful Relative Strength Indicator is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional Relative Strength Indicator, use the field function dsio or dspo.
rskintvl: (1) ('rskintvl') The leading sub-string of the optional argument in a backtest command [blend command] specifying the length, in market days, of the intervals used in calculating certain risk-related performance measurements, such as GSD, Sharpe, DD, and UI, for output in sumfile. The syntax for the rskintvl argument is as follows:

rskintvl=<risk_interval_length>

where risk_interval_length is a positive integer at most the prospective limit.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in rskintvl (2). If rskintvl (2) is omitted from a backtest command [blend command], then backtest.exe [blend.exe] sets rskintvl to 20 and reports this default setting through stdout.
.s: A field file extension indicating that the file's values are essentially as published (see a particular field file's glossary entry for exceptions) in The American Association of Individual Investors' "Stock Investor Pro".
sbdates.txt: A signal file identifying trading dates used by Jamie Gritton's Screen Builder. A signal value of 1 indicates that the current market date is a Screen Builder trading date while a signal value of 0 indicates otherwise. The earliest start supported by sbdates.txt is 19740107.
SD: Coming soon!
sft.v: A field file containing [Safety Rank] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Safety Rank] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by sft.v is 19860106.

The default value for sft.v has been set to 7. There is no separate default value for investments not covered by the electronic Value Line Investment Survey, meaning non-Value Line stocks and Value Line stocks with undefined [Safety Rank] are not distinguishable on the basis of sft.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of 7 in sft.v.
Sharpe(): Coming soon!
sho.a: A field file containing, for every market date, the most recent actual shares outstanding observation (expressed in single shares) for each investment's underlying security, as provided by the sources of daily historical pricing data.

Note that values exclude outstanding shares of other securities issued by the same company. In particular, the values for ADRs represent the number of ADRs outstanding in the United States, not the global number of shares outstanding for the company.

The default value (applied to any investments with no shares outstanding records prior to the current market date) for sho.a is 0.
-shrink: ('-shrink') A command switch accepted by backtest.exe that prevents cash from being purchased on trading dates unless no investments pass a variant's final step and no investments already held pass the htd condition (if present).

Recall that a variant's comparison value in the final step specifies the number of positions held in the portfolio of each cycle. By default (i.e., without this switch), any positions that cannot be filled with investments that either pass the final step or were previously held and pass the htd condition (if present) are invested in cash instead, thereby maintaining the specified number of positions. This switch, however, effectively eliminates such positions altogether (hence the term "shrink"), with the value of eliminated positions distributed among the remaining positions (if none remain, then one cash position is maintained).

Finally, note that this switch does not prevent the purchase of cash following early liquidations triggered by stopgain or stoploss.
signal file: A text file containing market-timing signals, formatted as follows:

1. The extension of the file is txt .
2. The first line of the file begins with the word "backtest", followed by the space-separated command arguments for the backtest command, if any, that produced the signal file.
3. The second line of the file contains text describing the signal.
4. Subsequent lines, called "records", contain two numbers, separated by tab, comma or space: the first number is a valid market date in yyyymmdd format and the second number, called the signal value, is a decimal expression (without commas).
5. Records are in ascending order by market date, no market dates are skipped, and none are repeated.

The backtest command argument

field<field_number>=<base_filename>.txt[:<lag_days>] ,

where <base_filename>.txt is a valid signal file, instructs backtest.exe to load the signal values in <base_filename>.txt corresponding to the current trading date (or the market date lag_days prior to the current trading date, if lag_days is specified) into field<field_number> for all investments on each trading date. If a record corresponding to the market date lag_days prior to the current trading date does not exist, then backward interpolation of signals is used. The earliest possible start supported by a signal file is equal to the market date corresponding to the signal file's first record or the earliest possible start supported by the backtester's database, whichever is later.

Signal files are similar to field files, except

1. Signal files can be created with text editors, whereas field files are in a special binary format and created by custom software linked to the backtester.
2. Field files contain specific values for different investments on each market date, whereas signal files contain only one value for each market date, independent of investments.
3. Field file lag cannot be parameterized, whereas signal file lag can be.
4. Signal file lag is limited to the retrospective limit, whereas field file lag is subject to a much smaller limit.
5. The earliest possible start for a field file is offset upward by <lag_days>, whereas the earliest possible start for a signal file is unaffected by its lag.
sls.v: A field file containing [Reported Annual Sales] as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen Plus, Value Screen 3 and VLIS 2.0 from January 3, 1986 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Reported Annual Sales] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by sls.v is 19860106.

The Value Line field named [Reported Annual Sales] represents total sales (or revenue), in millions of dollars, as published in each company's most recent annual statement. In VS+ and VS3, this field was named [Sales].

The default value for sls.v has been set to zero. Thus non-Value Line stocks and Value Line stocks with undefined [Reported Annual Sales] are not distinguishable on the basis of sls.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of zero in sls.v.
sma: A field function calculating the simple moving average of unsigned g-price for each investment over a specified interval of market dates. Its syntax is as follows:

sma:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function sma takes two arguments, each of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function sma calculates the average of its unsigned g-price over the period consisting of rs_days (or the value reference by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value reference by param_ref_1 for the variant being tested) number of market days before the current trading date and assigns the result to the calling field.

Note that if lag_days is zero, then simple moving averages are measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place.

By default, a meaningful simple moving average is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional simple moving average computation, use the field function dsio or dspo.
sprc: (1) A field function retrieving each investment's Stock Investor Pro-adjusted price per share of underlying stock at the close of the current trading date. Its syntax is as follows:

sprc

As shown, this version of sprc takes no arguments. For each investment on market date d, sprc retrieves its effective value in gtos.s and multiplies this by its current g-price, assigning the result to the calling field. Investments not covered by Market Guide or SI on the current trading date are assigned field values of zero, since the default value for gtos.s is zero. Field values produced by this version of sprc are commensurable with any field file with extension .s and zero lag.

(2) A field function retrieving each investment's SI-adjusted closing price per share of underlying stock a specified number of market dates previous to the current trading date. Its syntax is as follows:

sprc:<quote_lag>

As shown, this version of sprc takes a single non-parameterized argument, quote_lag. The value of this argument must be a non-negative integer at most 20. For each investment on market date d, sprc retrieves its value in gtos.s effective on d - quote_lag and multiplies this by its g-price on d - quote_lag, assigning the result to the calling field. That is, the values in field0 generated by the argument

field0=sprc:<quote_lag>are equivalent to the values in field2 generated by the following arguments:

field0=gtos.s:<quote_lag> field1=gprc:<quote_lag> field2=product:field0,field1Investments not covered by the effective issue of MG or SI on d - quote_lag are assigned field values of zero, since the default value for gtos.s is zero. Field values produced by this version of sprc are commensurable with other field files with extension .s lagged by the same value as quote_lag. Finally, if quote_lag is zero, then sprc (2) is equivalent to sprc (1).

(3) A field function calculating, for each investment, an SI-adjusted closing price per share of underlying stock, where the quotation date is a specified number of market dates previous to the current trading date and the shares are in units from a separately specified number of market dates previous to the current trading date. Its syntax is as follows:

sprc:<share_lag>,[<quote_lag>|<param_ref>]

As shown, this version of sprc takes two arguments, the first a non-parameterized argument, share_lag, and the second a parameterizable argument, <quote_lag>. The value of share_lag must be a non-negative integer at most 20, while the value of quote_lag may be any non-negative integer at most the retrospective limit. For each investment on market date d, sprc retrieves its value in gtos.s applicable on d - share_lag and multiplies this by its g-price on d - quote_lag, assigning the result to the calling field. That is, the values in field0 generated by the argument

field0=sprc:<share_lag>,<quote_lag>
are equivalent to the values in field2 generated by the following arguments:

field0=gtos.s:<share_lag> field1=gprc:<quote_lag> field2=product:field0,field1
Investments not covered by the effective issue of MG or SI on d - share_lag are assigned field values of zero, since the default value for gtos.s is zero. Field values produced by this version of sprc are commensurable with other fields with extension .s lagged by the same value as share_lag. Finally, if share_lag and quote_lag are equal, sprc (3) is equivalent to sprc (2), and if both share_lag and quote_lag are zero, then sprc (3) is equivalent to sprc (1). Uses of sprc (3) are similar to the uses of aprc (3) (see the entry for lag).
start: (1) ('start') The leading substrting of the optional argument in a backtest command or blend command specifying the market date on which portfolio values are initialized and performance measurement beings for all cycles when reporting results in sumfile. The syntax for the start argument is as follows:

start=<yyyymmdd>

where yyyymmdd is an integer representing a valid market date.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in start (2). If start (2) is omitted, then backtest.exe [blend.exe] sets start to start_min and reports this default setting through stdout. If start is later than start_min, then backtest.exe [blend.exe] adjusts start to start_min and reports the adjustment (with a brief explanation) through stdout. If start is not a valid market date or if the interval of market dates [start, end) does not contain at least hold number of market dates, then backtest.exe [blend.exe] reports an invalid start argument through stdout.
start_min: (1) For a given backtest command, the first market date on which the specified strategy is able to begin selecting investments for purchase, as constrained by the earliest availability of required field file data, as indicated in field file headers, and by the lower bound on the backtesting periods supported by daily pricing data, as indicated in date_index.dat. The value of start_min is independent of any parameter values, though it is affected by use of the field function pref.

(2) For a given blend command, the first market date on which all strategies comprising the blend are able to select investments for purchase (i.e., trade), as indicated in the headers of their corresponding cache files. If the comprising strategies have no intersecting interval of tradability, then start_min is undefined and the blend command cannot be executed. Otherwise, the value of start_min is simply equal to the maximum value of start_min (1) found among all cache files named in arguments.
step: (1) ('step') The leading sub-string of an argument in a backtest command that specifies a rule for limiting the set of investments eligible for purchase. The syntax for such arguments is as follows:

step<step_number>=<step_condition>

where step_number is a non-negative integer and step_command is a step condition. The values of step_number indicate the order in which the backtester is to apply step conditions. Every backtest command requires exactly one step argument with step_number equal to 0. The step condition following step0= is applied to the full universe of liquid investments open for purchase on the current trading date; each subsequent step condition is applied to the set of investments satisfying its preceding step condition. Step arguments may be entered in any order, but no value of step_number can be used more than once and the range of values for step_number used in a backtest command must not skip any number. For example, if there is an argument beginning with step5= somewhere in a command, then there must also be an argument beginning with step4= somewhere in the command as well.

There is no required relationship between step_number and the field number contained in the step condition: any step can refer to any field.

(2) The entire argument referred to in (1).

(3) The investment selection instruction implied by a step condition.
step condition: (1) A string of the form

<field_ref><comparison_code>[<comparison_value>|<param_ref>]

where field_ref is a field reference, comparison_code is a comparison code, comparison_value is a decimal representation of a number, and param_ref is a parameter reference. Step conditions are used in step arguments to instruct the backtester to select certain investments for possible purchase or continued holding and in htd arguments to instruct the backtester to select certain investments for a guarantee of continued holding.

field_ref can refer to any field argument in the backtest command, regardless of whether the field argument precedes or follows the referring step or htd argument. However, every field must be referenced by at least one step condition (in either a step or an htd argument) or else backtest.exe reports an error.

(2) The instruction to the backtester implied by a step condition (1). The meaning of a step condition depends upon its step type, as signified by the comparison code.
step reference: A string of the form

step<step_number> ,

where step_number is a non-negative integer. Step references are used to chronologically order the application of step conditions contained in step arguments and to reference steps in htd conditions.
step type: The type of investment-selection behavior signified by a step condition's comparison code.
stopgain: (1) ('stopgain') The leading sub-string of the optional argument in a backtest command specifying the winning total return, in multiplier form, that triggers early liquidation of investments before a cycle's next scheduled trading date. The syntax for the stopgain argument is as follows:

stopgain=[<gain_multiplier>|<param_ref>]

where gain_multiplier (or any value referred to by param_ref) is a number greater than 1, expressed in decimal form.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in stopgain (2). If stopgain (2) is included in a backtest command, then on each market date for each cycle of each variant, backtest.exe computes the total return on each investment in the portfolio from the close of the last trading date for the cycle through the close of the current market date; if the total return exceeds stopgain and the current market date is not a trading date for the cycle, then the investment is liquidated early at the close of the current market date and the proceeds are multiplied by friction and invested in cash until the cycle's next scheduled trading date. Note that the total returns triggering early sales are not measured from the purchase date, but from the last trading date, regardless of when investments were purchased. Finally, observe that if hold=1, then the total returns on all investments since the last trading date (which is always the current trading date) are always 1 (0%), meaning stopgain has no effect.
stoploss: (1) ('stoploss') The leading sub-string of the optional argument in a backtest command specifying the losing total return, in multiplier form, that triggers early liquidation of investments before a cycle's next scheduled trading date. The syntax for the stoploss argument is as follows:

stoploss=[<loss_multiplier>|<param_ref>]

where loss_multiplier (or any value referred to by param_ref) is a positive number less than 1, expressed in decimal form.

(2) The entire argument referred to in (1).

(3) The variable holding the value specified in stoploss (2). If stoploss (2) is included in a backtest command, then on each market date for each cycle of each variant, backtest.exe computes the total return on each investment in the portfolio from the close of the last trading date for the cycle through the close of the current market date; if the total return falls short of stoploss and the current market date is not a trading date for the cycle, then the investment is liquidated early at the close of the current market date and the proceeds are multiplied by friction and invested in cash until the cycle's next scheduled trading date. Note that the total returns triggering early sales are not measured from the purchase date, but from the last trading date, regardless of when investments were purchased. Finally, observe that if hold=1, then the total returns on all investments since the last trading date (which is always the current trading date) are always 1 (0%), meaning stoploss has no effect.
styp.a: A field file containing the two-digit security type code for each eligible investment on every market date.
sum: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field; then, for each group, sums the members' values in another specified field; and finally, assigns to each investment the sum for the group to which it belongs. Its syntax is as follows:

sum:[<sum_field_ref>|1],[<group_field_ref>|1],<at_step_ref>

As shown, the function sum takes three arguments: the first of which is either a field reference, sum_field_ref, or the number 1; the second of which is either another field reference, group_field_ref, or the number 1; and the third of which, at_step_ref, is a step reference. The argument at_step_ref specifies that sums be calculated for all investments, and only among those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group then separately has its sum computed over its members' values in the field referenced by sum_field_ref; if the number 1 is provided instead of sum_field_ref, then the sum is instead defined as the number of investments in the group. Finally, the resulting sum is assigned to the calling field for every investment within the group.
sumfile: (1) ('sumfile') The leading sub-srting of the optional argument in a backtest command or blend command specifying the file to which a summary of results will be saved. The syntax for the sumfile argument is as follows:

sumfile=<summary_filename>

where summary_filename is a valid name for a new or existing file.

(2) The entire argument referred to in (1).

(3) The summary file produced by backtest.exe. If sumfile (2) is included in the backtest command, then backtest.exe attempts to open a new file by the specified name; otherwise, it attempts to open a file by the name of Summary.csv. If backtest.exe is unable to open the file (usually because a file by the same name is already open), then it prompts the user to either enter another file name or to press "Enter" to discard results.

If backtest.exe successfully opens a file for writing (and in so doing, erases its contents if it already existed), then it prints comma separated data (readable with Microsoft Excel or other spreadsheet programs) to the file including: the backtest command that produced the file; an English translation of the command; if the command was parameterized, the parameter values associated with each variant; the first trading dates for each cycle following start; a matrix (with first trading dates and cycle numbers along the top margin and variant numbers along the left margin) whose entries consist of clusters of performance statistics including CAGR, risk-related measurements specified by risk, and AT, all measured from start to end, with one entry for each cycle of each variant; averages of the matrix entries in each variant's row; and a date/time stamp indicating when the source code for backtest.exe was last saved.

(4) The summary file produced by blend.exe. If sumfile (2) is included in the blend command, then blend.exe attempts to open a new file by the specified name; otherwise, it attempts to open a file by the name of Summary.csv. If blend.exe is unable to open the file (usually because a file by the same name is already open), then it prompts the user to either enter another file name or to press "Enter" to discard results.

If blend.exe successfully opens a file for output (and in so doing, erases its contents if it already existed), then it prints comma separated data (readable with Microsoft Excel or other spreadsheet programs) to the file including: the values used for start, end and friction; a list of the weights, backtest commands and their English translations for the blended strategies; average, minimum, maximum and standard deviation statistics for CAGR, all available risk-related measurements and AT, taken over all cycles; first trading date, CAGR, all risk-related measurements and AT, all measured from start to end, for each cycle; Annual Returns for each cycle; daily portfolio values for each cycle if -portval was included in the command; and a date/time stamp indicating when the source code for blend.exe was last saved.
suspension period: An interval of market dates over which a stock has no pricing records because of either an actual suspension or a nominal suspension. In practice, there is no way to distinguish between actual and nominal suspensions in the data sources. Thus, due to the hazards of interpolation (both forward and backward interpolation), it is safer to treat all suspension periods in a stock's historical daily data as actual and forbid trading during suspension periods in backtests, as does GTR1 Linearization.
tas.v: A field file containing [Total Assets] (in millions of dollars) as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen 3 and VLIS 2.0 from December 2, 1988 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Total Assets] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by tas.v is 19881205. The default value for tas.v has been set to 0.
tca.v: A field file containing [Total Current Assets] (in millions of dollars) as published in the electronic version of the Value Line Investment Survey.

The data is based on monthly electronic archives of Value Screen 3 and VLIS 2.0 from December 2, 1988 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Total Current Assets] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by tca.v is 19881205. The default value for tca.v has been set to 0.
tch.v: A field file containing [Technical Rank] as published in the Value Line Investment Survey.

The data is based on both printed issues and electronic archives of the Value Line Investment Survey. In May 2002, VLWRP manually constructed [Technical Rank] on all Value Line stocks found in the printed issues of Index to Stocks corresponding to the trading dates used by Jamie Gritton's Screen Builder from 19870102 through 19881028. [Technical Rank] values from this period were only incorporated into tch.v for investments covered in the electronic archives for the same period, Value Screen Plus.

Subsequent data is based on monthly electronic archives of Value Screen 3 and VLIS 2.0 from December 2, 1988 through February 6, 1998, and weekly archives of VLIS 2.0 and VLIS 3.0 from March 6, 1998 through the present end of the database. With zero lag, [Technical Rank] values are effective for trading from the close of the first market date following the Friday of publication through the publication date of the next archived issue of Value Line. Thus the earliest start supported by tch.v is 19870105.

The default value for tch.v has been set to 7. There is no separate default value for investments not covered by the electronic Value Line Investment Survey, meaning non-Value Line stocks and Value Line stocks with undefined [Technical Rank] are not distinguishable on the basis of tch.v (instead, use tim.v to identify the Value Line universe). Also note that all Value Line stocks identified by VLWRP as missing from the electronic archives receive the default value of 7 in tch.v.

Since [Technical Rank] is one of the most changeable fields included in the Value Line Investment Survey, it was originally assumed that monthly snapshots of [Technical Rank] from 1987 through 1997 were not frequent enough for valid daily-cycled backtesting. However, backtesting from 1998 to 2006 has shown the performance of strategies using [Technical Rank] to be surprisingly insensitive to lags in tch.v, thus challenging the assumption that weekly snapshots of [Technical Rank] are necessary for valid daily-cycled backtesting.
tim.v: A field file containing [Timeliness Rank] as published in the Value Line Investment Survey.

The file covers weekly [Timeliness Rank] values 1 and 2 from the first issue of 1974 (January 4) through the last issue of 1985, and weekly [Timeliness Rank] values 1 through 5 from the first issue of 1986 (January 3) through the end of the present database. With a lag of zero, [Timeliness Rank] values become effective for trading at the close of the first market date following the Friday of publication. Thus the earliest start supported by tim.v is 19740107.

The default value for [Timeliness Rank] is set to 7. However, beginning in 1986, investments covered by the Value Line Investment Survey but without [Timeliness Rank] values are assigned a special value of 6, while investments not covered by Value Line are assigned the normal default value of 7.

All data from 1974 through 1985 was manually collected by VLWRP from paper editions of VL found in public libraries. From 1986 through February 1998, VLWRP started with monthly electronic archives of Value Screen Plus and Value Screen 3 and reconstructed the weekly VL universe, including stocks excluded from VS+ and VS3, and [Timeliness Rank] values from the rank changes flagged in the printed editions of VL obtained via microfiche. From March 1998 through the present, the tim.v contains [Timeliness Rank] obtained from weekly archives of VLIS 2.0 and VLIS 3.0.
TI(): Coming soon!
tn: ('tn') A comparison code signifying the selection of the "top number" (specified by the comparison value) of eligible investments according to the referenced field. More precisely, the step condition

field<field_number>tn[<comparison_value>|<param_ref>]

signifies the selection of eligible investments whose value in field<field_number> is greater than or equal to the value in the Nth position when field<field_number> is sorted in descending order among eligible investments, where N is equal to comparison_value or, if the comparison value is parameterized, the value referenced by param_ref for the variant being tested. If there are fewer than N eligible investments, then all eligible investments are selected. Note that if the field value in the Nth position is equal to the field values of other eligible investments, then all such tying investments (in addition to the first N) are selected by the step condition. Thus, for example, step0 in the backtest command

backtest field0=tim.v:0 step0=field0tn10 field1=trm:10,126 step1=field1tn5
selects a group of 10 investments whose value in tim.v:0 is 7 (the maximum and default value, indicating non-coverage by Value Line), as well as all other investments whose value in tim.v:0 is 7 (of which there would be several thousand). To break ties for a field with a tendency to produce ties, consider adding to or subtracting from it a sufficiently small multiple of another field using the field function linear; the added or subtracted field then roughly functions as a tie-breaker.

In a backtest command's final step, the comparison value, in addition to functioning as just described, specifies the maximum number of positions in a portfolio. On each trading date, positions designated for liquidation are replaced with investments selected by the final step in the order they appear (which is undefined in the case of ties) in a descending sort by field<field_number>. If the final step selects an insufficient number of stock investments to bring the number of positions back up to the maximum following all required liquidations, then cash positions are opened instead by default; otherwise, if the command includes the -shrink switch, then the number of positions is reduced to the number held and purchased, with a cash position opened only if all positions are liquidated and the final step selects no stock investments. Investments are always purchased in equal dollar amounts, thereby rebalancing the portfolio among new positions.
tncut: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field; then, within each group, sorts investments in descending order according to values in another specified field; next, determines the inclusive cut-off value that would be used for selecting the top specified number of investments from within each group; and finally, assigns to each investment the cut-off value determined for its corresponding group. Its syntax is as follows:

tncut:<rank_field_ref>,[<group_field_ref>|1],<at_step_ref>,[<N>|<param_ref>]

As shown, the function tncut takes four arguments: the first of which, rank_field_ref, is a field reference; the second of which is either another field reference, group_field_ref, or the number 1; the third of which, at_step_ref, is a step reference; and the fourth of which is either a positive integer N or a parameter reference to such values. The argument at_step_ref specifies that cut-off values be determined among all investments, and only among those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group is then separately sorted in descending order by values in the field referenced by rank_field_ref. Within each group, the Nth investment's value in the field referenced by rank_field_ref is determined (if a group contains fewer than N investments, then the smallest value is used) and assigned to the calling field for every investment within the group.

For the sake of clarification, note that any step of comparison type tn is equivalent to a step of comparison type al after appropriate use of the field functions tncut and linear. For example, consider the command fragment

... field6=tncut:field5,1,step4,100 field7=linear:1,field5,-1,field6 step4=field7al0 ...
The field function tncut determines the inclusive cut-off value that would be used to select the top 100 investments by field5 at step4 and assigns it to field6 for all investments. The field function linear then subtracts this cut-off value from each investment's value in field5. Finally, step4 selects all investments for which the difference assigned to field7 is at least 0, or equivalently, all investments for which field5 is at least field6. In other words, step4 selects all investments that would pass step4 if it were defined to select the top 100 investments by field5. Therefore, the above command fragment is actually equivalent to the single step argument

step4=field5tn100
Obviously, direct use of a step of type tn is preferable to re-structuring it as a step of type al in the manner shown above unless the cut-off value itself is actually required for some other purpose. As an example of the latter situation, suppose one wishes for step4 to select all investments whose value in field5 is at least half the maximum value in field5 taken over all investments eligible at step4. The command fragment above can be modified to achieve this as follows:

... field6=tncut:field5,1,step4,1 field7=linear:1,field5,-0.5,field6 step4=field7al0 ...
Note how the field function tncut was used to obtain the maximum value in field5 among investments eligible at step5.
tp: ('tp') A comparison code signifying the selection of a "top percentage" (specified by the comparison value) of eligible investments according to the referenced field. More precisely, the step condition

field<field_number>tp[<comparison_value>|<param_ref>]

signifies the selection of investments whose value in field<field_number> is greater than or equal to the value in the Nth position when field<field_number> is sorted in descending order among eligible investments, where N is obtained by multiplying the number of eligible investments by comparison_value as a percentage or, if the comparison value is parameterized, the percentage value referenced by param_ref for the variant being tested, and rounding down if non-integral. Note that if the field value in the Nth position is equal to the field values of other eligible investments, then all such tying investments (in addition to the first N investments) are selected by the step condition. To break ties for a field with a tendency to produce ties, consider adding to or subtracting from it a sufficiently small multiple of another field using the field function linear; the added or subtracted field then roughly functions as a tie-breaker.
tpcut: A field function that first groups all investments that are eligible at a specified step according to discrete values within a specified field; then, within each group, sorts investments in descending order according to values in another specified field; next, determines the inclusive cut-off value that would be used for selecting the top specified percentage of investments from within each group; and finally, assigns to each investment the cut-off value determined for its corresponding group. Its syntax is as follows:

tpcut:<rank_field_ref>,[<group_field_ref>|1],<at_step_ref>,[<Top%>|<param_ref>]

As shown, the function tpcut takes four arguments: the first of which, rank_field_ref, is a field reference; the second of which is either another field reference, group_field_ref, or the number 1; the third of which, at_step_ref, is a step reference; and the fourth of which is either a percentage between 0 and 100 or a parameter reference to such values. The argument at_step_ref specifies that cut-off values be determined among all investments, and only among those investments, that are eligible for the referenced step. When this step is reached in the screening process, all eligible investments are first grouped by their discrete values in the field referenced by group_field_ref; if the number 1 is provided instead of a field reference, then all eligible investments form a single group. Each group is then separately sorted in descending order by values in the field referenced by rank_field_ref. Each group's size, N, is determined, and the (N * Top%/100 rounded down)th investment within the group is found and its value in the field referenced by rank_field_ref is assigned to the calling field for every investment within the group. If (N * Top%/100) is less than 1, then HUGE_VAL is instead assigned to the calling field for all investments within the group.

For the sake of clarification, note that any step of comparison type tp is equivalent to a step of comparison type al after appropriate use of the field functions tpcut and linear. For example, consider the command fragment

... field6=tpcut:field5,1,step4,30 field7=linear:1,field5,-1,field6 step4=field7al0 ...
The field function tpcut determines the inclusive cut-off value that would be used to select the top 30% of investments by field5 at step4 and assigns it to field6 for all investments. The field function linear then subtracts this cut-off value from each investment's value in field5. Finally, step4 selects all investments for which the difference assigned to field7 is at least 0, or equivalently, all investments for which field5 is at least field6. In other words, step4 selects all investments that would pass step4 if it were defined to select the top 30% investments by field5. Therefore, the above command fragment is actually equivalent to the single step argument

step4=field5tp30
Obviously, direct use of a step of type tp is preferable to re-structuring it as a step of type al in the manner shown above unless the cut-off value itself is actually required for some other purpose. As an example of the latter situation, suppose one wishes for step4 to select all investments whose value in field5 is at least twice the median value in field5 among all investments eligible at step4. The command fragment above can be modified to achieve this as follows:

... field6=tpcut:field5,1,step4,50 field7=linear:1,field5,-2,field6 step4=field7al0 ...
Note how the field function tpcut was used to obtain a "median" value for field5 among investments eligible at step5. (The value returned by tpcut:field5,1,step4,50 is actually greater than the median of field5 at step4, though the difference is minor with a large enough sample. The average of tpcut:field5,1,step4,50 and bpcut:field5,1,step4,50 is closer to the true median, and is in fact equal to the median when the sample size is even.)
trading date: A market date on which investments are allowed to be purchased or liquidated within the portfolio of a particular cycle by backtest.exe. In the backtests performed by backtest.exe, the trading dates for cycle n (numbered consecutively from 0 to hold - 1) are start + n, start + n + hold, start + n + 2*hold, start + n + 3*hold, ... A cycle's trading dates are a superset of its rebalancing dates.
trm: A field function calculating retrospective total returns (as multipliers) for each investment over a specified interval of market dates. Its syntax is as follows:

trm:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function trm takes two arguments, each of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed the retrospective limit. For each investment, the function trm uses its unsigned closing g-prices to calculate its total return over the period consisting of rs_days (or the value referenced by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value referenced by param_ref_1 for the variant being tested) number of market days before the current trading date; the result is assigned to the calling field.

Note that if lag_days is zero, then total returns are measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place. Also observe that since total return is calculated by simply dividing unsigned closing g-prices, it can also be obtained using the field functions gprc and ratio. For example, in the command fragment

field0=trm:10,126 field1=gprc:10 field2=gprc:136 field3=ratio:field1,field2 ...,
field0 and field3 are equal. Furthermore, the field functions trm and trp can be related using the field function linear (see the latter function's glossary definition for details).

By default, a meaningful retrospective total return is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional total return computation, use the field functions dsio or dspo.
trp: A field function calculating retrospective total returns (as percentages) for each investment over a specified interval of market dates. Its syntax is as follows:

trp:[<lag_days>|<param_ref_1>],[<rs_days>|<param_ref_2>]

As shown, the function trp takes two arguments, each of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the value of rs_days must be a positive integer, and their sum must not exceed retrospective limit. For each investment, the function trp uses its unsigned closing g-prices to calculate its total return as a percentage over the period consisting of rs_days (or the value referenced by param_ref_2 for the variant being tested) number of market days ending lag_days (or the value referenced by param_ref_1 for the variant being tested) number of market days before the current trading date; the result is assigned to the calling field.

Note that if lag_days is zero, then total returns are measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place. Also, note that the field functions trp and trm can be related using the field function linear (see the latter function's glossary definition for details).

By default, a meaningful retrospective total return is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional total return computation, use the field functions dsio or dspo.
turnover: For a given cycle (2) on a given trading date, the sum of all sale proceeds divided by the value of the portfolio on the trading date.
.u: A field file extension indicating that the field file is user-defined. Field values for all investments are guaranteed to be integers from 0 to 255, with a default value of 255.
UI(): Coming soon!
user: ('user') An optional argument in a backtest command specifying a sub-directory (of the directory containing backtest.exe) from which any user-defined field files referenced in the command will be opened for reading or writing. Its syntax is as follows:

user=<user_dir>

where user_dir is a valid directory name consisting of lowercase letters, numerals and underscores.

Note that only one instance of user can be included in a command and that it applies to all referenced user-defined field files. Thus it is not possible to open user-defined field files from more than one directory.
user-defined: Descriptive of a field file created by a backtest command argument of the form

<user_defined_field_name>.u=field<field_number>

where user_defined_field_name represents a string containing lower-case letters, numerals and underscores. User-defined field files are useful for saving screen rankings (up to 255 positions), integral percentile ranks, groupings, and certain other discrete information for use in subsequent backtest commands.

The above argument causes backtest.exe to create the file <user_defined_field_name>.u within its resident directory (if a file by that name already exists, then backtest.exe closes with an error message). It then executes the rest of the command as usual (though without auto-parameterization), only values within field<field_number> are saved to <user_defined_field_name>.u after converting them to integers from 0 to 255. Raw field values either less than 0 or greater than 255 are saved as 255, while all other values are rounded down to the nearest integer. Investments that are screened out by steps before the backtest command's logic requires use of field<field_number> also receive the default value of 255 in <user_defined_field_name>.u. In other words, on a given market date, non-default values are saved only for investments that were eligible at a step that required use of field<field_number>.

Backtest commands that create user-defined field files cannot be parameterized.
.v: A field file extension indicating that the file's values are essentially as published (see a particular field file's glossary entry for exceptions.) in the "Value Line Investment Survey".
Value Screen 3: Also VS3. The electronic edition of the Value Line Investment Survey archived with monthly frequency from December 2, 1988 through November 29, 1996, after which it was superceded by VLIS 2.0. This subscription to the Value Line Investment Survey was delivered on 3.5" floppy disk and--while containing more data fields than its predecessor, Value Screen Plus--it too lacked many fields contained in the weekly paper editions and later introduced in VLIS 2.0. Like VS+, this version also excluded all securities within the industries

Gold/Diamond (South African)
Financial Services
Real Estate Investment Trust
Investment Company (Domestic, Income and Foreign)
Multiform (later Diversified Company)

as well as miscellaneous other stocks. Altogether, Value Screen 3 excluded about 60 securities covered in the paper editions of the Value Line Investment Survey on any give date. VLWRP has collected Timeliness Rank (tim.v), Industry Code (incd.v) and Industry Rank (inr.v) for all securities excluded by Value Screen Plus and Value Screen 3.

Backtest commands that reference field files derived from VS3 fields not found in VS+ can start no earlier than 19881205, the first Monday following the first archived issue (19881202) of VS3.
Value Screen Plus: Also VS+. The electronic edition of the Value Line Investment Survey archived with monthly frequency from January 3, 1986 through October 28, 1988, after which it was superceded by Value Screen 3. This subscription to the Value Line Investment Survey was delivered on 5.25" floppy disk and lacked many fields contained in the weekly paper editions. This version also excluded all securities within the industries

Gold/Diamond (South African)
Financial Services
Real Estate Investment Trust
Investment Company (Domestic, Income and Foreign)
Multiform (later Diversified Company)

as well as miscellaneous other stocks. Altogether, Value Screen Plus excluded about 60 securities covered in the paper editions of the Value Line Investment Survey on any given date. VLWRP has collected Timeliness Rank (tim.v), Industry Code (incd.v) and Industry Rank (inr.v) for all securities excluded by Value Screen Plus and Value Screen 3.

Backtest commands that reference field files derived from VS+ fields can start no earlier than 19860106, the first Monday following the first archived issue (19860103) of VS+.
variant: A strategy that varies from another strategy in such a way that both can be backtested using the same backtest command via parameterization. More concretely, this means the two strategies differ only in numerical field function arguments and comparison values. For example, the strategy specified by the command

backtest field0=trm:0,126 step0=field0tn10
is a variant of the strategy specified by

backtest field0=trm:5,63 step0=field0tn20
because both can be backtested simultaneously using the command

backtest field0=tr:param0,param1 step0=field0tnparam2 paramfile=param.csv
where the file param.csv consists of the rows

0,126,10 5,63,20
The backtester refers to the first strategy as Variant 0 and the second strategy as Variant 1. Not all elements of a backtest command can be parameterized; for example, the argument hold cannot be parameterized.
Variant <N>: The name given by backtest.exe to the variant corresponding to the Nth row (starting from 0) of the parameter file. In the case of auto-parameterization, variants are numbered (from zero) by the number of positions held in descending order. In the case of no parameterization, the single backtested strategy is called "Variant 0".
VLIS 2.0: The electronic edition of the Value Line Investment Survey archived with monthly frequency from January 3, 1997 through February 6, 1998 and with weekly frequency from March 6, 1998 through June 20, 2003, after which it was superceded by VLIS 3.0. This subscription to the Value Line Investment Survey was delivered on CD and, in later years, via Value Line's website. With only a few exceptions, VLIS 2.0 covered all securities found in the paper edition of the Value Line Investment Survey. VLIS 2.0 also included many more data fields than its predecessor, VS3.

Backtest commands that reference field files derived from VLIS 2.0 fields not found in VS3 can start no earlier than 19970106, the first Monday following the first archived issue (19970103) of VLIS 2.0.
VLIS 3.0: The online subscription edition of the Value Line Investment Survey archived with weekly frequency from December 21, 2001 through the present. This version of the Value Line Investment Survey, like its predecessor VLIS 2.0, is believed to cover all securities found in the paper edition (since I now live in Australia, I am unable to confirm this) on any given date.

Backtest commands that reference field files derived from VLIS 3.0 fields not found in VLIS 2.0 can start no earlier than 20011224, the first Monday following the first archived issue (20011221) of VLIS 3.0.
VLWRP: An acronym for "Value Line Weekly Reconstruction Project". In May of 2001 I began work on "T1 Cleanup", a project involving several dozen volunteers with the goal of manually collecting weekly Timeliness 1 data from paper editions of the Value Line Investment Survey from 1965 through the beginning of weekly electronic archives of VLIS 2.0 in March 1998. While monthly Timeliness 1 ranks were already available as a result of the incredible work of Sux2BeU, it was believed that weekly Timeliness ranks were necessary for valid daily-cycled backtesting.

At the end of 2001, the project expanded its scope to include weekly Timeliness 2 data back to 1974. In July 2002, the project expanded once again with the goal of reconstructing weekly values for several other important Value Line data fields from the monthly archive of Value Screen Plus, Value Screen 3 and VLIS 2.0 and through reference to weekly Value Line issues on microfiche by data-entry volunteers.

Data-entry ceased in the middle of 2003 when doubts arose about our ability to find a provider of daily historical pricing data willing to allow their data to be used in online backtesters. When such a provider was found in the middle of 2005, reconstruction of weekly [Timeliness Rank], [Industry Code] and [Industry Rank] were quickly completed without need for further data-entry and requests were made for programmers interested in building online daily-cycled backtesters.

Between 2003 and 2005, GTR1 Linearization arose out of attempts to systematize the integration of data from multiple sources and the handling of complications in stock pricing history such as mergers, acquisitions, spin-offs, suspensions, delistings etc. TechCzech's first GTR1 Linearizer was completed around the same time that the breakthrough was reached in 2005 regarding daily historical pricing data. The success of GTR1 Linearization lead to my work in late 2006 on backtest.exe, a universal backtester that incorporates data from other sources besides VLWRP with relative ease.
vol: A field function calculating the volatility of each investment over a specified sequence of return periods. Its syntax is as follows:

vol:[<lag_days>|<param_ref_1>],[<num_of_periods>|<param_ref_2>],[<period_length>|<param_ref_3>]

As shown, the function vol takes three arguments, each of which can be either a number or a parameter reference. The value of lag_days must be a non-negative integer, the values of num_of_periods and period_length must be positive integers, and

lag_days + num_of_periods * period_length

must not exceed the retrospective limit. For each investment, the function vol calculates the annualized standard deviation of the natural logarithms of total returns (obtained by dividing the investment's appropriate closing g-prices) over the num_of_periods number of disjoint consecutive periods consisting of period_length number of market days, with the most recent period ending lag_days number of market days prior to the current trading date; the result is assigned to the calling field.

For example, vol:3,52,5 calculates each investment's volatility using its last 52 disjointly measured 5-day total returns, with the most recent 5-day total return measured through the close of the market date 3 days prior to the close of the current trading date.

Note that if lag_days is zero, then volatility is measured through the close of the current trading date, which corresponds to the same g-prices at which trades take place.

By default, a meaningful volatility measurement is always calculated for every investment on every market date, regardless of how recently the stock associated with an investment may have begun trading. This is possible because GTR1 Linearization defines each investment's daily g-prices indefinitely into the past using the history of parent companies and, when the latter does not exist, interpolation. However, to filter out investments with inadequate actual pricing history for a conventional volatility computation, use the field function dsio or dspo.
vprc: (1) A field function retrieving each investment's Value Line-adjusted price per share of underlying stock at the close of the current trading date. Its syntax is as follows:

vprc

As shown, this version of vprc takes no arguments. For each investment on market date d, vprc retrieves its effective value in gtov.v and multiplies this by its current g-price, assigning the result to the calling field. Investments not covered by the electronic version of the Value Line Investment Survey on the current trading date are assigned field values of zero, since the default value for gtov.v is zero. Field values produced by this version of vprc are commensurable with any field file with extension .v and zero lag.

The field function vprc cannot be used to exactly restrict a backtest to the Value Line universe as defined by the paper editions from 1986 to 1996 because of the approximately 60 investments that were covered by the paper edition but missing from Value Screen Plus and Value Screen 3. To accurately restrict a backtest to the Value Line universe, use tim.v or incd.v.

(2) A field function retrieving each investment's Value Line-adjusted closing price per share of underlying stock a specified number of market dates previous to the current trading date. Its syntax is as follows:

vprc:<quote_lag>

As shown, this version of vprc takes a single non-parameterized argument, quote_lag. The value of this argument must be a non-negative integer at most 20. For each investment on market date d, vprc retrieves its value in gtov.v effective on d - quote_lag and multiplies this by its g-price on d - quote_lag, assigning the result to the calling field. That is, the values in field0 generated by the argument

field0=vprc:<quote_lag>are equivalent to the values in field2 generated by the following arguments:

field0=gtov.v:<quote_lag> field1=gprc:<quote_lag> field2=product:field0,field1Investments not covered by the electronic issue of the Value Line Investment Survey effective on d - quote_lag are assigned field values of zero, since the default value for gtov.v is zero. See the comments for vprc (1) on restricting backtests to the Value Line universe. Field values produced by this version of vprc are commensurable with other field files with extension .v lagged by the same value as quote_lag. Finally, if quote_lag is zero, then vprc (2) is equivalent to vprc (1).

(3) A field function calculating, for each investment, a Value Line-adjusted closing price per share of underlying stock, where the quotation date is a specified number of market dates previous to the current trading date and the shares are in units from a separately specified number of market dates previous to the current trading date. Its syntax is as follows:

vprc:<share_lag>,[<quote_lag>|<param_ref>]

As shown, this version of vprc takes two arguments, the first a non-parameterized argument, share_lag, and the second a parameterizable argument, <quote_lag>. The value of share_lag must be a non-negative integer at most 20, while the value of quote_lag may be any non-negative integer at most the retrospective limit. For each investment on market date d, vprc retrieves its value in gtov.v effective on d - share_lag and multiplies this by its g-price on d - quote_lag, assigning the result to the calling field. That is, the values in field0 generated by the argument

field0=vprc:<share_lag>,<quote_lag>
are equivalent to the values in field2 generated by the following arguments:

field0=gtov.v:<share_lag> field1=gprc:<quote_lag> field2=product:field0,field1
Investments not covered by the electronic issue of the Value Line Investment Survey effective on d - share_lag are assigned field values of zero (since the default value for gtov.v is zero). See the comments for vprc (1) on restricting backtests to the Value Line universe. Field values produced by this version of vprc are commensurable with other fields with extension .v lagged by the same value as share_lag. Finally, if share_lag and quote_lag are equal, vprc (3) is equivalent to vprc (2), and if both share_lag and quote_lag are zero, then vprc (3) is equivalent to vprc (1). Uses of vprc (3) are similar to the uses of aprc (3) (see the entry for lag).
VS3: See Value Screen 3.
VS+: See Value Screen Plus.
.w: A field file extension indicating that the file's values are essentially as published (see a particular field file's glossary entry for exceptions) in Investor's Business Daily's "Your Weekend Review".
year: A field function calculating the calendar year, lagged a specified number of market dates from the current trading date. Its syntax is as follows:

year:[<lag_days>|<param_ref>]

As shown, the function year takes a single argument that is either an integer (possibly negative) or parameter reference to integers. The function year first identifies the market date that is lag_days prior to the current trading date (if lag_days is negative, then the identified market date will be later than the current trading date), provided it does not pass the latest end supported by gprc.dat and that it does not precede the earliest start supported by gprc.dat by more than the retrospective limit. When the identified market date would otherwise exceed one of these limits, it is defined as the earliest or latest (according to whether lag_days is positive or negative, respectively) market date within the limits. Once the lagged market date is identified, the function year assigns the year (in yyyy format) of the identified market date to the calling field for all investments.

Note that if lag_days is zero, then year determines the year associated with the current trading date.