druby wrote:

The condition and various sets of SMA are assigned to arrays. The group variable chooses which array is printed. group 1 is default and show the overall condition. If that need investigation, changing to group 2 shows logic behind condition. This allow switching back and forth at will.

Thanks druby.

Sorry I didn’t reply earlier.

Sounds like you might be able to print out what was the ‘last known’ condition of an array based on other metrics triggering it, perhaps historical evts too?.

Can you timestamp (perhaps use barindex, just guessing) so comparisons can be made between 2 array conditions and display that last occurring event? Chicken and egg kind of thing but know that at a specific point (previous tod / barindex?) you had X event occur?

If so can this kind of setup be used in an auto-trader?

Not sure if I fully understood what’s been said but do remember @PeterSt saying that diving into arrays while useful could also be my undoing (no offence taken btw, just implying they’re complexities for a newbie which is fair enough!)

I think I’m having a moment here  … 😮

I looked at barrsince a while back and it was promising, no idea why I overlooked it here.

If I can print it, I should be able to ‘barrsince it’ (maybe) ….. again with the good gear druby … 🙂

I’ll see if I can build a bit of logic around it.

Unfortunately tonite I’ve needed to go to a 15K bar count chart, given that’s the case and preload bars on pro-order is 10k is there a way to limit an auto-trader to wait until there’s 15 or 20k of massageable data? We can limit times and forbid days surely there’s a bar count min. limit that could also be doable?

Was looking at the same solution, but your implementation appears quite elegant.

I think the max preloadbars  setting is 10000, however setting to 15000 and with the logic, does the trick.

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.

druby wrote:

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 of

Once 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 / TotalSofarCount

Of 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 as

TotalSofar = TotalSofar + Close            // 427206663 = 427006311 + 200320   // 200320 is the current close value for the first bar read.
MyAverage = TotalSofar / TotalSofarCount   // 427206663 / 25001 = 17087.5817

Again, 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 …

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.

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.