System Stopped – Array Problem
- This topic has 34 replies, 3 voices, and was last updated 1 month ago by
.
-
Update
Algo still running with original added code setting at 100.
Changing setting 100, to 0 or 1 or 2 or 3 algo stops shortly after starting.
Using 4 or greater, algo continues.
This provisionally looks like an element, 0,1,2,3 being accessed before defining it.
Looking at code
Variable A3 = 15
line 5 CountBars=A3
line 27 shift=CountBars = -11 -1
Therefore shift = 3
if shift = 3 then main IF block starts at bar4.
No other code changes the shift value until the
end of main while loop where it is decremented by 1.
when shift = 0 and then shift=shift -1 = -1 then main while loop is terminated.
Based on this, shift is either 0,1,2,3, starting at 3 and being decremented to 0.
Predefining the array elements appears to avoid stopping, So after further thought,
not only could it be 0,1,2,3 be undefined, it could be trying to accessing above this.
Later incrementing and adding i1 with shift in index may be an issue.
1 user thanked author for this post.
Running on 1 minute, DAX40(DFB)
Set some demo bots loose with predefined arrays of 100, 10 and 4, all still running from yesterday, however no entries.
That appears to conclude that original error trigger when element[4] was accessed, and undefined.
In THE original code, ‘CounterBars = 500’, variable indirectly sets the index to 0-488, providing more data points.
This in theory explains why elements undefined, but doesn’t avoid error in tests, had to set A3 = 2000 before bot would stay running.
So another angle to look at.
1 user thanked author for this post.
had to set A3 = 2000 before bot would stay running.
The PRT default for preload bars is 2000, might that be why?
1 user thanked author for this post.
Could be, value too similar to ignore. been running for an hour or so now, no entries yet on any.
Backtest version, no pre-define, showing entries, so i’m wondering if , pre-defining elements, though avoiding stop error, has affected code in a way, when accessing elements which just hold the default value of zero, and has change the operation. And that may be that back test results could be erroneous for the same/different reason, since not throwing an error.
On a slightly different note, testing, trying to capture an error, and algo has limited/no feedback capabilities, print, graph, etc
In this case, the error pointed to the ‘array’ with message and several possible reasons why.
If you suspect, in this case, that its trying to access a undefined element. Then setting a IF block to check for a valid index range before use, if its a fail, then using another, different command who’s purpose is to fail, like test = highest[-1], negative index. If IF condition is out of bounds, then IF code run, which produces a failure before original error, The error message is now different, pointing to something else, so you can use this change, as an indication on what’s maybe happening in the bot when it stops, based on the condition you set.
1 user thanked author for this post.
Keep in mind the “trick” I found the other day : Use Print to find whether things which are accepted in Backtest, will fail in Live (or Demo).
Currently I don’t have an exact example in mind, but if – at places where you expect a variable to be defined – put a Print command of it, then this will silently fail if the variable is not defined after all, but the print column will be empty or the column won’t be there at all.1 user thanked author for this post.
Not got to a definitive answer but, I think the reason for the error, and what caused it are now clear.
However, the exact path taken to the error is still undefined.
#numbers/var refer to line numbers in your original code posted.
#Vopt When variable A3 = 15
#5 CountBars = A3, and then
#27 shift = CountBars-11-1 which equates to 3, giving a shift range of 0,1,2,3.
#29 main IF block is true when barindex is greater than Countbars
#30 main While loop, loops, shift value and, exit condition true when shift smaller than zero
#123 decrementing of shift by -1, end up at shift = -1, which breaks the loop.
Additionally…
#Vopt A2 = 1.5
#4 Risk = A2
#Vopt A23 = 77
#Vopt A24 = 15
#23 X1 = A23 + Risk which equates to 78.5, upper level threshold
#24 X2 = A24 – Risk which equates to 13.5, lower level threshold
#79 calculates the value of Value2 and then
#80 store Value2 in array, both related to shift value
#85 tests if current value of Value2 is smaller than the lower level threshold of X2, if it is….
#86 the value of i1 is set to one.
#87 The while loop, looks back and test if, pointed to, array value, of Value2, condition falls in between the upper and lower threshold levels.
So, current bar is below X2, #85, lookback searching for last time above X2 #87.
Now here is where I think the error comes in…
i1 is set to 1 #86 , so the look back starts at previous bar to shift , shift+1.
On the first run of main while, shift = 3, and that is the index value used to store arrays, then
adding 1 to shift points to an undefined element ‘4’ and hence error as loop commences.
Now pre-defining arrays to avoid this error means that the default value of these extra elements hold the value of zero.
When checking for the last inside of range, a value of zero, means that may not happen, because all higher elements are 0 and depending on situation at the time.
It’s possible that, if shift = 0, when all this happens, then condition for inside threshold area may be met before i1 increments to a value which results in accessing the undefined element. So not a total failure.
The original code had CountBars = 500, this would have resulted in a shift range of 0 – 488.
In the while loop, looking back would have a lot of elements defined. This avoiding error or at least pushes to an edge case where if, value2 stayed below or above the threshold levels that long and other factors allowed access beyond defined array element could happen.
I suppose the number of consecutive bars, above or below the threshold levels, in that process, is the cut off point.
And depending on timeframe used, the amount of these bars are going to be more or less.
Therefore A3 needs increasing to a value that avoids this array look back error situation.
1 user thanked author for this post.
I’ve optimised a version with A3 = 25 … I’ll try it tomorrow on Live.
I’ll comment out your snippet below to see if, with A3 =25, I get a stoppage for the same array look back error.
if barindex = 0 thenfor i = 0 to 100$Tablevalue2[i] = 0$val[i] = 0$val1[i] = 0nextendifBig Thanks for your ongoing time, interest and support.
1 user thanked author for this post.
Find exclusive trading pro-tools on 
