[attachment file=”234363″]

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.

// indicators
ST = Supertrend[3,10]

// conditions
if close crosses over ST then
signal = 1
endif

if close crosses under ST then
Signal = 0
endif


// orders ( displayed on price chart! )
if not onmarket and signal then
buy at market
 endif

if onmarket and not Signal then
sell at market
endif


// --- PLOT VARIABLES ON PRICE PANEL OF CHART
if close > ST then
graphonprice ST coloured("lime") as "ST"
else
graphonprice ST coloured("red") as "ST"
endif

// --- PLOT VARIABLES ON NEW PANEL OF CHART
graph close coloured("violet") as "close"
if close > ST then
graph ST coloured("lime") as "ST" 
else
graph 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 then
print(signal)coloured("red") fillcolor("red",10)
print(ST)coloured("red")fillcolor("red",10)
elsif signal = 0 and signal[1] = 1 then
print(signal)coloured("green")fillcolor("lime",10)
print(ST)coloured("green")fillcolor("lime",10)
endif

Screenshot-2024-06-26-094251.png Screenshot-2024-06-26-094251-1.png

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!

Screenshot-2024-06-27-014606.png test-print-var-limit-V1.00.itf

Thanks Druby, certainly a bit to mull over there, you’ve not let me down … 🙂

Very good point on printing what’s only needed, matches etc and I’m doing this now. Just getting a feel for how it’s feeding back triggers, so a big work in progress for me. TBH some code in back test or demo is probably a good idea sooner rather than later mainly because of 10k preload bars limits and what I can take with me from the indicators and into pro-order, long way to go but an idea of perhaps killing two birds if possible.

I’m trying to avoid HFT-like activities so it can marry with my discretionary actions but boy oh boy I think that’s perhaps the biggest challenge because the prints look okay to me and it’s hard to walk away from it seeing how well it all marries. So I’m trying to unwind it a little to marry with a smaller scope. Reading about there’s a few that’ll pre-can a number of auto-traders to meet there needs, maybe it’s something I can look at and tbh it’s something I’ve done for quite a while ‘manually’ and only now thought that a narrow poc  auto-trader would be cool to look at (family project, less family more me atmo, ha!)

The column ordering is something I’ve seen too and yes it’s a work in progress so I’ll mull over what you’ve suggested and see whether I go a little lateral and around the block with it till I land on something.

Thanks for the feedback!

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.

Screenshot-2024-06-27-051929.png test-print-var-limit-V1.01.itf

Looks good, I’m going to introduce that type of structure in my programming.

Spend too much time tracking down bugs, especially when they dont want to be found.

Regards