Arrays and how they can not be used (?)

PeterSt · Wed, 19 Jan 2022 15:33:34 +0000

This is merely a (too long) brainstorm. Thus please feel free not to read at all. 🙂 GraHal wrote: With above, I just did a quick mash up of an existing code, so not a valid test of Arrays. My understanding of Arrays is (using an xls to illustrate) … imagine a spreadsheet with numbered rows; after each bar the Close value is entered into a cell then next bar / close value is entered under the last entry … repeat etc. When required, a query of the Array (e.g. filled cells as above) can give HH, HL, LL, LH value over x bars. The clever bit is to code into a strategy to determine if price has passed the Highest High and price is now hitting a Lower High (a High lower than Highest High). And so on, so as to determine if the uptrend has ended. Anybody agree / disagree with above? Can any wizard code it? 🙂 (emphasis is mine) If it only were true that it would work like that. But it doesn’t and I think it can’t. What you suggest/imply there, @GraHal, is that the array lives over bars. As in Once $MyArray // Syntax error Once $MyArray[0] // Syntax error Once $MyArray[] // Syntax error On a side note : and *if* it would work like that, you’d get completely crazy of the fact that arrays can be one dimensional only. Thus, whatever you do, you would need two arrays or more. Think like (not tested for syntax, thus mere pseudo code) : If Highest(Close[20]) then // whatever this does. ElementToSet = ElementToSet + 1 $BarReference[ElementToSet] = BarIndex $HighReference[ElementToSet] = Close // Register highest price of last 20 bars at this moment in time. endif For i = 0 to $BarReference[LastSet] HighestBar = $BarReference[i] HighPriceBar = $HighReference[HighestBar] HighPrice = Close[HighestBar] next // Anyone who can understand this is crazy. // Anyone who can code this properly *and* understands himself, is ready for the mad house. The worst part is that this can easily be done without array, and then we suddenly understand. But meanwhile notice what I attempt there : Writing (for me) useful values in array elements, without consuming an 1M-elements array. This a. Makes it incomprehensible b. suggests that the array lives across bars (which it does not). Conclusion of that : There is no use to “save” array elements like I suggest doing there, and having them 1:1 with real bars (BarIndex) would – make it understandable indeed – make it a useless exercise because we already have that array (it is named Close[]). Working with arrays in PRT is mind boggling, or it is me who just can’t cope. Anyways … I personally use arrays everywhere and my whole life, but not within ProRealCode because there is no need to for me. This could also relate to actually everything already being in an array (or being presented as one), so that stuff like // Preserve the last 4 bars' gain. Gain4 = Gain3 Gain3 = Gain2 Gain2 = Gain1 Gain1 = Gain Gain = ThisBarsGain should better be done in a nice array, a small loop taking care of this. But this too is useless once you learn that this does all tricks already : If Gain > Gain[3] then // Gain larger than the gain 3 bars back ? // All still OK. endif So no definitions because PRT does this internally for you, and all is accessible in “array fashion”. Summarised : I am not debunking the array feature, but its real use-cases for me would occur when they live across bars; they are at least two dimensions. The latter is important so we could attach the value we want to preserve to the bar where it occurs in one go, which combines with not maintaining array elements per (history) bar. If Highest(Close[20]) then // whatever this does. ElementToSet = ElementToSet + 1 $HighReference[ElementToSet,1] = BarIndex // In case we want to know the bar where this happened. $HighReference[ElementToSet,2] = Close // The price where we detected this (whatever) High. endif // Find all the "highest" in subsequent elements of the array. For i = 0 to $BarReference[LastSet] HighPriceClose = $HighReference[i,2] // A high price occurred. HighBar = $HighReference[i,1] // Use this at convenience. For example : PricePriorToHigh = Close(HighBar - 1). // This happened right before this high. next So never mind this makes sense or not, at least I am now able to be creative and let it do something without being continuously disturbed by thinking of what I’m actually doing or even trying to do. We should not hallucinate over arrays going to live across bars (hoping that PRT is going to develop that) because I foresee all kind of hurdles regarding referencing bars in the past which are of a too far away history. Thus, if I would be able to store “events” (like my Highs) in an array in subsequent elements and once per month such an event occurs with my 1 second TimeFrame, then personally I would noy know what happens when my Live Strategy is 5 months in, and I still refer to a 1 second bar of 5 months in the past. I know, this is a general problem already, and the topic with the question “I save a barindex in a variable in order to refer to it as “Close[myBarFromDec2019]”, I postponed for later – but sure is due. IMO these things can’t work and my Live Strategy will eventually break (error out) or possibly come up with 0 values which ever back were not 0. Anyway : An array would be useful for this, if I would only store the resulting values of Close[myBarFromDec2019] and never the index to bars. Thus $MyHistoryArray[element 773] = Close[0]. After 3 years I will surely be able to access element 773 and its stored value. That is, if my strategy still runs, which chances are small either because of error or me being broke in that portfolio. And restarting that Strategy will have lost the value(s). There is really more to it all and I think that PRT does not have the infrastructure to let this work as I like to. But I’ll survive. 🙂 Peter

This topic has 32 replies, 6 voices, and was last updated 2 years ago by PeterSt.

Viewing 3 posts - 31 through 33 (of 33 total)

← 1 2 3

01/21/2022 at 1:16 PM #186182

GraHal

I can’t understand from the screenshots what the bug is and you haven’t said what the bug is? The Dutch on the screenshots doesn’t help understanding. 🙂

GraHal
Participant

Topics: 214
Replies: 8826
Been thanked: 2198 times

01/21/2022 at 3:22 PM #186201

PeterSt

Ah, ok. Sorry about that.

See how SureRisePoints vary. Also see how in the Optimisation Report the resolution shown is not high enough (which is the bug – several show the same value). But also see that internally this surely works out to different gains (no other variable changes). So now I can’t see which value is the best value.

And in the second post about this I showed how clicking the Save icon *does* show the value per Optimisation step / line (2nd attachment below).

PeterSt
Participant

Topics: 73
Replies: 2544
Been thanked: 829 times

03/07/2022 at 6:11 PM #189556

PeterSt

Dear people,

Please look at the last 3 posts on the first page. From that point on a huge misunderstanding emerged, which lived on until today. The main message in that post :

Arrays don’t live across bars.

But today it was worked out that this is not correct at all. N.b.: I could not see it because of technical issues with array elements. Also, because the subject seems somewhat more difficult, I was not corrected as well (in this very topic).

@Nicolas and of course @robertogozzi, thank you for bearing with me and keep on telling me that I had it plainly wrong !
Peter

1 user thanked author for this post.

robertogozzi

PeterSt
Participant

Topics: 73
Replies: 2544
Been thanked: 829 times
Author

Posts

Viewing 3 posts - 31 through 33 (of 33 total)

← 1 2 3

Find exclusive trading pro-tools on

Arrays and how they can *not* be used (?)

1 user thanked author for this post.

Arrays and how they can not be used (?)