Sorry, I dont get it, I just made a test wit the code you provided and the result is 99:
Haha, it well could be a language issue (my English). Your code :
1
2
3
4
5
6
7
8
9
10
11
12
$Arr[0]=89
$Arr[1]=200
MyVar=10
MyVar=MyVar+$Arr[0]
a=1
ifa=0then
buyatmarket
endif
graphmyvar
does not comply to my expression about “across bars” (I said it differently before). Thus, try this (I did not test it today) :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OnceArraySet=0
IfnotArraySetthen
$Arr[0]=89
$Arr[1]=200
ArraySet=1
endif
MyVar=10
MyVar=MyVar+$Arr[0]
a=1
ifa=0then
buyatmarket
endif
graphmyvar// Should graph 99 one time. All of the next times 10.
And thus the issue :
ArraySet is sustained for its value
$Arr is “new” at the next bar-call (call of the code).
If I am right (after all) I should show you a most useful code/application with arrays, which I made in vain because the arrays are not sustained. I made it in vain because natural thinking makes me do it, even after I knew and made that topic about it (~ 2 months back – “What arrays can *not* be used for”).
@PeterSt
Your comment is “// Should graph 99 one time. All of the next times 10”
No, array elements keep any retained value until you change it purposely, like any variable.
The sole difference is that if you change a variable, you can still access its previous value with and index, such as MyVar[1], MyVar[2], etc…, while array elements CANNOT, you can’t access a prior value of an array element by using, say, $Arr[0][1] to retrieve the value that element $array[0] retained the prior bar!
Can you post a description of an example of when you want an array to be totally erased at any new bar? It could be done, but you have to code it!
You mentioned that ProBuilder is not handling arrays like any other programming languages, because values are persistent other time. I do not know any language where arrays are automatically erased without any explicit instruction to do it?
No, array elements keep any retained value until you change it purposely, like any variable.
Even if I read that a 100 times I don’t understand the message in it. Maybe rephrase because the semantics seem so-so to begin with (I will try to learn Italian).
But apparently you guys don’t understand my messages either. 🙂
No array elements retain their value, unlike normal variables do.
(from bar to bar)
That should be correct (correct semantics maybe not – haha)
OK, you are right. It works. I guess there are just too many pitfalls and our mutual examples keep on being incorrect (mine too !).
With a larger array-application, always something goes wrong (not working) because of the strange way how to deal with them. This is for that other topic, so never mind that for now (I just try to find excuses 🙂 🙂 ).
Anyway, it requires 100% literal examples, or else something differently happens. Thus your last example
1
$var[0]=1000
will always show 1000 indeed, but not because it is going across bars. You just assign it newly each time in this example (it requires an If not to do that).
I repeat : my own examples also work out differently. But a lot is based on mistakes, where you don’t correct me on. Example (implied in my earlier example) :
1
2
3
4
5
6
7
// Suppose these are THE ONLY lines in a Strategy :
$Arr[2]=$Arr[2]+1000// This errors-out internally.
aaa=aaa+1// But this is fine (which I personally hate, but alas).
Graph$Arr[2]// Graphs nothing because it errored out earlier.
Graphaaa// Graphs 1, 2, 3, 4, ...
As you can see this is not consistent behaviour and I never saw that (I never recognised it).
This code would be correctly working (tested this time) :
1
2
3
4
5
6
7
8
9
10
11
12
OnceArraySet=0
IfnotArraySetthen// THIS ONE !
$Arr[0]=89// So Yes, this value is retained.
$Arr[1]=200
ArraySet=1
endif
MyVar=10
MyVar=MyVar+$Arr[0]
GraphMyVar// Always graphs 99.
I like to bring across that this is enormously ambiguous coding because it requires nothing much to let the line denoted “THIS ONE !” to go wrong on the coding side (I forget line one, for example or anything else that makes the If work out to False always) and the code at this line :
MyVar = MyVar + $Arr[0]
will just not do its job. And, if I use arrays like your examples (everywhere I’d say, including the last posts) then you use them locally (within the one bar) and by nature that would not fail. This is because I won’t need any If Not ArraySet stuff.
So …
@fhorus, I don’t understand what your issue is, because all just works (LOL). But I hope that Nicolas sees that his last reply to fhorus is again with an example where the array is used “locally”. And this way we will never understand.
With my way of throwing confusement at you, also not.
The ONCE should be used to define a variable such that its scope is always under the definition. This is ambiguous :
1
2
3
4
5
6
7
8
9
10
11
12
IfnotArraySetthen
$Arr[0]=89
$Arr[1]=200
ArraySet=1
endif
// What if the code in the If is never executed ?
// We would have unexpected results in :
bb=$Arr[0]
// and all what further uses bb (or $Arr). And no error message anywhere.
Now this :
1
2
3
4
5
6
7
8
9
Once$Arr[]// This initialises all array elements at 0. But which ? so there's more to it (Dim command).
IfnotArraySetthen
$Arr[0]=89
$Arr[1]=200
ArraySet=1
endif
// Now nothing is ambiguous.
So the above (last code) can not be done because PRT does not allow for it.
Lastly :
1
2
3
OnceA=0// If I would leave this out, I'd kill myself on the next occasion.
A=A+1// Count across bars.
So you guys come up with examples leaving out the first line and deem it fine.
It is of course PRT providing the option (not for arrays !) so we can wonder who is “wrong” to begin with.
Thus @fhorus, with the correct examples everybody turns out to be correct. But the main thing is : it just works as you (and me) want it to. Not with the ONCE but with some kind of decent If.
Apologies for all the confusing stuff. Luckily I was somewhat cautious. 🙁
This was the longest post possible to state that I was wrong after all.
Thank you Nicolas, Roberto and PeterSt for your time and effort to bring us to an understanding of those points. It appears it was much needed ! So basic, however previously unclear.
So many years of using PRT and the point you’ve stressed here several times, Nicolas -“ variables retain their value”-, was simply not in my mind or fairly unclear, probably because most of the variables in my indicators just change their value on each new bar. Not surprising that I’ve sometimes got some trouble with boolean variables, from one bar to the next !
Ok, we’ve got it now ; hope it will also be useful to others.
No array elements retain their value, unlike normal variables do
NO, that’s incorrect. As I wrote, “No, array elements keep any retained value until you change it purposely, like any variable“. I can’t see how semantics could be of any help, just once you have assigned a value to an array element that value will ALWAYS be retained, bar after bar, untill you purposely change it, just like any variable. That’s all.
OK, you want to continue. Yes Roberto, I know that by now. Why repeat something which was put behind us ? please delete your own last post and this one from me. You are additionally confusing, IMHO.
Yes, you are right too. Happy ? sure you are.
Now you can delete your post. 🙂
Hello Nicolas , do you know why the above indicator from post #118817 (Example #1: support and resistance example, based on fractals points) displays as follows on PRT v11? (SP500 in 500 ticks, history 500 UT) Thanks
.
