The Years of Priming value in the preferences area shown below is used to determine how much data to load before trading is planned to begin.  Data loading prior to the Test Start Date is needed enables the calculations of indicators and other calculations to have enough records available to generate results that will enable trading to begin on the Test Start Date.

Loading data ahead of when the system is to start trading is called Data-Priming.  This means that data ahead of the Test Start Data will be made available to the system.  To understand this better, consider an  Indicator[lookback] length requires 100 data records be available for calculating the indicator's results so that trading can begin on the Test Start Date.  In our example data file, its record information shows it has has twenty-years of records ahead of its last record date of today.  That file has more than enough data records to load the five years of data and to also enable an indicator that requires a 100-data records to produce results before the Test Start Date.  For example, the years shown in the image above will instruct Trading Blox Builder to load five-years of data records ahead of when the Test Start Date is expected to begin trading.

 

In this example where an indicator needs 100-records, and the priming data will make available 5-years of records.  That is more records than this indicator requires.  In this case, it will begin generating results 1-record later later than the first data date in the primed data file.  

 

Instrument Priming is based on the maximum lookback parameter value, plus the maximum indicator length value.  With those number in mind, add one bar to each of those lengths, and one bar to the final tally for the number of data records required for internal Trading Blox Builder reasons.   That value is how many records will be required before trading can begin.

 

So if the Test Start Date is 2017-01-02 and the years of priming data is 0, then the first bar of data will be 2017-01-02. If the Years of priming data is 1 then the first bar of data will be 2016-01-02 – 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 its required lookback 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-02 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.

 

---