How to know output from indicator when programming?
- This topic has 51 replies, 7 voices, and was last updated 4 months ago by
.
-
I think its written somewhere in one of the manuals that, the code only executes once per bar. What I didn’t see is, the definition of what a bar was. It wasn’t until I came across various comments, that it started to fall into place.
PRT, appears to be, an action triggered system, that is to say nothing changes until a tick comes in from the market, the action, for you displayed instrument. Depending on what timeframe your using, the time period is not a bar, its only a bar if a tick is in the time period. This can be proved by plotting the barindex variable. What you will see is it’s value increments by one only when there’s a tick present in the time period. On smaller timeframes, and/or low market action, there can be time periods without candles. When this happens barindex is not incremented.
It can be confusing because, bar, is generally used as a period of time on the timeframe. However there an operation difference between both.
Now at the default timeframe level, its not until a tick is received that the new bar starts. At the close of the bar the code is run. At this point any orders will be sent to the broker.
This is why a market order is set for the open of the next bar period. And there must be a small time delay between close; code run; order sent and order executed.
Once the orders have been sent to the broker, they will be executed independent of the code. I think some order types life span means they need refreshing every bar.
If you need to modify, the frequency the code executes, for a trailing stop or something else, the only way is to move to a lower default timeframe.
This solves the execution problem, but now you conditions are calculated at the default timeframe values and periods.
So the code needs modifying to get the higher timeframe values for the conditions back. The shorter way to do this is with the ‘TIMEFRAME’ instruction.
Without the ‘UPPDATEONCLOSE’, the higher timeframe values update with the default timeframe updates. With ‘UPDATEONCLOSE’ the higher time frame updates at its close.
Recently I’ve become aware that, using Timeframe without updateonclose in a called file, acts as if were using it, and update only at the close of the higher timeframe close. With it, delays result by another higher time frame period.
Additionally, moving to back test can cause an error message. Having the timeframe command in the main program and calling from with in it avoids issue.
What you will find is that you need to run on the lower timeframe, and use the Timeframe instruction for the higher ones. This could be done in one file, however you can call other files from within Timeframe instruction block to avoid back test error message.
Now, don’t take everything as 100%, because there can be exceptions depending on what your doing and how your doing it. And I have not checked at every point in the system and verified that execution is bar or time. These are some of the guidelines I keep in mind to avoid problems.
1 user thanked author for this post.
The simple answer to Inv’s question :
Your program code (Strategy code !) will not be executed (called) upon the occurrence of a tick (which is Bid, Ask or Trade). It can only be called on timed events (like 1 second, which is the smallest time possible for PRT).
The confusing will lie in the fact that Indicators and Indicator code do act upon ticks (though ticks for Trades only – not per Bid and Ask). So we can nicely visualize what happens at the tick level be that Trades, but we can not act upon it in anyway (yea, manually – press Buy or Sell).
1 user thanked author for this post.
The answer which requires somewhat more insight is this :
Yes, I sure use multi TFs in one Strategy. And this is not related at all to where you want to trade per se. Sure, I may use a one second system so I can act as close as I want, BUT this would not allow for nice Trailing systems. So try to grasp this :
Entries can very well be on the smallest TimeFrame possible (1 second).
Exits can do that too, but if you want trailing you will need to use a longer TF to give a Pending Order the opportunity to run into your set price. Mind you, I always talk about elf-created trailing here – not any trailing provided by PRT (which exists for IF but does not exist for IB).Once you grasp the above, you can hop over to the next step :
Which TF is used for what is thus up to you. Notice though, that the longer TF is commonly used to to the math on averages etc. Like 1 hour or 15 minutes (or days, whatever).
Meanwhile you can trade at the 1 minute level; same as I explained above (though above differentiated between Entry and Exit).
This now enters the realm of “shall I thus use a longer TF for the averages and such ?” … my answer : yes, but only *if* you still have the opportunity to trade at the shorter TF and still have sufficient backtest data. And there it goes wrong;I said it more often, people tend to propose the trading at the 1s level as the one all be all solution, but that is no solution at all and people should stop proposing it. Thus :
If I’d use a 1s TF for trading, I’d have 12 days of backtesting data (eh, with Premium that is – otherwise 1/5 of that). If that copes with your averages calculations, then fine, but forget about e.g. an average for 30 days with a (multi) TF of 1 day, because it’s just not there (because only 12 days are there).Now you know all, right ?
😉1 user thanked author for this post.
If I back test 1 million units (RTH) with a time frame of 1 second, then I have 3,5 months of (back test) data at IB… (screenshot) and 2 months (back test) data at IG…(screenshot)
I use a “Trailing Stop” with (1 second pending) Stop orders in both cases and for IB and IG this is no problem at all …
1234567891011121314151617181920If xLongOnMarket thenIf newSL=0 and (Close-TradePrice(1))>=(TrDist) thennewSL=TradePrice(1) //BreakEvenElsIf newSL>0 thennewSL=max((Close-TrDist),newSL)EndIfEndIfIf xShortOnMarket thenIf newSL=0 and (TradePrice(1)-Close)>=(TrDist) thennewSL=TradePrice(1) //BreakEvenElsIf newSL>0 thennewSL=min((Close+TrDist),newSL)EndIfEndIfIf newSL>0 thenSell at newSL STOPExitShort at newSL STOPEndIf1 user thanked author for this post.
Find exclusive trading pro-tools on 
