Priming is based on the maximum lookback parameter value, plus the maximum indicator length value. With those number in mind, we add one bar to each of the lengths, and one bar to the final tally for a number for internal program reasons.
In the case of someIndicator[lookback] the amount of priming required is the days in the indicator plus the lookback amount.
The Years of Priming value in preferences is used when loading data. Rather than start loading data on the Test Start Date, the system will attempt to load this extra years of data, if available. So if the Test Start Date is 2017-01-01 and the years of priming data is 0, then the first bar of data will be 2017-01-01. If the Years of priming data is 1 then the first bar of data will be 2016-01-01 – if the data is available. The first bar of data is always the first bar of available data, or the test start date minus the years of priming, whichever is later.
Every block and system is evaluated for required priming. The priming for a block is the max lookback parameters plus the max indicator lookback. The max of this value over all blox in all systems, is the test priming bars required. The first bar that the Entry Orders script and others will start running is on the Test Start Date, or the first primed bar, whichever is later. So if the Test Start Date is 2017-01-01 but the first primed date is 2017-02-01, then the first evaluated by the Entry Orders script will be 2017-02-01.
The Update Indicators script by default is set to start running on the first primed bar. So this might be before the Test Start Date. This is designed so that custom indicators can be computed and ready before the Test Start Date, and before the Entry Orders script starts running. Enough data is required for this: the number of bars is equal to what is required by the custom indicators, plus what is required for the test priming. So the user should set the Test Start Date to account for this.
The Update Indicators script runs for every instrument on bar of data, so that excludes holidays. The reason is so that this can be used to compute custom indicators correctly.
All non-instrument scripts like Before Instrument Day and After Instrument Day will run on all test days. Test days are typically weekdays, unless process holidays .ini setting is true in which case Sundays are included.
Note that if you set the test start date back in time, and then set the test start date ahead in time, the data is still cached and available. So this may change the priming and start of the update indicators script. Something to keep in mind.
Edit Time: 3/7/2018 3:51:42 PM
Topic ID#: 56