How to know output from indicator when programming?
- This topic has 51 replies, 7 voices, and was last updated 4 months ago by
.
-
No problem!
Good point, if I am following you right.
Image shows a corrected version of the SMA example, where I put in the correct values for the averages, doh!, and colour coded the average conditions along with a chart.
With Group set to 2, and looking at the print list, you can see where each individual condition changed from false to true.
And as you point out, your looking at values of the array[n] from previous bars.
Though the Print() list, shows the previous values, you would only be able to access the last value of an array[index] in code.
Variables usually hold a value for each bar. Since the var[n] of a variable is an offset from current bar, barindex is used to look back to the right location.
Arrays are different, in that, you can’t access a previous value of a specific index. They are useful for holding a specific number of values.
If you store the barindex, every time some condition is met, then you can use that to, look back at all the variables and values at that bar.
Also BarsSINCE(Condition,Occurrence) keyword can be used to look for last occurrence of certain variables.
1 user thanked author for this post.
1234567PreLoadBarsSet = 15000If BarIndex > PreLoadBarsSet then// all of your codeendif // End of all of your codeThis could start out with the normal DefParam PreLoadbars (= 10000) and it will imply a 5000 bar wait for you. With seconds that could be OK. With hours not so much.
🙂
With higher time periods, and/or beyond with the preloadbars limit, I suppose the first question is what needs those additional bars.
If further bars are needed to calculate an indicator, say moving Average etc, then there could be an option to pre calculate default
values for those, and syncronise a start point in the preload area. Then continue from there.
If there’s a need to look back beyond the preloadbars at earlier values, then that’s going to be a bit more difficult.
First thought, call a file with the data.
More untried idea’s.
1 user thanked author for this post.
what happens once the system is restarted will we need to buffer the data again?
Yes … 🙁
For Live as well as Backtesting. With Backtesting it only means you’ll have less backtesting period (which latter will not be a real pain).The idea would really be to avoid the whole issue; change your approach. Sit back and consider that using historical data to predict the future may lead to over-fitting in the first place.
1 user thanked author for this post.
First thought, call a file with the data.
… which is not possible in PRT. But you could collect the data over time and incorporate it in the “preload math”.
The data further back in history could be collected by PRT itself by means of a rougher time frame and special backtest run and then merged into the time frame you want to use by means of12345678Once TotalSofar = 427006311 // Accumulated outside of this program code (e.g. accumulated Close values like 17080 for the 25000 bars (below)).Once TotalSofarCount = 25000 // The "OOS" counted instances of virtual bars.TotalSofarCount = TotalSofarCount + 1 // Will be 25001 the first time your program is called.// Now accumulate further with the bars encountered in real time or backtesting.TotalSofar = TotalSofar + Close // Or whatever it is you accumulate over.MyAverage = TotalSofar / TotalSofarCountOf course this will be more complicated in your real life, but it is about the gist;
If you counted 427006311 of total value with the rougher time frame of 10 times what you normally use (say 10 hours instead of 1 hour), you will have counted 2500 bars. This now becomes thus 2500 times 10 = 25000 for the code you are using for real. If you would test with this 10 times for starters, you will learn soon what you need to do for real, in order for the result will be “linear”. Have accomplished that ? then you can go to 100 times; without further testing you will now have 250000 bars of history accumulated right when the program starts.
For the 10 times example, the second half of the sample code above will read as12TotalSofar = TotalSofar + Close // 427206663 = 427006311 + 200320 // 200320 is the current close value for the first bar read.MyAverage = TotalSofar / TotalSofarCount // 427206663 / 25001 = 17087.5817Again, your real life will be more complicated, depending on what you calculate. Try an Exponential Moving Average to get the gist of *that*.
I hope I presented the ad-hoc numbers a bit OK-ish (because of the lack of consistency check with real data). It is only about the gist of it all …
Interesting concept, echo real life comment and question approach.
If ‘idea’ is way out of ‘box’ , is it the right box, or is, ideal is way out there.
Re: call file
Image shows data file holding array values, simulated with loop.
Main file loops the call, and copy’s each value to a local array.
Once copied, data available in main, and data file not required again.
Additional, if main is in several charts, changing values in data file, size and/or mul,
ripples through all main instances, on data file re – apply.
It appears to work in back test, not tried with proOrder.
Image2, A proOrder file appears to append all file’s into one, so I don’t see why not.
Further, the proOrder file will take the up to date file when compiled, but any edits after won’t be included.
The data file, can be updated at any time, But a new proOrder file will need compiling for them to take affect.
1 user thanked author for this post.
That idea is really great because it uses the “data fill” indicator as a subroutine, which can be reused in all the strategies for that instrument of concern.
I am adding this seemingly superfluous text because the fact that it acts as a subroutine may not be clear to everyone. Also, it won’t consume extra slowness because of the call principle in PRT (which is relatively very slow). This is because it happens only once (If BarIndex = 0).
1 user thanked author for this post.
From the instrument side of things, and the lack of ability to change or identify the instrument.
At one point I was drawing a number of sup/res lines on the DAX, wall street, and bitcoin.
I used the ‘subRoutine’ technique for my sup/res lines, edit +/- the lines and used some logic to determine which instrument I was on.
With the fact that the normal range of these instruments were far apart from each other, that was one test.
A second one was, having a constant of a closed value for each instrument with a date/ time reference .
Chances of both appearing on two different instruments are very remote.
Maybe more possible over a larger number of instrument, but then use more than 1 reference value.
It worked quite well, when I change the chart to another instrument, the correct lines were drawn.
If I went on a random instrument I got a warning message, plus no lines.
Same message if no reference match, if it fell beyond historical bars loaded.
Also depending on, which candle you picked, could determine if lines drawn on different timeframes 5m,15m,30, 1h, 4h candle.
I don’t think I implemented all the these idea’s, because I moved onto other stuff, but it did the job at the time.
Find exclusive trading pro-tools on 
