Let's look at this simple piece of QuantScript code:
If we were to debug this strategy, it would make sense forto be for the first 5 bars, right? It should have a value on the sixth execution of the script i.e. the sixth bar - that is when we could go back in time 5 bars, to the first bar.
It makes perfect sense. However, imagine having a 1-day Trading Frequency strategy, which uses an SMA with a period of 200 bars to produce signals. Following our current logic, that SMA would have anvalue for the first 200 bars of the backtest. That's almost a year's worth of backtesting data doing nothing!
This approach would not be ideal. So QuantScript operates a bit differently.
Indeed, if you debug the strategy above, you will find thathas a value on the very first bar.
This is due to the fact that QuantScript executes your code an additional 500 times before it gets to the first bar of the backtest. If you have a strategy with 1000 Max Data Bars, QuantScript will actually load 500 extra, for a total of 1500 bars.
The signals produced during these 500 extra executions are ignored and are not part of the backtest.
These extra executions are what's called the warmup period. It exists to make sure time travelling works as expected from the very first bar, making backtests more meaningful.
To prove that this works, let's take our double-SMA strategy we wrote earlier, change it to use a single SMA with a period of, let's say 400, and see if it has a value on the very first bar.
Here's what our strategy looks like:
Paste that code into the QuantScript editor, click on Debug and, indeed,has a value starting from the first bar.
This concludes the warmup period section.
When we stop debugging and click on Calculate Backtest, another issue we need to be aware of pops up.