The following code is a simple limit based trading system however there are a handful of trades which ignore the exit signal and remain open through the life of the back-test which screws up the results. I believe this when exits happen on the same bar as entries?

CODE:
Please log in to see this code.

Let's start the other way around: "The following code..." peeks into the future by referencing the High price of the current bar and buying at limit the same bar (and possibly by using the LRV series when exiting).

Yes, I am peeking ahead to eliminate top/bottom ticks. LRV series is the exit price. I tried the following as well and similar issue

CODE:
Please log in to see this code.

Ok this worked, anyone see any errors?

CODE:
Please log in to see this code.

QUOTE:
Yes, I am peeking ahead to eliminate top/bottom ticks

What do you mean?

QUOTE:
there are a handful of trades which ignore the exit signal

It will only "ignore" it if it's programmed to ignore it. Got Slippage?

I only want the trade to execute if the high/low of bar exceeds the entry to ensure a realistic execution.

Understood, 99% of trades have the proper entry except a handful of trades never close despite the fact that price trades through the calculated exit. These trades are left open for years and generate huge outliers....

I'm still doing something wrong because I believe price is peeking as well now but any changes result in an error.

I think the addition of ! IsLastPositionActive fixed the problem, just double check for strategy peeking!

CODE:
Please log in to see this code.

QUOTE:
I only want the trade to execute if the high/low of bar exceeds the entry to ensure a realistic execution

Use "Limit Order Slippage". User Guide > Preferences > Slippage & Round Lots

QUOTE:
I think the addition of ! IsLastPositionActive fixed the problem

Right. Your logic was allowing for two positions to be opened on the same bar. For backtesting you need to determine which order your prefer to fill by putting it first.

In real life, you'll get Alerts for both signals, but the one that fills first is the one you'll stick with. If you're using trading automation (Fidelity), you'll need to cancel the opposing order to ensure that you don't "trade the box". And, if it turns out that both orders would have filled, just remember that your Strategy will always give priority to the first signal (ShortAtLimit).

Finally, Low[bar+1] is peeking. You cannot look ahead to a price on the next bar. Here's the snippet again with that correction and with a hint for using "else" statements.

CODE:
Please log in to see this code.

QUOTE:

Finally, Low[bar+1] is peeking. You cannot look ahead to a price on the next bar.

Cone,

This brings up another question slightly off thread. I am testing an Intraday Futures trading strategy where I am fading deviations and only want to execute at a certain price. As opposed to equities, a good deal of volume on index futures (ES for example) is conducted on the bottom and top ticks of the bar. What is a good technique to model these transactions? Adding a tick slippage will certainly negate the strategy, but wouldn't adding 1 tick slippage along with commission negate almost any high frequency intraday strategy?

QUOTE:
a good deal of volume on index futures (ES for example) is conducted on the bottom and top ticks of the bar. What is a good technique to model these transactions?

What's the model supposed to do? If you're trading X minute bars, it doesn't matter what happens "inside the bar" because your strategy can't access that data anyway unless: a) your base scale really isn't X-minute bars but something less, or, b) some other app has made the "intra-bar" data available for the X-minute strategy to read at the time it's processed.

QUOTE:
Adding a tick slippage will certainly negate the strategy

Why?

QUOTE:
wouldn't adding 1 tick slippage along with commission negate almost any high frequency intraday strategy

No, why?

Maybe you misunderstand what limit order slippage is. Essentially (and theoretically-speaking in backtests only) your order will be processed at the limit price if the market trades past your limit price by the slippage amount (for futures, I don't see any reason ever to use more than 1 tick).

In real life, it's quite possible that your limit order is executed precisely at a bar's extreme price. But just because your limit order gets by the slippage rule, it's the rest of the trade that determines whether you win or lose. In other words, limit order slippage can keep you out of bad trades as well as good trades that may have actually filled in real life. That's a little different that market-order slippage, which always reduces your trading gain, whether or not the trade is a winner or loser.

Yes, thank you for explaining slippage, I assumed slippage just charged each trade a set $ amount and as I was utilizing limit orders I don't believe that was relevant. But if its a simple checkbox, I can eliminate the peeking code above and just utilize that function.

I'm applying a fairly typical mean-reversion strategy to ES futures, sell strength, buy weakness, cover at some mean value. These strategies tend to work very well in equities. However with futures, a large percentage of my trades occur on those top/bottom ticks due to the larger tick size. When removing those trades, the return distributions becomes completely skewed to the losers, as in you know your losing trades will get filled but cannot predict when your winning trades will execute. The overall profitability depends greatly on those winning trades; when eliminated you get these beautifully downward sloping equity curves. So I'm at a loss as to how High Frequency futures trader make a buck without the ability to somehow trade at these levels (for a MR strat) or model a percentage of those trades as winners?

It's quite possible that the model just doesn't work....but the theory is sound IMHO.