How to know output from indicator when programming?
- This topic has 51 replies, 7 voices, and was last updated 2 months ago by
.
-
Hello George,
Unfortunately no logging or any other means of output is possible.
What I would do is make an Indicator for that Supertrend (or anything) (thus, not a Strategy but an Indicator), show it in the price area of the chart, and then run the backtest.
You can now scroll back in time and visualize the crossings etc.Notice that you need to take care of the fact that your indicator will be redundant to what your Strategy program does. Thus, adjust the program means also adjusting the Supertrend parameter(s).
Have fun !
PeterWe can use GRAPH Instruction to get a 1 or -1 when conditions are true … does that help?
When back testing, there are only limited ways to display variables in the code. #GaHal points out the ‘GRAPH’ instruction, the only others I know of are, GRAPHONPRICE and the PRINT() instructions.
The difference between the two GRAPH instructions are, one plots the variable to the price panel, and the other to a new panel in the chart.
PRINT(),displays numeric values of the variables in a list, which I believe is limited to 200 entries.
Though limited, you can control the output using logic around them’
see example code.
Anything more complicated, with objects and text, then its down #PeterST route.
And getting data external to PRT, if available, is limited.
One further observation…
In an indicator, the code is terminated with ‘RETURN var1,var2,… etc. The ‘var’s are optional based on requirement.
In back test , the ‘RETURN’ is omitted, but can have ‘GRAPH’ and ‘GRAPHONPRICE’.
The returned var’s, and graph instructions appear to work the same, and the location where you add indicator, to which graph instruction used.
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647// indicatorsST = Supertrend[3,10]// conditionsif close crosses over ST thensignal = 1endifif close crosses under ST thenSignal = 0endif// orders ( displayed on price chart! )if not onmarket and signal thenbuy at marketendifif onmarket and not Signal thensell at marketendif// --- PLOT VARIABLES ON PRICE PANEL OF CHARTif close > ST thengraphonprice ST coloured("lime") as "ST"elsegraphonprice ST coloured("red") as "ST"endif// --- PLOT VARIABLES ON NEW PANEL OF CHARTgraph close coloured("violet") as "close"if close > ST thengraph ST coloured("lime") as "ST"elsegraph ST coloured("red") as "ST"endif// --- LIST VARIABLES ON PRINT PANEL [limited 200 entries]// note...order executed on open of next bar!if signal = 1 and signal[1] = 0 thenprint(signal)coloured("red") fillcolor("red",10)print(ST)coloured("red")fillcolor("red",10)elsif signal = 0 and signal[1] = 1 thenprint(signal)coloured("green")fillcolor("lime",10)print(ST)coloured("green")fillcolor("lime",10)endifI think the best for understanding is what druby showed – repeated below. You will grasp it when you’d run his example code, but the main point is : the plotted lines you see there are generated from within the Strategy code (with GarphOnPrice) and it looks exactly the same as an Indicator which outputs it. Thus as a matter of fact, you could do *all* with that (please try druby’s code and play around with it).
Something else is (or could be) that you may have troubles with the “up and down” catching in code. This, IMHO, is a matter of getting used to (and the skill to code must possibly grow somewhat ?). It could also be about learning the “techniques” a bit. Like having a slow Moving Average and a fast Moving Average just in code, and knowing that you can still use the commands “Crossed Over” and “Crossed Under”. Just envision the outcome of functions like SuperTrend as plots (lines), not matter they are not there, while you can still do what you want with them as if they were there for real. This is how I put forward the Indicator and your Strategy code in parallel, so you could see your code plotting as if it were. Notice now that with GarphOnPrice you can do that for real BUT it requires backtesting (or forward testing = just let the backtest run/continue on your real time data) because Live code can not plot things (Graph and GraphOnPrice is not allowed in program code given to ProOrder).
A little bit more clear now ?
But thank druby – he did the hard(er) work.1 user thanked author for this post.
@druby I’ve hit the 10 variable limit when dumping to cli (print), any clues on extending this, could go side by side as a guess but a more clued-in way is always better – I know you like to do outside the box thinking and appreciate the insights you’ve shared elsewhere 🙂
1 user thanked author for this post.
Not ever hit that limit but, side by side would be my first bet.
Example shows 30 variables , each 10 are surrounded by logic so, on value of ‘switch’, only those 10 are sent to print window.
Though my example shows a group of Print()’s, you would surround each with same logic, were ever they were in program.
Then run different instances of program, then all variables will be covered by the different print windows.
Why!, columns end up in a non logical order, don’t know.
Speculating…
One issue you may have, is that depending, were in the program the Print() is, their may be a mismatch with the rows.
If this is a issue then, some form of index column may be called for, to keep alignment and/or group the print()’s in logical groups.
So, instead of groups of 10, the maximum, have several groups where results are logical/relevant for you to view.
This way you may not need to use other instances, just dynamically change the value of the switch from the settings,
for the relevant group of interest.
The 200 limit on entries runs out very quickly at bars level, conditions not so easy unless 100k+ runs.
I suppose this could be broken down into groups if it were a game breaker.
Not tried this with back test.
Obviously this is at best going to be a compromise and not ideal. However a option is better than no option.
I think that, grouping the Print()’s by relevant theme and dynamically changing the group, seems like a good process.
Another, not tried, idea would be to store the proposed print values in an array, and then manage, some logic, to select which to print.
May be using binary 101001101 to switch on/off required value,
And yet another thought, if several variables need to be true, for condition lets say, instead of displaying each one, display the result of all, true!.
If being false, breaks game, then you know which vars were involved, and then investigate or have a group of just them, which one was false.
anyway box is way out of sight!
1 user thanked author for this post.
What I do for the 200 lines limit (which only means : the last 200 are presented), is printing them only when really relevant. Thus, sitting back and thinking somewhat, you wouldn’t need the output of the variables at each bar-call. For example for each Entry yes. Or each Exit. Anyway generally, I have no issues with the 200 limit.
The limit of 10 variables is more cumbersome indeed. That would require some “shifted” grouping. I tend to do that by means of having a first 10, judge the result, comment those out and uncomment a next group of 10.
@druby : if one row does not contain all of them, it’s no problem (the cell just remains empty).
The column sequence is a guess indeed. I have seen them mixed in a fashion I did not like, and at a next boot of PRT is was fine.Print is great for tallying stuff. Thus, number of bars processed. Or number of trades. Etc. etc. etc. That only requires one line (while you have 200 – haha). With Graph you can tally too, but graph is relatively ultimately slow. Print holds back only a little.
All good points and idea’s Peter, I suppose the trick is to be flexible enough to cover everything, but refined enough to only present you with, what you need to move on.
On small code problems, any solution going to be helpful, its when it gets bigger and hard to keep track of it all.
Though extra code can bloat and complicate the situation, if it becomes part of the way you code then it becomes a feature.
Here’s an example I was looking at, on a similar line to your comment out technique.
Example just determines when a number of SMA align up. The condition is calculated using the relationship between various sets of SMA.
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.
Yes, great again.
Here’s my take on something which is obvious; it is necessary because Graph(OnPrice) has its limits too – apart from each graph slowing down significantly.
The example in the 2nd picture is one out of 100++ of such If’s in one program.
Of course this can be done with Print just the same.
Something else and for some maybe not known : the columns in the Print output can be given colors with the same syntax as usual.
1 user thanked author for this post.
Find exclusive trading pro-tools on 
