Tips and tricks / An array without $Array

Forums ProRealTime English forum ProOrder support Tips and tricks / An array without $Array

Viewing 11 posts - 1 through 11 (of 11 total)
  • #245310

    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…

    2 users thanked author for this post.
    #245311

    It is more accurate to use barssince on ArrayIndex if you need to store values that can be equal (exemple higher highs with a perfect double top with 2 equal HH).

    The exemple above was for storing barindex.

    #245313

    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.
    #245325

    Solved the problem i had with arrays with this trick.
    This bug which occurs with array was posted here :
    https://www.prorealcode.com/topic/arrays-related-bugs/

    The same code without array$ :

    #245326

    The other side of the coin is that using Barssince makes the code much slower than with Arrays…

    If prorealtime can add some instructions concerning bar state, like barstate.isconfirmed for exemple, or an other kind of arrays that would be updated only at the close of the bar… it would be great

    #245327

    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.

     

     

     

    1 user thanked author for this post.
    #245328

    Error on return line above, should be ‘src’ .

    #245331

    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 ?

    1 user thanked author for this post.
    #245332

    The last code shows that the index problem come from the index of the array when you use -1 or -2 and maybe the index of the array have been update temporarly and not at the close of the bar…

    #245365

    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.
    #245367

    F barindex = barindex then …. endif

    This one is really strange ! :-))))

    Note also (but not sure of it as i did not dig into it yet, as i just noticed it last week end) that this strange behaviour of array index may be fixed in probuilder (i mean for indicators) by those tricks but in proorder (i mean in strategies) the code may behave differently (with odd missing points), and that is even more annoying…

Viewing 11 posts - 1 through 11 (of 11 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login