Array/Bubble sort in strategy doesn’t work, but works as an indicator
- This topic has 30 replies, 4 voices, and was last updated 1 month ago by
.
-
Hi Finning,
In an earlier comment, Roberto mentioned that the back-test doesn’t run ‘live’, this I take, the array/tick scenario is not a problem in back-test and beyond.
Also, I think JS told me that the number of decimal places in back-test was 5 where 6 in indicator, that could affect values.
However, if trying to get an indicator and back-test to match then, using only closed data that could be a way to go.
But when arrays are introduced in the indicator, then the live ticks are an issue, I bring this up because of the complexity of what your trying to achieve with the dynamic optimisation where the arrays make it easier to manipulate a bunch of similar variables.
As I see it:
If the value placed in an array element is fixed, ‘1’, each tick won’t affect the value of the element regardless of how many ticks there are.
If the value to be place is CLOSE, then each tick will update CLOSE and also the element, however at the end of the bar the element will hold the right end of bar close value.
The problem starts when the element of an array is on both sides of the equals ‘=’ sign , like arr[n] = arr[n] +1
When there is a tick, ‘1’ is added to the element and this becomes the new updated element value. The next tick re-calculates the equation again, but now with the previous updated value.
This continues for every tick in the bar until the bar end, and explains the runaway count observed per tick.
In comparison, normal variable can change their values with every tick, however, their original values are only updated at the end of a bar where there last value becomes historicised, similar to the arr[n] = close example.
Because arrays hold there values over the end of a bar, and there is no access to historic element values, then you always have the arr[n] = arr[n] +1 issue.
In Robert’s latest code for the indicator, the code block was isolated to the first tick. However the value capture was at that point, and could introduce an error as I explained above with (1,0) and (0,1) an bar end.
This and other techniques will be good depending on the required result.
In my Bubble V11 code, I avoid the array/tick issue by only storing the tradeCandle condition result, 1 or 0, in an array , similar to the arr[n] = CLOSE example, and then copied the results to a new array which acted as a multidimensional array.
Each bars set of results are stored in the Multi-array in the next free elements.
This allow the looking back at previous element values and the ability to loop and count up the true condition counts.
Having access to previous elements allows a different none taxing way of updating the counts.
I did see a comment from Nicolas that multidimensional array may be coming at some point.
‘For every action there’s a reaction’
Storing multiple elements in and array, per bar, will get to the 1 million element limit much quicker.
So some clean up routine would be required to avoid that happening. That maybe easier to solve than requesting DEFPARAM ARRAYUPDATE = ByBAR // default = ByTICK .
I think at daily TF with a sample of 40 periods the code would only back-test up to about 25000 bars.
Not really an issue at daily but hourly brings that down to a ~1000 bars, also increasing the sample period will have its affect.
So the clean up would have to reduce the array size down to a size in which it holds the minimum elements to continue forward at its most efficient.
If going to take strategy live, then specifically coding for back-test would be the way to go.
Though the drawing commands are limit in back-test, using a combination of logic with the graph and print functions can help greatly while debugging.
I’ve not yet studied the back-test and live strategy in a comparison sense, but loosely assume its similar to the back-test.
I think that about summariser’s some of what’s be going on.
1 user thanked author for this post.
Find exclusive trading pro-tools on 
