Tips and tricks / An array without $Array
- This topic has 10 replies, 2 voices, and was last updated 3 weeks ago by
.
-
Something we are not necessarily aware of is that any variable is also an array…
in contrary of $arrays which can be updated several times at each candle (they do not depend on barindex), the array made of any variable is an array related to barindex ; and this can be an advantage if you want your array to be updated only at the close of the current bar!
This array can’t be deleted and can’t update previous values afterward… But it is useful when you want to store pivot high and lows wihtout having the array errors issues because of array updating at each ticks…123456789101112131415161718once ArrayIndex = -1once AnyVariable = 0 // I Am A Variable But Yet A Real Array !if ConditionsAreMet thenAnyVariable = NewDataArrayIndex = ArrayIndex + 1endif...// How to retrieve the nth value (n) from the array ?MyNthDataValue = AnyVariable[barssince(AnyVariable>AnyVariable[1],ArrayIndex-n)]// How to retrieve the last value from the array ?MyNthDataValue = AnyVariable[barssince(AnyVariable>AnyVariable[1],0)]// How to retrieve the first value from the array ?MyNthDataValue = AnyVariable[barssince(AnyVariable>AnyVariable[1],ArrayIndex)]Wrote this before your last update post!
Just a few thought…
When condition is true and new data is stored in AnyVariable along with the current ArrayIndex count,
these values don’t change and are stored with the following bars where condition is false, until next bar where it is true again.
Let’s say that, the Newdata is ‘9’ and doesn’t change over several times the condition is true, (the repeated values are not represented).
9,9,9,9,9,… AnyVariable
0,1,2,3,4,… ArrayIndex
In the recovery process, the Barssince condition is looking for a change in data value, x > x[1].
But if, AnyVariable is the same value as in example, I presume there will be an error in recovery.
However, the Array index is going to be different with every valid entry, regardless if the data was the same.
So, there could be an error if the data value is the same, and maybe away around that is to, look for a change in the index value.
Or, ensuring that the non valid data value is -1 or something, so to get the change.
Maybe a simple solution is to remove the ‘Once’ from before the AnyVariable = 0, this would default it to the = 0 value every bar, until a true condition value.
You could also used the ‘0’ to test if recovered data value is valid, and has not not fell out of sequence somewhere.
0, 0,0 ,9,0,0,0,9,0,0,0,9,0,0,0,9,0,0,0,9,… AnyVariable
-1,-1,-1, 0,0,0,0,1, 1, 1, 1,2,2,2,2, 3,3,3,3,4,… ArrayIndex
Anyway. Regards
1 user thanked author for this post.
Had a look at the array version which throws an index error,
I think the error is coming from the BARINDEX – array[n] and that the BARINDEX equation doesn’t recognise array[n] as an integer.
Even though the element value may be an integer, array[n] is not an int data type, and I think that may be something to do with it.
So the error is coming from the barindex side and not the array side, pre-formatting array or isset etc, not going to affect it.In your other post you discussed
drawtext(“text #array[n]#”,x,y and drawtext(array[n],x,y)
where the former doesn’t display the array value, but the latter does.
I think the same thing is happening with
Barindex – array[n] and arr = array[n] , barindex – arr
Changing the array’s in the barindex equations with normal variables versions seems to avoid the index error.
Don’t no if displayed results are right , i’ll leave that up to you to determine.
123456789101112131415161718192021222324252627Once RSILen = 14Once prd = 1Once pBcTi = -1Once pBmTi = -1src = RSI[RSILen](close)If src[prd] = lowest[2*prd+1](src) thenpBcTi=pBcTi+1$pBcT[pBcTi]= Barindex-1if pBcTi > 2 and isset($pBcT[pBcTi]) thenvar = $pBcT[pBcTi-1]var2 = $pBcT[pBcTi-2]var3 = $pBcT[pBcTi]if src[barindex-var] <= src[barindex-var2] and src[barindex-var] <= src[barindex-var3] thenpBmTi=pBmTi+1$pBmT[pBmTi]= $pBcT[pBcTi-1]drawpoint($pBcT[pBcTi-1],src[barindex-var],3) coloured("red",100)endifendifendifReturn scr1 user thanked author for this post.
This version of the code does not throw the index error neither, even if the barindex-array[n] remain in the code… which should mean your explanation on the cause of the index error would not be the right one. Don’t you think so ?
123456789101112131415161718192021222324Once RSILen = 14Once prd = 1Once pBcTi = -1Once pBmTi = -1src = RSI[RSILen](close)If src[prd] = lowest[2*prd+1](src) thenpBcTi=pBcTi+1$pBcT[pBcTi]= Barindex-1if pBcTi > 2 thenpb1 = pBcTi-2pb2 = pBcTi-1pb3 = pBcTiif src[barindex-$pBcT[pb2]] <= src[barindex-$pBcT[pb1]] and src[barindex-$pBcT[pb2]] <= src[barindex-$pBcT[pb3]] thenpBmTi=pBmTi+1$pBmT[pBmTi]= $pBcT[pb2]drawpoint($pBcT[pb2],src[barindex-$pBcT[pb2]],3) coloured("red",100)endifendifendifReturn src1 user thanked author for this post.
Your’re right ! … under certain scenarios, it appears not to work, but then others it does.
I’m looking a bit deeper!
Placing the original index terms in the equations, to causes the index error, but enclosing the whole code in,
IF barindex < n then … endif
Avoids the index error when n is smaller than barindex, increasing n beyond barindex, error doesn’t return.
changing to
IF barindex = barindex then …. endif
appears to negate the error as well. Not sure why this avoids index error, unless it helps aligning to a bar somehow!
This loosely give me the idea, that the error is after the OHLC data of the chart build, and into the current candle tick area.
Comparing the output of your latest code and a version modified in above way, show odd missing points when both compared.
However, if you re-add the modified error version, the missing points show up in the right place on a chart re-build.
This again points to some deviation when ticks are being used.
Not got any further with it yet, need to think about a while and figure out how to test further.
1 user thanked author for this post.
Find exclusive trading pro-tools on 
