That part is optional, but I threw it in as an additional safety check, to make sure the actual fill price is somewhat in line (in this case, within 4 ticks) of the theoretical ENTRY price of the system (which may have been based on close of bar).
I didn't use POSITION here. POSITION simply represents POS_SIZE during backtesting or when loading a chart, then it starts tracking TR_POS when processing live ticks.
POS_SIZE is positive if long, and negative when short.
I'm setting the V#15 to zero when we can not rely on TR_FILL or TR_POS is zero (in other words, we are not in actual trade). Then you should use that V#15 as the size for your actual trading order. In effect, it will send the order with a size of 0 in this case and do nothing.
Trying to incorporate a scale out into my strategy. For example, strategy buys 2 ES contracts and sells 1 at a 4 tick profit. The remaining contract is sold once the ultimate target is reached.
But, what if the scale out occurs and price reverses to the catastrophic stop. Or, maybe price reverses to the stop before the scale out. Is there a way to sell ALL remaining contracts? Depending on whether or not the scale out occurred, there could be either 1 or 2 contracts remaining.
Also, if there is only one contract remaining and you sell 2 contracts, will the system liquidate the long and then sell 1 short or only liquidate the remaining long?
A simple route might be to just make your stop order a "Flatten Position" order.
Otherwise, you could put some login inside your trading system to set a V# to the TR_POS (will need to be ABS(TR_POS) for short) and then use that V# in your trading order instead of a constant.
Regarding the response above about using "Flatten Position", it is not recognized as a valid order and therefore does not execute (I am using GAIN). I will try using TR_POS to determine the actual number of contracts open.
But...here are some additional questions. These are concerning the IntraBar setting in the Action section of the system definition.
Does the IntraBar setting affect live trading or only backtest?
Does the live trading action occur Intrabar only if using HI or LO in the RTL? (versus CL).
Since CL is not, by definition, intrabar, what happens if the RTL specifies CL but the IntrBar setting is checked?
The Intra-Bar checkbox associates itself with a rule/signal. It is ONLY relevant for live trading in TSYS Indicator and has no impact at all on backtesting. If Intra-Bar is turned on for a rule, that rule will be continually monitored/evaluated as the bar forms. If the rule becomes true during the bar, then any associated action (trading order) will trigger at that point while bar is still forming instead of waiting for bar to complete to run the rule on the just completed bar.
Intra-Bar is typically used for rules that....once they become true, they never become false during that same bar. This would be the case when looking for price to hit a target or a stop. Consider this rule where the target is set to V#17 and we are looking for price to move up to that target...
HI >= V#17
once the high of the forming bar gets to V#17, the target is hit. The HI never goes down, only up, during formation of bar. So we can go ahead and trigger our action (trade) at that instant price meets or exceeds that target. Hope that helps to clarify.
So if the backtest rules are evaluated once per bar interval, does that imply the same rule as above (HI >= V#71) is only evaluated at close of bar? And I assume that is the reason you want to backtest on the lowest periodicity practical.
And in backesting, if your HI >= V#17 rule was above your entry rule, it would not be considered until the bar after entry. However, if it was below your entry rule, it would be possible to get in and out on same bar. But that is also dangerous as the HI may have occurred before entry. Typically I recommend a periodicity of 1-min bars for testing.
Earlier in this thread you created some code to accommodate both backtesting and live trading. I want to test my understanding of how this code works. See below.
Statement #1
IF(POS_SIZE > 0 AND TR_POS != 0 AND TR_FILL > 0 AND ABS(TR_FILL - ENTRY) <= 4 * TINC) THEN (SET(V#13, TR_FILL + V#17 * TINC) AND SET(V#14, TR_FILL - V#17 * TINC) AND SET(V#15, ABS(TR_POS)));
Statement 1 is used during live trading. It first tests that both backtest and live trading indicate the system is Long and that the theoretical backtest entry price (ENTRY) is reasonably close to the actual fill price (TR_FILL). Differences may be due to the backtest engine evaluating the code on a close of bar basis where live trading is evaluating entry conditions intrabar. The actual fill price is used as a reference to set stops and targets. V#15 is set to the actual position size.
Why is POS_SIZE > 0 required in this statement? It seems that you would want to ensure that this statement will not be evaluated by the backtest engine, so wouldn't POS_SIZE = 0 be correct?
Statement #2
IF(POS_SIZE > 0 AND (TR_POS == 0 OR TR_FILL <= 0 OR ABS(TR_FILL - ENTRY) > 4 * TINC)) THEN (SET(V#13, ENTRY+ V#17 * TINC) AND SET(V#14, ENTRY- V#17 * TINC) AND SET(V#15, 0));
Statement 2 is used only for backtest calculations. It tests that the backtest is in a trade (POS_SIZE > 0) and live trading is not (TR_POS == 0 OR TR_FILL <= 0). In other words, this statement is not used for live trading. In fact, the position size (V#15) is set to 0 so an actual live trade cannot be initiated. Targets and stops are set based on the backtesting token ENTRY price.
Why is POS_SIZE > 0 required in this statement? It seems that you would want to ensure that this statement will not be evaluated by the backtest engine, so wouldn't POS_SIZE = 0 be correct?
You want ensure that the trading system got you into this trade (as opposed to maybe you launching the program with an actual trade already on but not entered by position) so ensuring that POS_SIZE > 0 (or POS_SIZE != 0) will do just that. Probably not required but safer this way.
Right, this is just used in case the 1st rule doesn't kick in for live trading....so that you can see the trades historically in the TSYS chart (or you can backtest the system). Obviously, running the backtest would not work if you have an active position on at the time you run the backtest. We have discussed adding a token that conveys whether or not the system is processing live ticks in a chart, or not. Something like TR_LIVE that would just be 1 if live or 0 if false. Will probably get something like that in place soon.
I believe it might be a good time to consider attacking this live trading issue with an RTX Indicator.
We do have a built-in indicator called Trading Rule which was designed with some of this in mind, but it might be time to take a fresh approach from the RTX side.
Entry could be based on either a Signal, or an entry price/level (price moving up to 1200.75, C#1, V#1, etc).
The entry would fire a signal action which would typically enter the position. From there, stop and target options could be available.
If automatical order management (trading strategy) is associated with the entry order, then that will take care of the stop and target management on the server side, and there really is no need for anything more than the Trading Rule that is already in place.
You can read move about Automated Order Management in the link below. Currently only supported for CQG and Rithmic.
But ultimately, simply using the Trading Rule with your entry signal and the letting the trading strategy take care of your targets and stops might be the way to go. Sometimes the challenge can be fitting all your entry logic into a single signal.
AND ABS(TR_FILL - ENTRY) <= 4 * TINC
That part is optional, but I threw it in as an additional safety check, to make sure the actual fill price is somewhat in line (in this case, within 4 ticks) of the theoretical ENTRY price of the system (which may have been based on close of bar).
I didn't use POSITION here. POSITION simply represents POS_SIZE during backtesting or when loading a chart, then it starts tracking TR_POS when processing live ticks.
POS_SIZE is positive if long, and negative when short.
I'm setting the V#15 to zero when we can not rely on TR_FILL or TR_POS is zero (in other words, we are not in actual trade). Then you should use that V#15 as the size for your actual trading order. In effect, it will send the order with a size of 0 in this case and do nothing.
Trying to incorporate a scale out into my strategy. For example, strategy buys 2 ES contracts and sells 1 at a 4 tick profit. The remaining contract is sold once the ultimate target is reached.
But, what if the scale out occurs and price reverses to the catastrophic stop. Or, maybe price reverses to the stop before the scale out. Is there a way to sell ALL remaining contracts? Depending on whether or not the scale out occurred, there could be either 1 or 2 contracts remaining.
Also, if there is only one contract remaining and you sell 2 contracts, will the system liquidate the long and then sell 1 short or only liquidate the remaining long?
Thanks.
A simple route might be to just make your stop order a "Flatten Position" order.
Otherwise, you could put some login inside your trading system to set a V# to the TR_POS (will need to be ABS(TR_POS) for short) and then use that V# in your trading order instead of a constant.
Regarding the response above about using "Flatten Position", it is not recognized as a valid order and therefore does not execute (I am using GAIN). I will try using TR_POS to determine the actual number of contracts open.
But...here are some additional questions. These are concerning the IntraBar setting in the Action section of the system definition.
Does the IntraBar setting affect live trading or only backtest?
Does the live trading action occur Intrabar only if using HI or LO in the RTL? (versus CL).
Since CL is not, by definition, intrabar, what happens if the RTL specifies CL but the IntrBar setting is checked?
Thanks.
The Intra-Bar checkbox associates itself with a rule/signal. It is ONLY relevant for live trading in TSYS Indicator and has no impact at all on backtesting. If Intra-Bar is turned on for a rule, that rule will be continually monitored/evaluated as the bar forms. If the rule becomes true during the bar, then any associated action (trading order) will trigger at that point while bar is still forming instead of waiting for bar to complete to run the rule on the just completed bar.
Intra-Bar is typically used for rules that....once they become true, they never become false during that same bar. This would be the case when looking for price to hit a target or a stop. Consider this rule where the target is set to V#17 and we are looking for price to move up to that target...
HI >= V#17
once the high of the forming bar gets to V#17, the target is hit. The HI never goes down, only up, during formation of bar. So we can go ahead and trigger our action (trade) at that instant price meets or exceeds that target. Hope that helps to clarify.
So if the backtest rules are evaluated once per bar interval, does that imply the same rule as above (HI >= V#71) is only evaluated at close of bar? And I assume that is the reason you want to backtest on the lowest periodicity practical.
And in backesting, if your HI >= V#17 rule was above your entry rule, it would not be considered until the bar after entry. However, if it was below your entry rule, it would be possible to get in and out on same bar. But that is also dangerous as the HI may have occurred before entry. Typically I recommend a periodicity of 1-min bars for testing.
Earlier in this thread you created some code to accommodate both backtesting and live trading. I want to test my understanding of how this code works. See below.
Statement #1
IF(POS_SIZE > 0 AND TR_POS != 0 AND TR_FILL > 0 AND ABS(TR_FILL - ENTRY) <= 4 * TINC) THEN (SET(V#13, TR_FILL + V#17 * TINC) AND SET(V#14, TR_FILL - V#17 * TINC) AND SET(V#15, ABS(TR_POS)));
Statement 1 is used during live trading. It first tests that both backtest and live trading indicate the system is Long and that the theoretical backtest entry price (ENTRY) is reasonably close to the actual fill price (TR_FILL). Differences may be due to the backtest engine evaluating the code on a close of bar basis where live trading is evaluating entry conditions intrabar. The actual fill price is used as a reference to set stops and targets. V#15 is set to the actual position size.
Why is POS_SIZE > 0 required in this statement? It seems that you would want to ensure that this statement will not be evaluated by the backtest engine, so wouldn't POS_SIZE = 0 be correct?
Statement #2
IF(POS_SIZE > 0 AND (TR_POS == 0 OR TR_FILL <= 0 OR ABS(TR_FILL - ENTRY) > 4 * TINC)) THEN (SET(V#13, ENTRY+ V#17 * TINC) AND SET(V#14, ENTRY- V#17 * TINC) AND SET(V#15, 0));
Statement 2 is used only for backtest calculations. It tests that the backtest is in a trade (POS_SIZE > 0) and live trading is not (TR_POS == 0 OR TR_FILL <= 0). In other words, this statement is not used for live trading. In fact, the position size (V#15) is set to 0 so an actual live trade cannot be initiated. Targets and stops are set based on the backtesting token ENTRY price.
Thanks.
Why is POS_SIZE > 0 required in this statement? It seems that you would want to ensure that this statement will not be evaluated by the backtest engine, so wouldn't POS_SIZE = 0 be correct?
You want ensure that the trading system got you into this trade (as opposed to maybe you launching the program with an actual trade already on but not entered by position) so ensuring that POS_SIZE > 0 (or POS_SIZE != 0) will do just that. Probably not required but safer this way.
Right, this is just used in case the 1st rule doesn't kick in for live trading....so that you can see the trades historically in the TSYS chart (or you can backtest the system). Obviously, running the backtest would not work if you have an active position on at the time you run the backtest. We have discussed adding a token that conveys whether or not the system is processing live ticks in a chart, or not. Something like TR_LIVE that would just be 1 if live or 0 if false. Will probably get something like that in place soon.
I believe it might be a good time to consider attacking this live trading issue with an RTX Indicator.
We do have a built-in indicator called Trading Rule which was designed with some of this in mind, but it might be time to take a fresh approach from the RTX side.
Entry could be based on either a Signal, or an entry price/level (price moving up to 1200.75, C#1, V#1, etc).
The entry would fire a signal action which would typically enter the position. From there, stop and target options could be available.
If automatical order management (trading strategy) is associated with the entry order, then that will take care of the stop and target management on the server side, and there really is no need for anything more than the Trading Rule that is already in place.
You can read move about Automated Order Management in the link below. Currently only supported for CQG and Rithmic.
https://www.linnsoft.com/intro-trading-strategy
But ultimately, simply using the Trading Rule with your entry signal and the letting the trading strategy take care of your targets and stops might be the way to go. Sometimes the challenge can be fitting all your entry logic into a single signal.
Pages