This is a Feature Request dubbed ExtraBars.
Purpose:
Currently if you are using an indicator that requires n data bars before valid and want backtest data for an exact period of time, say 2 years, you must use a months, weeks, or days timeframe to get close to the 2-year number.
Background:
In V6 there was a method called GetAllDaaForSymbol. This allowed a strategy to start at bar 0 with valid indicators. This made for a true comparison of strategy performance versus "Buy and Hold" because they both started at the same bar.
In V7 there is a new function called StartIndex. This allows for the strategy to be delayed for n bars until indicators are valid. It also delays the Benchmark calculation by the same number of bars. So, again, you can get an accurate comparison of both over an identical timeframe.
Proposal:
Create a new "AddBars" function that would add the required number of bars to a backtest timeframe so that the strategy indicators could be valid at the backtest timeframe. For example, if your longest indicator period is 30 bars, AddBars could be set for 29 (30 - 1). In this example both the strategy and the Benchmark performance calculation should automatically be delayed 30 bars so they would start at the same bar to provide an accurate comparison. Then a 2-year backtest timeframe should then yield two years of synced strategy and backtest data.
Purpose:
Currently if you are using an indicator that requires n data bars before valid and want backtest data for an exact period of time, say 2 years, you must use a months, weeks, or days timeframe to get close to the 2-year number.
Background:
In V6 there was a method called GetAllDaaForSymbol. This allowed a strategy to start at bar 0 with valid indicators. This made for a true comparison of strategy performance versus "Buy and Hold" because they both started at the same bar.
In V7 there is a new function called StartIndex. This allows for the strategy to be delayed for n bars until indicators are valid. It also delays the Benchmark calculation by the same number of bars. So, again, you can get an accurate comparison of both over an identical timeframe.
Proposal:
Create a new "AddBars" function that would add the required number of bars to a backtest timeframe so that the strategy indicators could be valid at the backtest timeframe. For example, if your longest indicator period is 30 bars, AddBars could be set for 29 (30 - 1). In this example both the strategy and the Benchmark performance calculation should automatically be delayed 30 bars so they would start at the same bar to provide an accurate comparison. Then a 2-year backtest timeframe should then yield two years of synced strategy and backtest data.
Rename
Using the 2-year + 30 bars example, what's the advantage of "AddBars" over assigning a StartIndex to 30 and loading 25 months instead of 2 years?
Probably nothing, as long as you can get the numbers to work. 30 bars != 1 month. It's more like 6 weeks. I guess you could use 110 weeks instead of 2 years. Currently I am using 1, 133 days to simulate 2 years most accurately.
It would be nice (but not absolutely necessary) to be able to preset the indicator valid data parameter in code, so if I want to quickly compare different backtest timeframes, I could do it without having to do calculations and conversions.
It would be nice (but not absolutely necessary) to be able to preset the indicator valid data parameter in code, so if I want to quickly compare different backtest timeframes, I could do it without having to do calculations and conversions.
This is too similar to the funcitonality that already exists, StartIndex.
@Glitch. I disagree. StartIndex is for syncing B&H and strategy backtest period . It is also be used to insure the strategy indicators are valid before generating signals before.
StartIndex does not do the same thing as the proposed AddBars, which addresses a completely different use case. It is a way to get a strategy to execute for the exact full-length of the backtest period. In a way it "gets back" the bars taken up by StartIndex that reduces the actual number of days of backtest.
You cannot do what I am proposing with StartIndex. I tried, but it does not take a negative number.
StartIndex does not do the same thing as the proposed AddBars, which addresses a completely different use case. It is a way to get a strategy to execute for the exact full-length of the backtest period. In a way it "gets back" the bars taken up by StartIndex that reduces the actual number of days of backtest.
You cannot do what I am proposing with StartIndex. I tried, but it does not take a negative number.
QUOTE:
StartIndex does not do the same thing as the proposed AddBars, ... In a way it "gets back" the bars taken up by StartIndex that reduces the actual number of days of backtest.
If you have StartIndex=100, then to get those bars back, just add 100 to the previous Data Range.
At any rate, I would use either one method or the other--but not both. To implement both would cause users confusion because some may try to employ both methods simultaneously with unexpected results.
So if you want the AddBars method, then we all need to rewrite our strategies to remove StartIndex. Either method works for me--but not both.
Hi @superticker. Thanks for your interest and comment. Adding 100 bars at the beginning is exactly the issue.. How do you add 100 bars to a 2-year strategy backtest timeframe? It requires conversion to another unit of time (weeks, months, or days) and calculations. AddBars is just a convenience to avoid this.
I don't see why any code would need to be rewritten. Unless you are concerned about the issue I am trying to address, you would have no reason to re-write your code. The new feature is not going to break anything unless you use it.
Actually, I would argue that your original StartIndex value should work perfectly with AddBars. StartIndex counts from 0, and AddBars would just have 0 be at an earlier date. The strategy would start at StartIndex, as it does now, but you would have a true backtest timeframe..
I don't see why any code would need to be rewritten. Unless you are concerned about the issue I am trying to address, you would have no reason to re-write your code. The new feature is not going to break anything unless you use it.
Actually, I would argue that your original StartIndex value should work perfectly with AddBars. StartIndex counts from 0, and AddBars would just have 0 be at an earlier date. The strategy would start at StartIndex, as it does now, but you would have a true backtest timeframe..
Having multiple similar ways to do the same thing--including a programming language like C#--is not a desirable feature. It just confuses the code unnecessarily. Sometimes you have to protect programmers from themselves. :(
So if you want AddBars, then dump StartIndex. That's my only requirement.
So if you want AddBars, then dump StartIndex. That's my only requirement.
But they are not the same thing. They do different things. StartIndex delays the start of a strategy. AddBars adds bars the front of a timeframe, much like GetAllDataForSymbol from V6. Don't see how they would be confused.
Agreed with Glitch and superticker: the two methods would serve the similar goal, arriving at it slightly differently.
And this request doesn't seem necessary to me at all because you have GetHistoryUnsynched as the GetAllDataForSymbol alternative.
And this request doesn't seem necessary to me at all because you have GetHistoryUnsynched as the GetAllDataForSymbol alternative.
QUOTE:
the two methods would serve the similar goal, arriving at it slightly differently.
Sorry. Disagree. Technically you may be correct. But it's not the same goal. The purpose and use case are different from StartIndex.
QUOTE:
And this request doesn't seem necessary to me at all because you have GetHistoryUnsynched as the GetAllDataForSymbol alternative.
I took a look at this function and it would likely be practical for a few "external" symbols, but not for a DataSet of symbols. StartIndex is compatible with using a DataSet and does not require special symbol by symbol synchronization.
I suppose I could code a loop to synchronize 100 symbols, but for now I think I'll just continue to use a timeframe of 1133 Days to get my true 2 year backtest.
Your Response
Post
Edit Post
Login is required